Another approach to IR
in [Kernel]
|
From: Maxim Levitsky on 1 Dec 2009 10:50 On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: > While reading all of these IR threads another way of handling IR > occurred to me that pretty much eliminates the need for LIRC and > configuration files in default cases. The best way to make everything > "just work" is to eliminate it. > > The first observation is that the IR profile of various devices are > well known. Most devices profiles are in the published One-for-All > database. These device profiles consist of vendor/device/command > triplets. There is one triplet for each command like play, pause, 1, > 2, 3, power, etc. > > The second observation is that universal remotes know how to generate > commands for all of the common devices. > > Let's define evdev messages for IR than contain vendor/device/command > triplets. I already posted code for doing that in my original patch > set. These messages are generated from in-kernel code. > > Now add a small amount of code to MythTV, etc to act on these evdev > messages. Default MythTV, etc to respond to the IR commands for a > common DVR device. Program your universal remote to send the commands > for this device. You're done. Everything will "just work" - no LIRC, > no irrecord, no config files, no command mapping, etc. You are making one big wrong assumption that everyone that has a remote uses mythtv, and only it. Many users including me, use the remote just like a keyboard, or even like a mouse. > > Of course there are details involved in making this work. MythTV will > have to have a config option to allow it to emulate several different > DVR devices so that you can pick one that you don't own. It should > also have choices for emulating the common devices defined for the > remotes included with various Linux video board like the Hauppauge > remote. > > For apps that haven't been modified you will have to run a daemon > which will capture vendor/device/command evdev events and convert them > into keystroke commands than work the menus. You'll need a config file > for this and have to write scripts. Instead I'd just go modify the app > the respond to the IR events, it is easy to do. > > Long run, we define a MythTV IR profile, mplayer profile, etc and get > these into the IR database for universal remotes. Now MythTV can stop > emulating another vendor's device. > > For the default MythTV case no external support will need to be > installed if the protocol decode engines are in the kernel. The raw > data will come in, run through the engines, and pop out as evdev > messages with a vendor/device/command triplet. Devices that decode in > hardware will just send vendor/device/command triplets. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jon Smirl on 1 Dec 2009 11:20 On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky <maximlevitsky(a)gmail.com> wrote: > On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: >> While reading all of these IR threads another way of handling IR >> occurred to me that pretty much eliminates the need for LIRC and >> configuration files in default cases. The best way to make everything >> "just work" is to eliminate it. >> >> The first observation is that the IR profile of various devices are >> well known. Most devices profiles are in the published One-for-All >> database. These device profiles consist of vendor/device/command >> triplets. There is one triplet for each command like play, pause, 1, >> 2, 3, power, etc. >> >> The second observation is that universal remotes know how to generate >> commands for all of the common devices. >> >> Let's define evdev messages for IR than contain vendor/device/command >> triplets. I already posted code for doing that in my original patch >> set. These messages are generated from in-kernel code. >> >> Now add a small amount of code to MythTV, etc to act on these evdev >> messages. Default MythTV, etc to respond to the IR commands for a >> common DVR device. Program your universal remote to send the commands >> for this device. You're done. Everything will "just work" - no LIRC, >> no irrecord, no config files, no command mapping, etc. > You are making one �big wrong assumption that everyone that has a remote > uses mythtv, and only it. > > Many users including me, use the remote just like a keyboard, or even > like a mouse. So let's try and figure out a "just works" scheme for doing this. What I'm trying to do is to get everyone to step back and think about this problem instead of rushing head long into merging LIRC as is. irrecord is not something a non-technical user can easily handle. A basic scheme that can be used to eliminate configuration is to take well known IR device profiles and emulate them in Linux. So pick another well known device to emulate (call it A) and map it to mouse/keyboard events. Mapping vendor/device/command codes for a couple devices to mouse/keyboard events is a tiny amount of data and can be done in-kernel. This case could also be made to "just work". Set your universal remote to device A. Commands from for device A will arrive and be mapped into generic keyboard/mouse commands. There are probably other solutions to making IR work without needing irrecord and configuration. What would be some other possibilities? Also consider the long term strategy of defining standard device profiles and getting them into the IR database. Make an IR profile for mouse/keyboard. After this gets into the database a universal remote can be set to this profile which will be a better match than emulating another device. > > >> >> Of course there are details involved in making this work. MythTV will >> have to have a config option to allow it to emulate several different >> DVR devices so that you can pick one that you don't own. It should >> also have choices for emulating the common devices defined for the >> remotes included with various Linux video board like the Hauppauge >> remote. >> >> For apps that haven't been modified you will have to run a daemon >> which will capture vendor/device/command evdev events and convert them >> into keystroke commands than work the menus. You'll need a config file >> for this and have to write scripts. Instead I'd just go modify the app >> the respond to the IR events, it is easy to do. >> >> Long run, we define a MythTV IR profile, mplayer profile, etc and get >> these into the IR database for universal remotes. Now MythTV can stop >> emulating another vendor's device. >> >> For the default MythTV case no external support will need to be >> installed if the protocol decode engines are in the kernel. The raw >> data will come in, run through the engines, and pop out as evdev >> messages with a vendor/device/command triplet. Devices that decode in >> hardware will just send vendor/device/command triplets. >> > > > -- Jon Smirl jonsmirl(a)gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mauro Carvalho Chehab on 1 Dec 2009 12:10 Hi Jon, Jon Smirl wrote: > On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky <maximlevitsky(a)gmail.com> wrote: >> On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: >>> While reading all of these IR threads another way of handling IR >>> occurred to me that pretty much eliminates the need for LIRC and >>> configuration files in default cases. The best way to make everything >>> "just work" is to eliminate it. >>> >>> The first observation is that the IR profile of various devices are >>> well known. Most devices profiles are in the published One-for-All >>> database. These device profiles consist of vendor/device/command >>> triplets. There is one triplet for each command like play, pause, 1, >>> 2, 3, power, etc. >>> >>> The second observation is that universal remotes know how to generate >>> commands for all of the common devices. >>> >>> Let's define evdev messages for IR than contain vendor/device/command >>> triplets. I already posted code for doing that in my original patch >>> set. These messages are generated from in-kernel code. >>> >>> Now add a small amount of code to MythTV, etc to act on these evdev >>> messages. Default MythTV, etc to respond to the IR commands for a >>> common DVR device. Program your universal remote to send the commands >>> for this device. You're done. Everything will "just work" - no LIRC, >>> no irrecord, no config files, no command mapping, etc. >> You are making one big wrong assumption that everyone that has a remote >> uses mythtv, and only it. >> >> Many users including me, use the remote just like a keyboard, or even >> like a mouse. > > So let's try and figure out a "just works" scheme for doing this. What > I'm trying to do is to get everyone to step back and think about this > problem instead of rushing head long into merging LIRC as is. irrecord > is not something a non-technical user can easily handle. > > A basic scheme that can be used to eliminate configuration is to take > well known IR device profiles and emulate them in Linux. So pick > another well known device to emulate (call it A) and map it to > mouse/keyboard events. Mapping vendor/device/command codes for a > couple devices to mouse/keyboard events is a tiny amount of data and > can be done in-kernel. > > This case could also be made to "just work". Set your universal remote > to device A. Commands from for device A will arrive and be mapped into > generic keyboard/mouse commands. > > There are probably other solutions to making IR work without needing > irrecord and configuration. What would be some other possibilities? > > Also consider the long term strategy of defining standard device > profiles and getting them into the IR database. Make an IR profile for > mouse/keyboard. After this gets into the database a universal remote > can be set to this profile which will be a better match than emulating > another device. This is basically the way the current in-kernel IR drivers work. The driver converts scancodes (device address/command sequence) into an evdev standard code. Just taking an example from the dibcom0700 driver (as the same driver supports several different RC5 and NEC codes at the same time), the kernel table has several keycodes added there, all working at the same time. Providing that the scancodes won't overlap, you can map two different scancodes (from different IR's) to return the same keycode (table is not complete - I just got a few common keycodes): # SCAN Key_code # 0xeb13 KEY_RIGHT 0x1e17 KEY_RIGHT 0x1d17 KEY_RIGHT 0x860f KEY_RIGHT 0xeb11 KEY_LEFT 0x1e16 KEY_LEFT 0x1d16 KEY_LEFT 0x860e KEY_LEFT 0x0703 KEY_VOLUMEUP 0xeb1c KEY_VOLUMEUP 0x1e10 KEY_VOLUMEUP 0x037d KEY_VOLUMEUP 0x1d10 KEY_VOLUMEUP 0x8610 KEY_VOLUMEUP 0x7a12 KEY_VOLUMEUP 0x0709 KEY_VOLUMEDOWN 0xeb1e KEY_VOLUMEDOWN 0x1e11 KEY_VOLUMEDOWN 0x017d KEY_VOLUMEDOWN 0x1d11 KEY_VOLUMEDOWN 0x860c KEY_VOLUMEDOWN 0x7a13 KEY_VOLUMEDOWN 0x0706 KEY_CHANNELUP 0xeb1b KEY_CHANNELUP 0x1e20 KEY_CHANNELUP 0x0242 KEY_CHANNELUP 0x1d20 KEY_CHANNELUP 0x860d KEY_CHANNELUP 0x7a10 KEY_CHANNELUP 0x070c KEY_CHANNELDOWN 0xeb1f KEY_CHANNELDOWN 0x1e21 KEY_CHANNELDOWN 0x007d KEY_CHANNELDOWN 0x1d21 KEY_CHANNELDOWN 0x8619 KEY_CHANNELDOWN 0x7a11 KEY_CHANNELDOWN It should be noticed, however, that some devices may be provided with a shipped IR with a different keytable where the keycodes may overlap with this table. So, what we can do is to have a "default" keycode table mapping several different IR's there to be used by drivers that are shipped with an IR that can be fully mapped by the default table. However, for devices with scancodes that overlaps with the default table, we'll need a separate table. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Devin Heitmueller on 1 Dec 2009 12:20 On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab <mchehab(a)redhat.com> wrote: > Just taking an example from the dibcom0700 driver (as the same driver > supports several different RC5 and NEC codes at the same time), > the kernel table has several keycodes added there, all working > at the same time. Providing that the scancodes won't overlap, you can > map two different scancodes (from different IR's) to return the same > keycode (table is not complete - I just got a few common keycodes): Mauro, Just to be clear, the dib0700 does not actually support receiving RC5 or NEC codes at the same time. You have to tell the chip which mode to operate in, via a REQUEST_SET_RC to the firmware (see dib0700_core.c:405). The em28xx works the same way (you have to tell it what type of IR format to receive). The fact that the driver currently uses the same lookup table for both types of remote controls however, was perhaps not the best design choice. It really should be separated out, and merged with the regular ir-functions.c. I just never got around to it. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mauro Carvalho Chehab on 1 Dec 2009 12:40
Devin Heitmueller wrote: > On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab > <mchehab(a)redhat.com> wrote: >> Just taking an example from the dibcom0700 driver (as the same driver >> supports several different RC5 and NEC codes at the same time), >> the kernel table has several keycodes added there, all working >> at the same time. Providing that the scancodes won't overlap, you can >> map two different scancodes (from different IR's) to return the same >> keycode (table is not complete - I just got a few common keycodes): > > Mauro, > > Just to be clear, the dib0700 does not actually support receiving RC5 > or NEC codes at the same time. You have to tell the chip which mode > to operate in, via a REQUEST_SET_RC to the firmware (see > dib0700_core.c:405). The em28xx works the same way (you have to tell > it what type of IR format to receive). Yes, I know. I have a dib0700-based device that came with a NEC table, and I had to fix the driver to work with NEC on newer (1.20) firmwares and add the corresponding table for my NEC IR. Still I prefer to use this device with a RC5 IR from another manufacturer ;) Yet, the same table works on my device with the shipped IR and with some other RC5 IR's I have. Due to the lack of an API to select the IR standard, I need to reload the module, passing a different modprobe parameter, to set it to either mode. > The fact that the driver currently uses the same lookup table for both > types of remote controls however, was perhaps not the best design > choice. It really should be separated out, and merged with the > regular ir-functions.c. I just never got around to it. I'm not sure if splitting the table on two would be the better way. For sure we need to add an EVIOSETPROTO ioctl to allow the driver to change the protocol in runtime. If we'll keep using the same table, all an userspace app need is to say what's the desired IR mode. On the other hand, it should be easy for the application to also replace the table when a different protocol is selected. The point that I want to bold is that it is possible to use one big table to support several different IR's at the same time. This may be a good solution for devices that were shipped with more than one different IR models. It may also be a good solution to avoid having a large number of keymaps, as we may consolidate commonly used IR's on an unique table (or on a few groups of tables). Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |