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: Jarod Wilson on 26 Nov 2009 21:30 On 11/26/2009 06:23 PM, Dmitry Torokhov wrote: > On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote: >> On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote: >> >>> On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote: >>>> On 11/23/2009 12:37 PM, Dmitry Torokhov wrote: >>>>> On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote: >>>>>> Mauro Carvalho Chehab<mchehab(a)redhat.com> writes: >>>>>> >>>>>>> Event input has the advantage that the keystrokes will provide an unique >>>>>>> representation that is independent of the device. >>>>>> >>>>>> This can hardly work as the only means, the remotes have different keys, >>>>>> the user almost always has to provide customized key<>function mapping. >>>>>> >>>>> >>>>> Is it true? I would expect the remotes to have most of the keys to have >>>>> well-defined meanings (unless it is one of the programmable remotes)... >>>> >>>> Its the cases like programmable universal remotes that really throw >>>> things for a loop. That, and people wanting to use random remote X that >>>> came with the amp or tv or set top box, with IR receiver Y. >>> >>> Right, but still the keys usually do have the well-defined meaning, >> >> Except when they don't. I have two very similar remotes, one that was bundled with a system from CaptiveWorks, and one that was bundled with an Antec Veris IR/LCD (SoundGraph iMON rebrand). Outside of the Antec remote having a mouse pad instead of up/down/left/right/enter, they have an identical layout, and the keys in the same locations on the remotes send the same IR signal. But the button names vary a LOT between the two. So on the DVD key on the Antec and the MUTE key on the CW send the same signal. Same with Audio vs. Eject, TV vs. History, etc. Moral of the story is that not all IR protocols spell things out particularly well for what a given code should actually mean. > > I guess we are talking about different things. While the 2 remotes may > use different protocols to communicate The remotes use the exact same protocol. Their respective bundled receivers however, do translate key presses differently. Perhaps this is a bad example though, because both of these remotes came with receivers that do onboard decoding. But there's nothing stopping me from wanting to use either of these remotes with an mceusb IR transceiver. > and may use the same codes to > mean different things they buttons have well-defined meaning and we > could map that to input keycodes. Then what is left is to load the > proper mapping for particular device into the kernel. In this case, its not the device, but the remote, that we need a different mapping for. > This can be done > either automatically (when we know the mapping) or with the help of the > user (owner of the system). Yep, that'd work. Just trying to illustrate that the same code doesn't always mean anywhere near the same thing from one remote to another. >>> teh >>> issue is in mapping raw code to the appropriate keycode. This can be >>> done either by lirc config file (when lirc is used) or by some other >>> means. >> >> The desire to map a button press to multiple keystrokes isn't uncommon either, though I presume that's doable within the input layer context too. > > No, at present we expect 1:1 button->event mapping leaving macro > expansion (i.e. KEY_PROG1 -> "do some multi-step sequence" to > userspace). Hm. So ctrl-x, alt-tab, etc. would have to be faked in userspace somehow. Bummer. -- 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: Christoph Bartelmus on 27 Nov 2009 03:00 Hi Jon, on 27 Nov 09 at 00:06, Jon Smirl wrote: [...] > code for the fun of it, I have no commercial interest in IR. I was > annoyed with how LIRC handled Sony remotes on my home system. Can you elaborate on this? I'm not aware of any issue with Sony remotes. 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: Mauro Carvalho Chehab on 27 Nov 2009 21:50 Em Thu, 26 Nov 2009 17:06:03 -0200 Mauro Carvalho Chehab <mchehab(a)redhat.com> escreveu: > Krzysztof Halasa wrote: > > Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: > > > >> Technically, it is not hard to port this solution to the other > >> drivers, but the issue is that we don't have all those IR's to know > >> what is the complete scancode that each key produces. So, the hardest > >> part is to find a way for doing it without causing regressions, and to > >> find a group of people that will help testing the new way. > > > > We don't want to "port it" to other drivers. We need to have a common > > module which does all RCx decoding. The individual drivers should be as > > simple as possible, something that I outlined in a previous mail. > > With the current 7bits mask applied to almost all devices, it is probably not very > useful for those who want to use generic IRs. We really need to port the solution > we've done on dvb-usb to the other drivers, allowing them to have the entire > scancode at the tables while keep supporting table replacement. > > The issue is that we currently have only 7bits of the scan codes produced by the IR's. > So, we need to re-generate the keycode tables for each IR after the changes got applied. Ok, I got some time to add support for tables with the full scan codes at the V4L drivers. In order to not break all tables, I've confined the changes to just one device (HVR-950, at the em28xx driver). The patches were already committed at the -hg development tree. In order to support tables with the full scan codes, all that is needed is to add the RC5 address + RC5 data when calling ir_input_keydown. So, the change is as simple as: - ir_input_keydown(ir->input, &ir->ir, - poll_result.rc_data[0]); + ir_input_keydown(ir->input, &ir->ir, + poll_result.rc_address << 8 | + poll_result.rc_data[0]); + else An example of such patch can be seen at: http://linuxtv.org/hg/v4l-dvb/rev/9c38704cfd56 There are still some work to do, since, currently, the drivers will use a table with a fixed size. So, you can replace the current values, but it is not possible to add new keys. The fix for it is simple, but we need to think what would be the better way for it. There are two alternatives: - A table with a fixed size (like 128 or 256 entries - maybe a modprobe parameter could be used to change its size); - some way to increase/reduce the table size. In this case, we'll likely need some ioctl for 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/
From: Mauro Carvalho Chehab on 28 Nov 2009 04:50 Dmitry Torokhov wrote: > On Sat, Nov 28, 2009 at 12:39:18AM -0200, Mauro Carvalho Chehab wrote: >> Em Thu, 26 Nov 2009 17:06:03 -0200 >> Mauro Carvalho Chehab <mchehab(a)redhat.com> escreveu: >> >>> Krzysztof Halasa wrote: >>>> Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: >>>> >>>>> Technically, it is not hard to port this solution to the other >>>>> drivers, but the issue is that we don't have all those IR's to know >>>>> what is the complete scancode that each key produces. So, the hardest >>>>> part is to find a way for doing it without causing regressions, and to >>>>> find a group of people that will help testing the new way. >>>> We don't want to "port it" to other drivers. We need to have a common >>>> module which does all RCx decoding. The individual drivers should be as >>>> simple as possible, something that I outlined in a previous mail. >>> With the current 7bits mask applied to almost all devices, it is probably not very >>> useful for those who want to use generic IRs. We really need to port the solution >>> we've done on dvb-usb to the other drivers, allowing them to have the entire >>> scancode at the tables while keep supporting table replacement. >>> >>> The issue is that we currently have only 7bits of the scan codes produced by the IR's. >>> So, we need to re-generate the keycode tables for each IR after the changes got applied. >> Ok, I got some time to add support for tables with the full scan codes at the V4L drivers. >> In order to not break all tables, I've confined the changes to just one device (HVR-950, >> at the em28xx driver). The patches were already committed at the -hg development tree. >> >> In order to support tables with the full scan codes, all that is needed is to add the >> RC5 address + RC5 data when calling ir_input_keydown. So, the change is as simple as: >> >> - ir_input_keydown(ir->input, &ir->ir, >> - poll_result.rc_data[0]); >> + ir_input_keydown(ir->input, &ir->ir, >> + poll_result.rc_address << 8 | >> + poll_result.rc_data[0]); >> + else >> >> An example of such patch can be seen at: >> http://linuxtv.org/hg/v4l-dvb/rev/9c38704cfd56 >> >> There are still some work to do, since, currently, the drivers will use a table with a fixed >> size. So, you can replace the current values, but it is not possible to add new keys. >> >> The fix for it is simple, but we need to think what would be the better way for it. There are >> two alternatives: >> - A table with a fixed size (like 128 or 256 entries - maybe a modprobe parameter >> could be used to change its size); >> - some way to increase/reduce the table size. In this case, we'll likely need some >> ioctl for it. >> > > Hmm, why can't you just resize it when you get EVIOCSKEYCODE for > scancode that would be out of bounds for the current table (if using > table approach)? For your reference, the code where EVIOGKEYCODE/EVIOSKEYCODE handling is done is at this changeset: http://linuxtv.org/hg/v4l-dvb/rev/21e71d58cd2a Dynamic resizing can be done, but there are a few different use cases for someone to touch on the keymaps: 1. People want to change the key assignment for a key at the shipped IR. In this case, the table won't need to change its size; 2. People want to use the shipped IR, plus a different one. In this case, table size needs to be extended to store the newer codes; 3. People want to discard the shipped IR and use something else. Case 3 is the worse scenario. Let's suppose, for example that instead of using a 49 keys IR, they want to use some programable IR with 55 keys, with different scancodes. This means that they'll need to delete all 49 scancodes from the old IR and add 55 new scancodes. As there's no explicit call to delete a scan code, the solution I found with the current API is to read the current scancode table and replace them with KEY_UNKNOWN, allowing its re-use (this is what the driver currently does) or deleting that scancode from the table. After deleting 49 keys, you'll need to add the 55 new keys. If we do dynamic table resize for each operation, we'll do 104 sequences of kmalloc/kfree for replacing one table. IMO, it would be better to have an ioctl to do the keycode table resize. An optional flag at the ioctl (or a separate one) can be used to ask the driver to clean the current keymap table and allocate a new one with the specified size. This will avoid playing with memory allocation for every new key and will provide a simple way to say to the driver to discard the current keybable, since a new one will be used. 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: Stefan Richter on 28 Nov 2009 05:40
Mauro Carvalho Chehab wrote: > Dmitry Torokhov wrote: [scancode-to-keycode map size] >> Hmm, why can't you just resize it when you get EVIOCSKEYCODE for >> scancode that would be out of bounds for the current table (if using >> table approach)? [...] > Let's suppose, for example that instead of using a 49 keys > IR, they want to use some programable IR with 55 keys, with different > scancodes. This means that they'll need to delete all 49 scancodes from the old IR > and add 55 new scancodes. As there's no explicit call to delete a scan code, the solution > I found with the current API is to read the current scancode table and replace them with > KEY_UNKNOWN, allowing its re-use (this is what the driver currently does) or deleting > that scancode from the table. After deleting 49 keys, you'll need to add the 55 new keys. > If we do dynamic table resize for each operation, we'll do 104 sequences of kmalloc/kfree > for replacing one table. It is not a performance sensitive task, is it? If you can trade ABI simplicity for performance (which shouldn't actually matter), that'd be a better deal. Besides, some of the necessary kernel-internal house-keeping can also be deferred until close(). > IMO, it would be better to have an ioctl to do the keycode table resize. An optional flag > at the ioctl (or a separate one) can be used to ask the driver to clean the current > keymap table and allocate a new one with the specified size. > This will avoid playing with memory allocation for every new key and will provide a simple > way to say to the driver to discard the current keybable, since a new one will be used. OTOH, an additional "forget all current mappings" ioctl sounds like an ABI simplification. -- Stefan Richter -=====-==--= =-== ===-- http://arcgraph.de/sr/ -- 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/ |