Another approach to IR
in [Kernel]
|
From: Mauro Carvalho Chehab on 2 Dec 2009 14:40 Dmitry Torokhov wrote: >> The raw interface applies only to the devices that doesn't have a hardware decoder >> (something between 40%-60% of the currently supported devices). > > 50% is quite a number I think. But if driver does not allow access to > the raw stream - it will refuse binding to lirc_dev interface. Ok. > We need to cater to the future cases as well. I don't want to redesign > it in 2 years. But for devices that have only hardware decoders I > suppose we can short-curcuit "interfaces" and have a library-like module > creating input devices directly. We really need only one interface for those devices. However, protocol selection is needed, as it is associated with the scantable on those devices. a sysfs entry would solve this issue. Also, we need a better schema to cleanup the keycode table. Currently, the only way I'm aware is to run a loop from 0 to 65535 associating a scancode to KEY_UNKNOWN or to KEY_RESERVED. >> In the case of the cheap devices with just raw interfaces, running in-kernel >> decoders, while it will work if you create one interface per protocol >> per IR receiver, this also seems overkill. Why to do that? It sounds that it will >> just create additional complexity at the kernelspace and at the userspace, since >> now userspace programs will need to open more than one device to receive the >> keycodes. > > _Yes_!!! You open as many event devices as there are devices you are > interested in receiving data from. Multiplexing devices are bad, bad, > bad. Witness /dev/input/mouse and all the attempts at working around the > fact that if you have a special driver for one of your devices you > receive events from the same device through 2 interfaces and all kind of > "grab", "super-grab", "smart-grab" schemes are born. The only device that the driver can actually see is the IR receiver. There's no way to know if there is only one physical IR sending signals to it or several different models, especially if we consider that programmable IR's can be able even to generate more than one protocol at the same time, and can emulate other IR types. You might create some artificial schema to try to deal with different IR's being received at the same IR receiver, but, IMHO, this will just add a complex abstraction layer. Also, this won't give any real gain, as either both IR's will generate the same scancodes (and you can't distinguish what IR generated that code), or the scancode is different, and you can handle it differently. >>> (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? IMHO, the better is to use a separate interface for the IR transmitters, on the devices that support this feature. There are only a few devices I'm aware of that are able to transmit IR codes. 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 15:00 On Wed, Dec 2, 2009 at 2:50 PM, Jon Smirl <jonsmirl(a)gmail.com> wrote: > On Wed, Dec 2, 2009 at 2:33 PM, Mauro Carvalho Chehab > <mchehab(a)redhat.com> wrote: >> Dmitry Torokhov wrote: >>>> The raw interface applies only to the devices that doesn't have a hardware decoder >>>> (something between 40%-60% of the currently supported devices). >>> >>> 50% is quite a number I think. But if driver does not allow access to >>> the raw stream - it will refuse binding to lirc_dev interface. >> >> Ok. >> >>> We need to cater to the future cases as well. I don't want to redesign >>> it in 2 years. But for devices that have only hardware decoders I >>> suppose we can short-curcuit "interfaces" and have a library-like module >>> creating input devices directly. >> >> We really need only one interface for those devices. However, protocol selection >> is needed, as it is associated with the scantable on those devices. >> a sysfs entry would solve this issue. >> >> Also, we need a better schema to cleanup the keycode table. Currently, the only way >> I'm aware is to run a loop from 0 to 65535 associating a scancode to KEY_UNKNOWN or >> to KEY_RESERVED. >> >>>> In the case of the cheap devices with just raw interfaces, running in-kernel >>>> decoders, while it will work if you create one interface per protocol >>>> per IR receiver, this also seems overkill. Why to do that? It sounds that it will >>>> just create additional complexity at the kernelspace and at the userspace, since >>>> now userspace programs will need to open more than one device to receive the >>>> keycodes. >>> >>> _Yes_!!! You open as many event devices as there are devices you are >>> interested in receiving data from. Multiplexing devices are bad, bad, >>> bad. Witness /dev/input/mouse and all the attempts at working around the >>> fact that if you have a special driver for one of your devices you >>> receive events from the same device through 2 interfaces and all kind of >>> "grab", "super-grab", "smart-grab" schemes are born. >> >> The only device that the driver can actually see is the IR receiver. There's no way to >> know if there is only one physical IR sending signals to it or several different models, >> especially if we consider that programmable IR's can be able even to generate more than one >> protocol at the same time, and can emulate other IR types. > > 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. I forgot about fixed function receivers - ones that only receive codes from a specific vendor/device pair and decode them in hardware. Those devices would just create a fixed entry in the configfs which would then allow a keycode mapping to be loaded. Or a parallel scheme for setkeys IOCTL. These device can only receive from a single remote. > > If I tell a programmable remote to send out the same commands as my > Sony remote that's the same thing as owning two identical Sony > remotes. I'd expect them to be indistinguishable. If you want to be > able to tell your remotes apart, don't program them to emulate each > other. > > I've published code that can split these devices apart, it's not > impossible to do. > > 802.11 receivers have the same problem, there is one receiver and many > transmitters. The networking code doesn't have problems with sorting > this out and separating the streams. > >> You might create some artificial schema to try to deal with different IR's being received >> at the same IR receiver, but, IMHO, this will just add a complex abstraction layer. >> >> Also, this won't give any real gain, as either both IR's will generate the same scancodes (and you can't distinguish what IR generated that code), or the scancode is different, and you >> can handle it differently. > > Reusing the keycode is fine if they on different evdev devices. A key > feature is creating one evdev device for each remote. > >> >>>>> (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? >> >> IMHO, the better is to use a separate interface for the IR transmitters, >> on the devices that support this feature. There are only a few devices >> I'm aware of that are able to transmit IR codes. >> >> Cheers, >> Mauro. >> >> > > > > -- > Jon Smirl > jonsmirl(a)gmail.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/
From: Jarod Wilson on 2 Dec 2009 15:00 On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote: > Dmitry Torokhov 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? > > IMHO, the better is to use a separate interface for the IR transmitters, > on the devices that support this feature. There are only a few devices > I'm aware of that are able to transmit IR codes. If I'm thinking clearly, there are only three lirc kernel drivers that support transmit, lirc_mceusb, lirc_zilog and lirc_serial. The mceusb driver was posted, so I won't rehash what it is here. The zilog driver binds to a Zilog z80 microprocessor thingy (iirc) exposed via i2c, found on many Hauppauge v4l/dvb devices (PVR-150, HVR-1600, HD-PVR, etc). The serial driver is fairly self-explanatory as well. There are also a few userspace-driven devices that do transmit, but I'm assuming they're (currently) irrelevant to this discussion. -- 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 15:00 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. 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? 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. -- 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/
From: Jon Smirl on 2 Dec 2009 15:00
On Wed, Dec 2, 2009 at 2:33 PM, Mauro Carvalho Chehab <mchehab(a)redhat.com> wrote: > Dmitry Torokhov wrote: >>> The raw interface applies only to the devices that doesn't have a hardware decoder >>> (something between 40%-60% of the currently supported devices). >> >> 50% is quite a number I think. But if driver does not allow access to >> the raw stream - it will refuse binding to lirc_dev interface. > > Ok. > >> We need to cater to the future cases as well. I don't want to redesign >> it in 2 years. But for devices that have only hardware decoders I >> suppose we can short-curcuit "interfaces" and have a library-like module >> creating input devices directly. > > We really need only one interface for those devices. However, protocol selection > is needed, as it is associated with the scantable on those devices. > a sysfs entry would solve this issue. > > Also, we need a better schema to cleanup the keycode table. Currently, the only way > I'm aware is to run a loop from 0 to 65535 associating a scancode to KEY_UNKNOWN or > to KEY_RESERVED. > >>> In the case of the cheap devices with just raw interfaces, running in-kernel >>> decoders, while it will work if you create one interface per protocol >>> per IR receiver, this also seems overkill. Why to do that? It sounds that it will >>> just create additional complexity at the kernelspace and at the userspace, since >>> now userspace programs will need to open more than one device to receive the >>> keycodes. >> >> _Yes_!!! You open as many event devices as there are devices you are >> interested in receiving data from. Multiplexing devices are bad, bad, >> bad. Witness /dev/input/mouse and all the attempts at working around the >> fact that if you have a special driver for one of your devices you >> receive events from the same device through 2 interfaces and all kind of >> "grab", "super-grab", "smart-grab" schemes are born. > > The only device that the driver can actually see is the IR receiver. There's no way to > know if there is only one physical IR sending signals to it or several different models, > especially if we consider that programmable IR's can be able even to generate more than one > protocol at the same time, and can emulate other IR types. 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. If I tell a programmable remote to send out the same commands as my Sony remote that's the same thing as owning two identical Sony remotes. I'd expect them to be indistinguishable. If you want to be able to tell your remotes apart, don't program them to emulate each other. I've published code that can split these devices apart, it's not impossible to do. 802.11 receivers have the same problem, there is one receiver and many transmitters. The networking code doesn't have problems with sorting this out and separating the streams. > You might create some artificial schema to try to deal with different IR's being received > at the same IR receiver, but, IMHO, this will just add a complex abstraction layer. > > Also, this won't give any real gain, as either both IR's will generate the same scancodes (and you can't distinguish what IR generated that code), or the scancode is different, and you > can handle it differently. Reusing the keycode is fine if they on different evdev devices. A key feature is creating one evdev device for each remote. > >>>> (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? > > IMHO, the better is to use a separate interface for the IR transmitters, > on the devices that support this feature. There are only a few devices > I'm aware of that are able to transmit IR codes. > > Cheers, > Mauro. > > -- 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/ |