Another approach to IR
in [Kernel]
|
From: Jarod Wilson on 2 Dec 2009 15:50 On Dec 2, 2009, at 3:14 PM, Dmitry Torokhov wrote: > On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: >> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: >> >>> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: >>>> On 12/2/09 12:30 PM, Jon Smirl wrote: >>>>>>>> (for each remote/substream that they can recognize). >>>>>>>>> >>>>>>>>> I'm assuming that, by remote, you're referring to a remote receiver (and not to >>>>>>>>> the remote itself), right? >>>>>>> >>>>>>> If we could separate by remote transmitter that would be the best I >>>>>>> think, but I understand that it is rarely possible? >>>>> >>>>> The code I posted using configfs did that. Instead of making apps IR >>>>> aware it mapped the vendor/device/command triplets into standard Linux >>>>> keycodes. Each remote was its own evdev device. >>>> >>>> Note, of course, that you can only do that iff each remote uses distinct >>>> triplets. A good portion of mythtv users use a universal of some sort, >>>> programmed to emulate another remote, such as the mce remote bundled >>>> with mceusb transceivers, or the imon remote bundled with most imon >>>> receivers. I do just that myself. >>>> >>>> Personally, I've always considered the driver/interface to be the >>>> receiver, not the remote. The lirc drivers operate at the receiver >>>> level, anyway, and the distinction between different remotes is made by >>>> the lirc daemon. >>> >>> The fact that lirc does it this way does not necessarily mean it is the >>> most corerct way. >> >> No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way. >> >>> Do you expect all bluetooth input devices be presented >>> as a single blob just because they happen to talk to the sane receiver >>> in yoru laptop? Do you expect your USB mouse and keyboard be merged >>> together just because they end up being serviced by the same host >>> controller? If not why remotes should be any different? >> >> A bluetooth remote has a specific device ID that the receiver has to >> pair with. Your usb mouse and keyboard each have specific device IDs. >> A usb IR *receiver* has a specific device ID, the remotes do not. So >> there's the major difference from your examples. >> > > Not exactly... I can have 2 identical USB keyboadrs form the same > manufacturer and they will still be treated separately. BT has session > ID to help distinguish between devices. Semantics. :) My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which "device" some random IR input is actually coming from. >>> Now I understand that if 2 remotes send completely identical signals we >>> won't be able to separete them, but in cases when we can I think we >>> should. >> >> I don't have a problem with that, if its a truly desired feature. But >> for the most part, I don't see the point. Generally, you go from >> having multiple remotes, one per device (where "device" is your TV, >> amplifier, set top box, htpc, etc), to having a single universal >> remote that controls all of those devices. But for each device (IR >> receiver), *one* IR command set. The desire to use multiple distinct >> remotes with a single IR receiver doesn't make sense to me. Perhaps >> I'm just not creative enough in my use of IR. :) > > Didn't Jon posted his example whith programmable remote pretending to be > several separate remotes (depending on the mode of operation) so that > several devices/applications can be controlled without interfering with > each other? Yes. But that's an atypical usage, in my experience, and as Mauro said, something that can be done trivially in userspace (lirc can do this today, even for the same remote and mode of operation, on a per-key basis if you want). If it doesn't add too much complexity and people will actually use it, I don't have a problem with implementing one input device per distinct remote, but I doubt many people would use that functionality. -- Jarod Wilson jarod(a)wilsonet.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 2 Dec 2009 15:50 Jon Smirl wrote: > IR devices transmit vendor/device/command triplets. They are easy to > tell apart and create an evdev device corresponding to each > vendor/device pair or something else along those lines. What they transmit depend on the used protocol. With NEC and RC5 (currently, the most common protocols), they transmit only address (TV, VCR, SAT) and command. If you have two IR's that not fully follow RC5 standard, they may use distinct addresses. So, if you're lucky enough, you'll be able to guess the IR vendor, based on the 8 bit address code. I think that you can get the vendor only with RC6 IR's on some modes. In the case of RC6, as pointed by Andy, there are some patents envolved, meaning that we probably will need to decode it on userspace, except if someone can get the proper patent rights for its used on Linux. 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: Mauro Carvalho Chehab on 2 Dec 2009 16:00 Jon Smirl wrote: > Some major use cases: > using IR as a keyboard replacement, controlling X and apps with it in > via mouse and keyboard emulation. > using IR to control a headless embedded device possibly running > multiple apps - like audio and home automation (my app) > IR during boot when it is the only input device the box has. > multifunction remote controlling several apps > using several different remotes to control a single app I think you reasonably described the major usecases. >>> If everyone hates configfs the same mapping can be done via the set >>> keys IOCTL and making changes to the user space apps like loadkeys. >>> >> It is not the hate of configfs per se, but rather concern that configfs >> takes too much resources and is not normally enabled. > > It adds about 35K on 64b x86. 30K on 32b powerpc. If it gets turned on > by default other subsystems might start using it too. I work on an > embedded system. These arguments about non-swapable vs swapable are > pointless. Embedded systems don't have swap devices. > Of course config can be eliminated by modifying the setkeys IOCTL and > user space tools. It will require some more mods to input to allow > multiple maps monitoring the input stream and splitting them onto > multiple evdev devices. This is an equally valid way of building the > maps. > > The code I posted is just demo code. It is clearly not in shape to be > merged. Its purpose was to spark a design discussion around creating a > good long-term architecture for IR. Unfortunately, afaik, most distros don't enable configfs yet. I have to manually compile my kernel when I need some useful stuff there. I agree with Dmitry: IR is probably not enough to have this enabled by default on distros. I prefer a more traditional approach like ioctls (and/or sysfs) instead of configfs. 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: Jarod Wilson on 2 Dec 2009 16:00 On Dec 2, 2009, at 3:48 PM, Dmitry Torokhov wrote: .... >>>>>> Personally, I've always considered the driver/interface to be the >>>>>> receiver, not the remote. The lirc drivers operate at the receiver >>>>>> level, anyway, and the distinction between different remotes is made by >>>>>> the lirc daemon. >>>>> >>>>> The fact that lirc does it this way does not necessarily mean it is the >>>>> most corerct way. >>>> >>>> No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way. >>>> >>>>> Do you expect all bluetooth input devices be presented >>>>> as a single blob just because they happen to talk to the sane receiver >>>>> in yoru laptop? Do you expect your USB mouse and keyboard be merged >>>>> together just because they end up being serviced by the same host >>>>> controller? If not why remotes should be any different? >>>> >>>> A bluetooth remote has a specific device ID that the receiver has to >>>> pair with. Your usb mouse and keyboard each have specific device IDs. >>>> A usb IR *receiver* has a specific device ID, the remotes do not. So >>>> there's the major difference from your examples. >>>> >>> >>> Not exactly... I can have 2 identical USB keyboadrs form the same >>> manufacturer and they will still be treated separately. BT has session >>> ID to help distinguish between devices. >> >> Semantics. :) >> >> My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which "device" some random IR input is actually coming from. >> > > Heh, right back at ya ;) The fact that you need to do some more work > to separate 2 physical devices does not mean it should not be done. No, but it means added complexity inside the kernel. I'm questioning whether the added complexity is worth it, when I doubt the vast majority of users would take advantage of it, and it can already be done in userspace. Although... Damn. The userspace approach would only work if the device were passing raw IR to userspace, so in the in-kernel decoding case, yeah, I guess you'd need separate input devices for each remote to use them independently. Meh. Doubt I'd ever use it, but I guess I'll concede that it makes some sense to do the extra work. -- Jarod Wilson jarod(a)wilsonet.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: Dmitry Torokhov on 2 Dec 2009 16:00
On Wed, Dec 02, 2009 at 06:23:51PM -0200, Mauro Carvalho Chehab wrote: > Dmitry Torokhov wrote: > > On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: > >> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: > >>> Now I understand that if 2 remotes send completely identical signals we > >>> won't be able to separete them, but in cases when we can I think we > >>> should. > >> I don't have a problem with that, if its a truly desired feature. But > >> for the most part, I don't see the point. Generally, you go from > >> having multiple remotes, one per device (where "device" is your TV, > >> amplifier, set top box, htpc, etc), to having a single universal > >> remote that controls all of those devices. But for each device (IR > >> receiver), *one* IR command set. The desire to use multiple distinct > >> remotes with a single IR receiver doesn't make sense to me. Perhaps > >> I'm just not creative enough in my use of IR. :) > > > > Didn't Jon posted his example whith programmable remote pretending to be > > several separate remotes (depending on the mode of operation) so that > > several devices/applications can be controlled without interfering with > > each other? > > > From what I understood, he is using the same physical remote, but creating different > IR groups of keys on it, each group meant to be used by a different application. > > For such usage, some software will need to filter the scancode group and send > them only for a certain application. This can be done easily by using lirc, > purely in userspace. > > Another alternative (that will also work for multimedia keys on a keyboard) is > to add a filtering subsystem at evdev that will send certain events for just certain > PID's. They are the same key events (Lets's say KEY_PLAY) but one is supposed to affect CD player while another DVD player application. Evdev will not be able to distinguish them but if we had 2 separate devices then applications could read from the one thet user assigned to them. However even subscription is something that is desirable to have ouside of IRC handling topic (so that supporting applications need not be woken up by events they are not interested in - example mixer application is interested in KEY_VOLUMEUP, KEY_VOLUMEDOWN and KEY_MUTE but not any other key that may be emitted by a keyboard). -- Dmitry -- 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/ |