Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
in [Kernel]
|
Prev: x86, crypto, Use gas macro for PCLMULQDQ-NI and PSHUFB
Next: [patch 6/8] x86: UV - XPC NULL deref when mesq becomes empty.
From: Mauro Carvalho Chehab on 26 Nov 2009 11:30 Christoph Bartelmus wrote: > Hi, > > on 25 Nov 09 at 12:44, Jarod Wilson wrote: > [...] >> Ah, but the approach I'd take to converting to in-kernel decoding[*] would >> be this: > [...] >> [*] assuming, of course, that it was actually agreed upon that in-kernel >> decoding was the right way, the only way, all others will be shot on sight. > > I'm happy to see that the discussion is getting along. > But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just > because I'm not familiar at all with input layer toolset. > > 1. For sure in-kernel decoding will require some assistance from userspace > to load the mapping from IR codes to keys. Current drivers have the IR keycode tables in-kernel also, directly associated with the board ID. > So, if there needs to be a tool > in userspace that does some kind of autodetection, why not have a tool > that does some autodetection and autoconfigures lircd for the current > device. There are userspace tools to change the IR keycode maps. It shouldn't be hard to change it to autodetect the hardware and to autoconfigure lircd. > Lots of code duplication in kernel saved. Huh? The code is already there. > What's the actual benefit of in-kernel decoding? There are two benefits: 1) the developer that adds the hardware also adds the IR code. He has the hardware and the IR for testing, so it means a faster development cycle than waiting for someone else with the same hardware and IR to recode it on some other place. You should remember that not all developers use lirc; 2) the IR works out of the box. > 2. What would be the format of the key map? lircd.conf files already exist > for a lot of remote controls. Will we have a second incompatible format to > map the keys in-kernel? Where are the tools that create the key maps for > new remotes? No matter what tool you use, the format should be very close: scancode -> key_code. If you wan to take a look on a real example, I'm enclosing the keycode table used by dib0700 driver, as generated/readed by a simple keycode application I made to test the dynamic keycode loading: http://linuxtv.org/hg/v4l-dvb/file/tip/v4l2-apps/util/keytable.c Most of the keycodes there are RC5 keys. There are also some NEC keys, as those devices can work with either RC5 or NEC keycodes, by using a different parameter during module load. In the case of this driver, the pulse/space is done in hardware by the DibCom chip. The scancode is sent to PC via the USB interface. I hope it helps for you to better understand how this works. Cheers, Mauro.
From: Jarod Wilson on 26 Nov 2009 12:30 On 11/26/2009 08:54 AM, Mauro Carvalho Chehab wrote: > Jarod Wilson wrote: >> On Nov 23, 2009, at 7:53 PM, Andy Walls wrote: >> >>> On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote: >> ... >>> I generally don't understand the LIRC aversion I perceive in this thread >>> (maybe I just have a skewed perception). Aside for a video card's >>> default remote setup, the suggestions so far don't strike me as any >>> simpler for the end user than LIRC -- maybe I'm just used to LIRC. LIRC >>> already works for both transmit and receive and has existing support in >>> applications such as MythTV and mplayer. >> >> There's one gripe I agree with, and that is that its still not plug-n-play. >> Something where udev auto-loads a sane default remote config for say, >> mceusb transceivers, and the stock mce remote Just Works would be nice, >> but auto-config is mostly out the window the second you involve transmitters >> and universal remotes anyway. > > For several devices, an udev rule that auto-loads a sane default keymap does work. > Of course, this won't cover 100% of the usages, and I lirc is a very good way > of covering the holes. > >> But outside of that, I think objections are largely philosophical -- >> in a nutshell, the kernel has an input layer, remotes are input devices, >> and lirc doesn't conform to input layer standards. > > Yes. I think this is mainly the issue. > > The other issue is how to migrate the existing drivers to a new API without > causing regressions. If we decide that IR's that receive raw pulse/code > should use the raw input interface, this means that a large task force will be > needed to convert the existing drivers to use it. Aversion to regression is definitely a major concern. And why I'm liking the idea of a hybrid approach, at least initially. > What do you think of adding lirc at staging while we discuss/improve the API's and lircd > support for the input event interface? Do you think this would work? Sure, I don't see why not. And I've got another dozen or so drivers to follow those first three... :) -- 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 26 Nov 2009 12:50 Jarod Wilson wrote: > On 11/26/2009 08:54 AM, Mauro Carvalho Chehab wrote: >> Jarod Wilson wrote: >>> On Nov 23, 2009, at 7:53 PM, Andy Walls wrote: >>> >>>> On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote: >>> ... >>>> I generally don't understand the LIRC aversion I perceive in this >>>> thread >>>> (maybe I just have a skewed perception). Aside for a video card's >>>> default remote setup, the suggestions so far don't strike me as any >>>> simpler for the end user than LIRC -- maybe I'm just used to LIRC. >>>> LIRC >>>> already works for both transmit and receive and has existing support in >>>> applications such as MythTV and mplayer. >>> >>> There's one gripe I agree with, and that is that its still not >>> plug-n-play. >>> Something where udev auto-loads a sane default remote config for say, >>> mceusb transceivers, and the stock mce remote Just Works would be nice, >>> but auto-config is mostly out the window the second you involve >>> transmitters >>> and universal remotes anyway. >> >> For several devices, an udev rule that auto-loads a sane default >> keymap does work. >> Of course, this won't cover 100% of the usages, and I lirc is a very >> good way >> of covering the holes. >> >>> But outside of that, I think objections are largely philosophical -- >>> in a nutshell, the kernel has an input layer, remotes are input devices, >>> and lirc doesn't conform to input layer standards. >> >> Yes. I think this is mainly the issue. >> >> The other issue is how to migrate the existing drivers to a new API >> without >> causing regressions. If we decide that IR's that receive raw pulse/code >> should use the raw input interface, this means that a large task force >> will be >> needed to convert the existing drivers to use it. > > Aversion to regression is definitely a major concern. And why I'm liking > the idea of a hybrid approach, at least initially. Yes. This indeed seems to be a very good idea. > >> What do you think of adding lirc at staging while we discuss/improve >> the API's and lircd >> support for the input event interface? Do you think this would work? > > Sure, I don't see why not. And I've got another dozen or so drivers to > follow those first three... :) Ok. As you said you'll do some work at the patches, could you please send us v3 in order to add it into drivers/staging? In the case of the API header file, I would tag at the header file that the API is experimental, so can be changed without prior announcements, etc (in order to avoid people to use and rely on it it outside lirc). IMO, the better is to keep such announcement there while we're still working at the hybrid approach, as we may need to change something during the development phase. Dmitry, While lirc is basically a series of input drivers, considering that they have lots in common with the input drivers at V4L/DVB and that we'll need to work on some glue to merge both, do you mind if I add the lirc drivers at drivers/staging from my trees? 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 26 Nov 2009 13:00 Krzysztof Halasa wrote: > Dmitry Torokhov <dmitry.torokhov(a)gmail.com> writes: > >> In what way the key interface is unsufficient for delivering button >> events? > > At present: 128 different keys only (RC5: one group). One remote per > device only. > > The protocol itself doesn't have the above limitations, but has others, > with are acceptable for key input. This is not a limit at the input subsystem. It were a design decision for some drivers at the V4L subsystem that we need to change. 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 26 Nov 2009 14:00
Krzysztof Halasa wrote: > Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: > >> 1) the developer that adds the hardware also adds the IR code. He has >> the hardware and the IR for testing, so it means a faster development >> cycle than waiting for someone else with the same hardware and IR to >> recode it on some other place. You should remember that not all >> developers use lirc; > > It's fine, but please - no keymaps in the kernel (except for fixed > receivers, i.e. the ones which can only work with their own dedicated > remote, and which don't pass RC5/etc. code). > > The existing keymaps (those which can be used with lirc) have to be > moved to userspace as well. The removal of the existing keymaps from kernel depends on having an application to be called from udev to load the proper keymaps when a device is probed. After having it for a while, we should deprecate the in-kernel keymaps and move them to userspace. I also think that it is important to remove the 7 bits limitation from all drivers and re-generate the keymaps, since they'll change after it. 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/ |