What are the goals for the architecture of an in-kernel IR system?
in [Kernel]
|
Prev: [PATCH 2/3] sched: make tunable scaling style configurable
Next: [PATCH] pata_rdc: MWDMA0 is unsupported
From: Krzysztof Halasa on 3 Dec 2009 12:50 Gerd Hoffmann <kraxel(a)redhat.com> writes: > I'd pick a more descriptive name like 'bundled_remote'. > Maybe an additional attribute could say which protocol the bundled > remote speaks (rc5, ...), so userspace could do something sensible by > default even if it has no data about the bundled remote. This is problematic since there can be more that one remote bundled. If we export the sensor (tuner etc) name, userspace can make some decision (or ask the user etc). The protocol alone won't help - the user will have to teach the system about the remote anyway. This should be made trivial at least for common protocols, though. > Name them by the hardware they are bundled with should work reasonable > well. I guess udev can look at parent PCI vendor/device and subsystem vendor/device for most PCI cases. Ditto with USB. For generic stuff like TSOP* coupled with a resistor and connected to RS232 port, we can't guess anyway. > We also could also provide a list of possible remotes directly via > sysfs The kernel has no way to _know_ this information. The policy is better handled in userland. >> Anyway, we shouldn't postpone lirc drivers addition due to that. Actually merging lirc is a prerequisite for a number of changes. -- Krzysztof Halasa -- 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: Christoph Bartelmus on 3 Dec 2009 17:00 Hi Mauro, on 03 Dec 09 at 19:10, Mauro Carvalho Chehab wrote: [...] >>> So the lirc_imon I submitted supports all device types, with the >>> onboard decode devices defaulting to operating as pure input devices, >>> but an option to pass hex values out via the lirc interface (which is >>> how they've historically been used -- the pure input stuff I hacked >>> together just a few weeks ago), to prevent functional setups from >>> being broken for those who prefer the lirc way. >> >> Hmm. I'd tend to limit the lirc interface to the 'raw samples' case. >> Historically it has also been used to pass decoded data (i.e. rc5) from >> devices with onboard decoding, but for that in-kernel mapping + input >> layer really fits better. > I agree. Consider passing the decoded data through lirc_dev. - there's a large user base already that uses this mode through lirc and would be forced to switch to input layer if it disappears. - that way all IR drivers would consistently use lirc interface and all PnP hooks could be implemented there in one place. - drivers like lirc_imon that have to support both raw and decoded mode, currently have to implement both the lirc and the input interface. Complexity could be reduced in such cases. But maybe this is necessary anyway for lirc_imon that also includes mouse functionality. Jarod? Christoph -- 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: Christoph Bartelmus on 4 Dec 2009 02:40 Hi Dmitry, on 03 Dec 09 at 14:12, Dmitry Torokhov wrote: [...] >> Consider passing the decoded data through lirc_dev. [...] > I believe it was agreed that lirc-dev should be used mainly for decoding > protocols that are more conveniently decoded in userspace and the > results would be looped back into input layer through evdev which will > be the main interface for consumer applications to use. Quoting myself: > Currently I would tend to an approach like this: > - raw interface to userspace using LIRC For me this includes both the pulse/space data and also the scan codes when hardware does the decoding. Consider cases like this: http://lirc.sourceforge.net/remotes/lg/6711A20015N This is an air-conditioner remote. The entries that you see in this config file are not really separate buttons. Instead the remote just sends the current settings for e.g. temperature encoded in the protocol when you press some up/down key. You really don't want to map all possible temperature settings to KEY_* events. For such cases it would be nice to have access at the raw scan codes from user space to do interpretation of the data. The default would still be to pass the data to the input layer, but it won't hurt to have the possibility to access the raw data somehow. Christoph -- 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: Christoph Bartelmus on 4 Dec 2009 16:50 Hi Mauro, on 04 Dec 09 at 12:33, Mauro Carvalho Chehab wrote: > Christoph Bartelmus wrote: >>>> Consider passing the decoded data through lirc_dev. [...] >> Consider cases like this: >> http://lirc.sourceforge.net/remotes/lg/6711A20015N >> >> This is an air-conditioner remote. >> The entries that you see in this config file are not really separate >> buttons. Instead the remote just sends the current settings for e.g. >> temperature encoded in the protocol when you press some up/down key. You >> really don't want to map all possible temperature settings to KEY_* >> events. For such cases it would be nice to have access at the raw scan >> codes from user space to do interpretation of the data. >> The default would still be to pass the data to the input layer, but it >> won't hurt to have the possibility to access the raw data somehow. > Interesting. IMHO, the better would be to add an evdev ioctl to return the > scancode for such cases, instead of returning the keycode. That means you would have to set up a pseudo keymap, so that you can get the key event which you could than react on with a ioctl. Or are you generating KEY_UNKNOWN for every scancode that is not mapped? What if different scan codes are mapped to the same key event? How do you retrieve the scan code for the key event? I don't think it can work this way. Christoph -- 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: Christoph Bartelmus on 4 Dec 2009 18:10
Hi Dmitry, on 04 Dec 09 at 14:07, Dmitry Torokhov wrote: > On Fri, Dec 04, 2009 at 10:46:00PM +0100, Christoph Bartelmus wrote: >> Hi Mauro, >> >> on 04 Dec 09 at 12:33, Mauro Carvalho Chehab wrote: >>> Christoph Bartelmus wrote: >>>>>> Consider passing the decoded data through lirc_dev. >> [...] >>>> Consider cases like this: >>>> http://lirc.sourceforge.net/remotes/lg/6711A20015N >>>> >>>> This is an air-conditioner remote. >>>> The entries that you see in this config file are not really separate >>>> buttons. Instead the remote just sends the current settings for e.g. >>>> temperature encoded in the protocol when you press some up/down key. You >>>> really don't want to map all possible temperature settings to KEY_* >>>> events. For such cases it would be nice to have access at the raw scan >>>> codes from user space to do interpretation of the data. >>>> The default would still be to pass the data to the input layer, but it >>>> won't hurt to have the possibility to access the raw data somehow. >> >>> Interesting. IMHO, the better would be to add an evdev ioctl to return the >>> scancode for such cases, instead of returning the keycode. >> >> That means you would have to set up a pseudo keymap, so that you can get >> the key event which you could than react on with a ioctl. Or are you >> generating KEY_UNKNOWN for every scancode that is not mapped? >> What if different scan codes are mapped to the same key event? How do you >> retrieve the scan code for the key event? >> I don't think it can work this way. >> > EV_MSC/MSC_SCAN. How would I get the 64 bit scan codes that the iMON devices generate? How would I know that the scan code is 64 bit? input_event.value is __s32. BTW, I just came across a XMP remote that seems to generate 3x64 bit scan codes. Anyone here has docs on the XMP protocol? Christoph -- 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/ |