Another approach to IR
in [Kernel]
|
From: Trent Piepho on 2 Dec 2009 16:20 On Wed, 2 Dec 2009, Jarod Wilson wrote: > >> > >> 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. You just need to send a tuple that contrains the keycode plus some kind of id for the remote it came from. That's what I did for lirc, it decodes the sparc/mark into a remote id and key code tuple. It's certainly a common thing to want. Anyone who has existing remotes and components that use them would want it. You don't want your computer turning off when you push the power button on the DVD player's remote, do you? Each host connected to a network interface doesn't get its own device. -- 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:20 Dmitry Torokhov wrote: > 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. This is clear, but the point is that the two distinguish scancodes can (and, in practice, will) be generated by the same IR. For example, my Satellite IR produces two different sets of codes. if you press <SAT>, all keys you press after that will have the "sat" address. If you press <TV>, they'll get a different address. So, the needed feature is not to really distinguish two different IR's, but to allow to create groups of scancodes that will be directed to a distinct interface. I won't object about such interface, but the default should be to have just one interface and having all conversion applied to that interface. Maybe we can have a separate module for IR evdev filtering to fulfill this need. Basically, such module will get the events from one input interface and create an arbitrary number of evdev devices, and will apply different scancode->keycode tables for each different interfaces. I don't see why to limit the input interface to be IR. It can eventually be any input interface (bluetooth, keyboard, PS/3 control, Wii control, ...). 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:30 On Dec 2, 2009, at 4:12 PM, Trent Piepho wrote: > On Wed, 2 Dec 2009, Jarod Wilson wrote: >>>> >>>> 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. > > You just need to send a tuple that contrains the keycode plus some kind of > id for the remote it came from. That's what I did for lirc, it decodes the > sparc/mark into a remote id and key code tuple. It's certainly a common > thing to want. Anyone who has existing remotes and components that use > them would want it. What for, exactly? > You don't want your computer turning off when you push > the power button on the DVD player's remote, do you? No, I don't. Perhaps we should clarify something here. Are we intending to auto-create a new input device for every IR command set we see arrive at the IR receiver? I've been assuming we're not going to willy-nilly just auto-create a new device for every IR signal we happen to catch passing by. The receiver should only be passing along input events for the codeset/remote I've told it to listen for (which by default, is the codes for the receiver's bundled remote). Otherwise, yeah, I'm going to wind up with my htpc powering off when I hit the button on my harmony remote that is supposed to turn off my tv and amp. -- 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 16:50 Jarod Wilson wrote: > On Dec 2, 2009, at 4:12 PM, Trent Piepho wrote: > >> On Wed, 2 Dec 2009, Jarod Wilson wrote: >>>>> 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. >> You just need to send a tuple that contrains the keycode plus some kind of >> id for the remote it came from. That's what I did for lirc, it decodes the >> sparc/mark into a remote id and key code tuple. It's certainly a common >> thing to want. Anyone who has existing remotes and components that use >> them would want it. > > What for, exactly? > >> You don't want your computer turning off when you push >> the power button on the DVD player's remote, do you? > > No, I don't. In this specific case, IMO, the default keytables should map the power button to KEY_POWER2. > > Perhaps we should clarify something here. Are we intending to auto-create > a new input device for every IR command set we see arrive at the IR receiver? > I've been assuming we're not going to willy-nilly just auto-create a new device > for every IR signal we happen to catch passing by. The receiver should only > be passing along input events for the codeset/remote I've told it to listen > for (which by default, is the codes for the receiver's bundled remote). Yes, but several bundled IR's have a power button. By default, it doesn't make sense to use it to turn the machine off, so KEY_POWER2 is a good option. > Otherwise, yeah, I'm going to wind up with my htpc powering off when > I hit the button on my harmony remote that is supposed to turn off my tv and amp. 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: Jon Smirl on 2 Dec 2009 19:30
On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson <jarod(a)wilsonet.com> 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. Actually remotes do have an ID. They all transmit vendor/device pairs which is exactly how USB works. > >> Now I understand that if 2 remotes send completely identical signals we >> won't be able to separate 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. :) > > -- > Jarod Wilson > jarod(a)wilsonet.com > > > > -- 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/ |