What are the goals for the architecture of an in-kernel IR system?
in [Kernel]
|
Prev: backlight: tdo24m: ensure chip select changes between transfers
Next: 2.6.31.5 x86-64 KVM: 'emulation failed (pagetable) rip 7fb49335da7b 66 0f 7f 07'
From: Dmitry Torokhov on 3 Dec 2009 13:00 On Thu, Dec 03, 2009 at 01:09:14PM +0100, Gerd Hoffmann wrote: > On 12/03/09 05:29, Jarod Wilson wrote: >> On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote: >> >>>> Anyway, we shouldn't postpone lirc drivers addition due to that. >>>> There are still lots of work to do before we'll be able to split >>>> the tables from the kernel drivers. >>> >>> Indeed. The sysfs bits are future work for both lirc and evdev >>> drivers. There is no reason to make the lirc merge wait for it. >> >> At this point, my plan is to try to finish cleaning up lirc_dev and >> lirc_mceusb at least over the weekend while at FUDCon up in Toronto, >> and resubmit them next week. > > Good plan IMHO. Having lirc_dev merged quickly allows in-kernel drivers > start supporting lirc. No, please, wait just a minute. I know it is tempting to just merge lirc_dev and start working, but can we first agree on the overall subsystem structure before doing so. It is still quite inclear to me. The open questions (for me at least): - do we create a new class infrastructure for all receivers or only for ones plugged into lirc_dev? Remember that classifying objects affects how udev and friemds see them and may either help or hurt writing PnP rules. - do we intend to support in-kernel sotfware decoders? What is the structure? Do we organize them as a module to be used by driver directly or the driver "streams" the data to IR core and the core applies decoders (in the same fashion input events from drivers flow into input core and then distributed to all bound interfaces for processing/conversion/transmission to userspace)? - how do we control which decoder should handle particular receiver/remote? Is it driver's decision, decoder's decision, user's or all of the above? - do we allow to have several decorers active at once for a receiver? - who decides that we want to utilize lirc_dev? Driver's themselves, IR core (looking at the driver/device "capabilities"), something else? - do we recognize and create input devices "on-fly" or require user intervention? Semantics for splitting into several input/event devices? Could anyone please draw me a picture, starting with a "receiver" piece of hardware. I am not concerned much with how exactly receiver is plugged into a particular subsystem (DVB/V4L etc) since it would be _their_ implementation detail, but with the flow in/out of that "receiver" device. Now as far as input core goes I see very limited number of changes that may be needed: - Allow to extend size of "scancode" in EVIOC{S,G}KEYCODE if we are unable to limit ourselves to 32 bits (keeping compatibility of course) - Maybe adding new ioctl to "zap" the keymap table - Adding more key EV_KEY/KEY_* definitons, if needed Thanks. -- 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: Dmitry Torokhov on 3 Dec 2009 17:20 On Thu, Dec 03, 2009 at 10:51:00PM +0100, Christoph Bartelmus wrote: > 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. 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. -- 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: Dmitry Torokhov on 4 Dec 2009 05:10 On Thu, Dec 03, 2009 at 04:33:28PM -0200, Mauro Carvalho Chehab wrote: > Let me draw my view: > > Em Thu, 3 Dec 2009 09:55:31 -0800 > Dmitry Torokhov <dmitry.torokhov(a)gmail.com> escreveu: > > > No, please, wait just a minute. I know it is tempting to just merge > > lirc_dev and start working, but can we first agree on the overall > > subsystem structure before doing so. It is still quite inclear to me. > > > > The open questions (for me at least): > > > > - do we create a new class infrastructure for all receivers or only for > > ones plugged into lirc_dev? Remember that classifying objects affects > > how udev and friemds see them and may either help or hurt writing PnP > > rules. > > IMO, I would create it as /sys/class/input/IR (just like the /mice). I That will not work. Driver core does not support notion of subclasses, Greg and Kay insist on flat class namespace. Mice do not belong to a separate [sub]class, they all members of input class, with peculiar directory structure. IRs however, I believe, deserve a full-fledged class (since they are in my view are parents to the input devices representing remotes). I would argus for the following sysfs hierarchy for the main device tree: /sys/devices/pcipci0000:00/../pci.../../irrcv0/input14/event16 /sys/devices/pcipci0000:00/../usb.../../irrcv1/input15/event17 /input16/event18 And corresponding class: /sys/class/irrcv/irrcv0 irrcv1 and so on. > > don't see why do we need to different lirc than no-lirc drivers in the > case of sysfs class. I do agree that _all_ infrared receivers should belong to this class, and not only ones utilizing lirc_dev. > As devices with raw input capabilities will have > another dev to communicate, this means that we'll need a /lirc node > there to point to lirc dev. > > > > > - do we intend to support in-kernel sotfware decoders? > > Yes. > Good. > > - What is the structure? Do we organize them as a module to be used by driver > > directly or the driver "streams" the data to IR core and the core > > applies decoders (in the same fashion input events from drivers flow > > into input core and then distributed to all bound interfaces for > > processing/conversion/transmission to userspace)? > > My plan is to expand ir-common.ko module and rename it to ir-core, to be > the IR core module for the evdev interface. I'm already working on it. > My idea for an architecture is that the lirc-core module will use > ir-common where the IR decoders will be, and the evdev interface. > How related lirc-core to the current lirc code? If it is not the same maybe we should not call it lirc to avoid confusion. > IMO, we should move them from /drivers/media/common to /drivers/input/ir. > It makes sense to use kfifo to send the data to the in-kernel decoders. > OK. > > - how do we control which decoder should handle particular > > receiver/remote? Is it driver's decision, decoder's decision, user's > > or all of the above? > > It should be all the above, since some hardware will only work with certain > decoders (hardware limitation) or they may have already a raw mode->scancode > legacy decoder. In the latter case, those decoders will be removed from > the existing drivers, but this action will take some time. > > Some sysfs attributes are needed to specify a list of the supported protocols > and the currently used one. I'll prepare a proposed patch for it, after we > finish aligning the requirements. > > > - do we allow to have several decorers active at once for a receiver? > > Yes, as an optional requirement, since some hardware won't support it. > > > - who decides that we want to utilize lirc_dev? Driver's themselves, IR > > core (looking at the driver/device "capabilities"), something else? > > Drivers that support raw mode, should interface via lirc-core, that will, > in turn use ir-core. > > Drivers that have in-hardware decode will directly use ir-core. > > > - do we recognize and create input devices "on-fly" or require user > > intervention? Semantics for splitting into several input/event > > devices? > > I don't have a strong opinion here. > > I don't see any way for doing it, except with very few protocols that > sends vendor IDs. I don't care if this feature can be used by the > drivers/decoders that could support it. > > > Could anyone please draw me a picture, starting with a "receiver" > > piece of hardware. I am not concerned much with how exactly receiver is > > plugged into a particular subsystem (DVB/V4L etc) since it would be > > _their_ implementation detail, but with the flow in/out of that > > "receiver" device. > > Not sure if I got your idea. Basically, what I see is: > > For device drivers that work in raw mode: > [IR physical device] ==> [IR receiver driver] ==> [lirc-core] ==> [decoder] ==> [ir-core] ==> [evdev] > > (eventually, we can merge decoder and ir-core into one module at the beginning, > depending on the size of the decoders) > > For device drivers that work only in evdev mode (those with hardware decoders): > > [IR physical device] ==> [IR receiver driver] ==> [ir-core] ==> [evdev] > Maybe we are talking about the same things and it is just names that are confusing. I'd imagine something like this: In-kernel decoding: [IR physical device] => [IR receiver driver] => [IR core] => [decoder] => [input core] => [evdev] => [decoder] => [input core] => [evdev] Hardware decoder: [IR physical device] => [IR receiver driver] => [IR core] => [input core] => [evdev] I.e we still register with IR core but driver communicates directly with input device. Userspace decoging: [IR physical device] => [IR receiver driver] => [IR core] => [lirc_dev] => [lircd] => [uinput] => [input core] => [evdev] Essentially lirc_dev becomes a special case of decoder that, instead of connecting inptu core and creating input devices passes the data to userspace. I did not show the block that you call ir-core since I expect it to be more like a library rather than an object in overall structure. > > > > Now as far as input core goes I see very limited number of changes that > > may be needed: > > > > - Allow to extend size of "scancode" in EVIOC{S,G}KEYCODE if we are > > unable to limit ourselves to 32 bits (keeping compatibility of course) > > Yes, but the way EVIOC{S,G}KEYCODE currently works, it performs poorly when you have a > table with 2^64 size. The table is very sparsed, but, as the key to get/set a code is > the scancode, it is very hard to enumberate what are the actual entries there. The > better is to use an index parameter for they, instead of using the scancode as such. > evdev does not really care what you use as scancode. So nobody stops your driver to report index as a scancode and accept index from the ioctl. The true "scancode" will thus be competely hidden from userspace. In fact a few drivers do just that. -- 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: Dmitry Torokhov on 4 Dec 2009 17:10 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. -- 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: Dmitry Torokhov on 4 Dec 2009 18:20
On Sat, Dec 05, 2009 at 12:01:00AM +0100, Christoph Bartelmus wrote: > 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. > I suppose we could add MSC_SCAN_END event so that we can transmit "scancodes" of arbitrary length. You'd get several MSC_SCAN followed by MSC_SCAN_END marker. If you don't get MSC_SCAN_END assume the code is 32 bit. FWIW there is MSC_RAW as well. -- 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/ |