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: hermann pitton on 5 Dec 2009 22:40 Hi, Am Freitag, den 04.12.2009, 19:28 -0500 schrieb Jon Smirl: > On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus <lirc(a)bartelmus.de> wrote: > > BTW, I just came across a XMP remote that seems to generate 3x64 bit scan > > codes. Anyone here has docs on the XMP protocol? > > Assuming a general purpose receiver (not one with fixed hardware > decoding), is it important for Linux to receive IR signals from all > possible remotes no matter how old or obscure? Or is it acceptable to > tell the user to throw away their dedicated remote and buy a universal > multi-function one? Universal multi-function remotes are $12 in my > grocery store - I don't even have to go to an electronics store. finally we have some point here, IMHO, that is not acceptable and I told you previously not to bet on such. Start some poll and win it, and I'll shut up :) To be frank, you are quite mad at this point, or deliver working other remotes to __all__ for free. Cheers, Hermann -- 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 6 Dec 2009 02:10 On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote: > Em Fri, 4 Dec 2009 02:06:42 -0800 > Dmitry Torokhov <dmitry.torokhov(a)gmail.com> escreveu: > > > > > > > > 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. > > Let me better express here. It is all about how we'll expand the limits of those > ioctls to fulfill the needs. > > The point is that we'll have, let's say something like to 50-500 scancode/keycode tuples > sparsely spread into a 2^64 scancode universe (assuming 64 bits - Not sure if is there any > IR protocol/code with a bigger scancode). > > On such universe if we want to get all keycodes with the current ioctls for a scancode in > the range of 32 bits, we need to do something like: > > u32 code; > int codes[2]; > for (code = 0; code <= (unsigned u32) - 1; code++) { > codes[0] = (int)code; > if (!ioctl(fd, EVIOCGKEYCODE, codes)) > printf("scancode 0x%08x = keycode 0x%08x\n", codes[0], codes[1]); > } > > So, on the 32 bits case, we'll do about 4 billions calls to EVIOGKEYCODE ioctl to > read the complete scancode space, to get those 50-500 useful codes. > Right, currently there is no need to query all scancodes defined by device. Quite often drivers don't even know what scancodes device actually generates (ex AT keyboard). Could you describe in more detail how you are using this data? > > Due to the current API limit, we don't have any way to use the full 64bits space for scancodes. > Can we probably reduce the "scancode" space? ARe all 64 bits in protocols used to represent keypresses or some are used for some kind of addressing? > if we use code[0] as an index, this means that we'll need to share the 32 bits on code[1] > for scancode/keycode. Even using an 32 bits integer for keycode, it is currently limited to: > > #define KEY_MAX 0x2ff > #define KEY_CNT (KEY_MAX+1) > > So, we have 10 bits already used for keycode. This gives only 22 bits for scancodes, if we share > codes[1] for both keycode/scancode. By sharing the 32 bits, we'll need to be care to not extend > KEY_MAX to be bigger than 0x3ff, otherwise the keytable won't be able to represent all keys of the > key universe. > > What is need for this case is that the arguments for get key/set key to be something like: > > struct { > u16 index; > u64 scancode; > u32 keycode; > }; > Hmm, so what is this index? I am confused... 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 6 Dec 2009 02:20 On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote: > > > > > > > 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. > > Just for better illustrate what I'm seeing, I broke the IR generic > code into two components: > > lirc core - the module that receives raw pulse/space and creates > a device to receive raw API pulse/space events; > > IR core - the module that receives scancodes, convert them into > keycodes and send via evdev interface. > > We may change latter the nomenclature, but I'm seeing the core as two different > modules, since there are cases where lirc core won't be used (those > devices were there's no way to get pulse/space events). > OK, I think we are close but not exactly close. I believe that what you call lirc core will be used always - it is the code that create3s class devices, connectes decorers with the data streams, etc. I believe it will be utilized even in case of devices using hardware decoders. That is why we should probably stop calling it "lirc core" just tso we don't confuse it with original lirc. Then we have decoders and lirc_dev - which implements original lirc interface (or maybe its modified version) and allows lircd to continue working. Lastly we have what you call IR core which is IR-to-input bridge of sorts. Right? -- 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 7 Dec 2009 02:50 On Sun, Dec 06, 2009 at 09:03:31AM -0200, Mauro Carvalho Chehab wrote: > Dmitry Torokhov wrote: > > On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote: > >> Em Fri, 4 Dec 2009 02:06:42 -0800 > >> Dmitry Torokhov <dmitry.torokhov(a)gmail.com> escreveu: > >> > >>> 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. > >> Let me better express here. It is all about how we'll expand the limits of those > >> ioctls to fulfill the needs. > >> > >> The point is that we'll have, let's say something like to 50-500 scancode/keycode tuples > >> sparsely spread into a 2^64 scancode universe (assuming 64 bits - Not sure if is there any > >> IR protocol/code with a bigger scancode). > >> > >> On such universe if we want to get all keycodes with the current ioctls for a scancode in > >> the range of 32 bits, we need to do something like: > >> > >> u32 code; > >> int codes[2]; > >> for (code = 0; code <= (unsigned u32) - 1; code++) { > >> codes[0] = (int)code; > >> if (!ioctl(fd, EVIOCGKEYCODE, codes)) > >> printf("scancode 0x%08x = keycode 0x%08x\n", codes[0], codes[1]); > >> } > >> > >> So, on the 32 bits case, we'll do about 4 billions calls to EVIOGKEYCODE ioctl to > >> read the complete scancode space, to get those 50-500 useful codes. > >> > > > > Right, currently there is no need to query all scancodes defined by > > device. Quite often drivers don't even know what scancodes device > > actually generates (ex AT keyboard). > > > > Could you describe in more detail how you are using this data? > > It is useful if you want to dump the keycode maps into file with the current > scancode attribution, in order to modify some keystrokes. > > Right now, programs like dumpkeys (from kbd package) allow you to dump for example > the attribution keys from your keyboard. > > In the case of IR's this functionality is very important. > > For example, you may need to replace the scancode/KEY_CHANNELUP tuple by scancode/KEY_UP, > in order to make your IR to work with some applications that don't recognize the IR > specific keycodes. > > In practice, with such applications, you'll need to replace several different scancodes. > > So, you may end by having different scancodes producing the same keycode, as such applications > aren't capable of differentiating an UP key from a CHANNELUP key. This is the case, for example > of the popular tvtime application. > > The better way is to just generate a dump file, modify the needed entries and reload the > table by calling EVIOSKEYCODE, in order to use the new table. > > I wrote a small application that just do the above, and I use to load some special tables > to work with some applications like tvtime and mplayer. (with mplayer, you need to map > <channel down> as KEY_H and <channel up> as KEY_K). > > I hope that, after we finish addressing IR's, we'll finally have media applications handling > directly the proper keycodes, but people may still need to write different keycodes to do > other things. I used to have a keymap file in order to use an IR to control the slide show > with openoffice. > > >> Due to the current API limit, we don't have any way to use the full 64bits space for scancodes. > >> > > > > Can we probably reduce the "scancode" space? ARe all 64 bits in > > protocols used to represent keypresses or some are used for some kind of > > addressing? > > All the IR's I found with V4L/DVB use up to 16 bits code (or 24 bits, for NEC extended protocol). > However, currently, the drivers were getting only 7 bits, due to the old way to implement > EVIO[S|G]KEYCODE. > > I know, however, one i2c chip that returns a 5 byte scancode when you press a key. > We're currently just discarding the remaining bits, so I'm not really sure what's there. > > > The usage of 7 bits, in practice, were meaning that it weren't possible to use > a different remote than the one provided by the device manufacturer, as the scancodes produced > by other remotes differ on more than 7 bits. Also, this means that, if your TV and your PC > are using the same protocol, like RC5, if you press a button on your TV remote, the PC will > also get it. > > I know, however, one IR driver that produces 6 bytes when you press a key. > We're currently just discarding the remaining bits, so I'm not really sure > what else is there. Some badly optimized protocol? a bigger scancode? a protocol indication? > > In general, the scancode contains 8 or 16 bits for address, and 8 bits for command. > > However, the scancode table needs to handle the address as well, since we don't want that a > scancode meant to go to your TV to be handled by the PC, but we may want to get codes from > different addresses there, as we may need to use the address to differentiate the commands > meant to control the TV volume, for example, than the same command meant to control the PC > master volume. Right, but this data is not interesting to userspace. For userpsace scancode is just a cookie that is uniquely identifies a button for which a keycode can be assigned. > > >> if we use code[0] as an index, this means that we'll need to share the 32 bits on code[1] > >> for scancode/keycode. Even using an 32 bits integer for keycode, it is currently limited to: > >> > >> #define KEY_MAX 0x2ff > >> #define KEY_CNT (KEY_MAX+1) > >> > >> So, we have 10 bits already used for keycode. This gives only 22 bits for scancodes, if we share > >> codes[1] for both keycode/scancode. By sharing the 32 bits, we'll need to be care to not extend > >> KEY_MAX to be bigger than 0x3ff, otherwise the keytable won't be able to represent all keys of the > >> key universe. > >> > >> What is need for this case is that the arguments for get key/set key to be something like: > >> > >> struct { > >> u16 index; > >> u64 scancode; > >> u32 keycode; > >> }; > >> > > > > Hmm, so what is this index? I am confused... > > It is the sequence number of a scancode/keycode tuple stored at the keycode table. > > Better than saying it in words, let me put a code snippet: > > at include/linux/input.h, we'll add a code like: > > struct input_keytable_entry { > u16 index; > u64 scancode; > u32 keycode; > } __attribute__ ((packed)); > > (the attribute packed avoids needing a compat for 64 bits) > > #define EVIOGKEYCODEENTRY _IOR('E', 0x85, struct input_keytable_entry) > > (and a similar ioctl for setkeycode) > > This struct will be used by the new > > at include/media/ir-common.h, we already have: > > struct ir_scancode { > u16 scancode; > u32 keycode; > }; > > struct ir_scancode_table { > struct ir_scancode *scan; > int size; > ... > }; > > The code at ir core that will handle the ioctl will be like: > > static int ir_getkeycode_entry(struct input_dev *dev, struct input_keytable_entry *ike) > { > struct ir_scancode_table *rc_tab = input_get_drvdata(dev); > > if (rc_tab->size >= ike->index) > return -EINVAL; > > irk->scancode = rctab->scan->scancode; > irk->keycode = rctab->scan->keycode; > > return 0; > } > OK, but why do you even want to expose scancode to userpsace using evdev here? Lircd-type applications might be interested, but they are going to use lircd. For the rest of userpsace index can be used as a "scancode" just as easily. Scancodes in input system never been real scancodes. Even if you look into atkbd it uses some synthetic data composed out of real scancodes sent to the keyboard, and noone cares. If you are unsatisfied with mapping you fire up evtest, press the key, take whatever the driver [mis]represents as a scancode and use it to load the new definition. And you don't care at all whether the thing that driver calls cancode makes any sense to the hardware device. -- 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 7 Dec 2009 03:00
On Sun, Dec 06, 2009 at 12:58:00PM +0100, Christoph Bartelmus wrote: > Hi Dmitry, > > on 04 Dec 09 at 15:15, Dmitry Torokhov wrote: > [...] > >>>>>> 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. > > And I set a timeout to know that no MSC_SCAN_END will arrive? This is > broken design IMHO. > EV_SYN signals the end of state transmission. > Furthermore lircd needs to know the length of the scan code in bits, not > as a multiple of 32. I really do not think that LIRCD is the type of application that should be using evdev interface, but rather other way around. > > > FWIW there is MSC_RAW as well. > > It took me some time to convice people that this is not the right way to > handle raw timing data. > > Christoph -- 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/ |