From: J. J. G. de S. L. <ska...@gm...> - 2008-12-29 13:18:40
Attachments:
input_map.sh.patch
|
Hello. I'm testing my remote via the new uinput functionality in the lirc CVS. I like the concept because of two reasons: 1. It allows all input to be processed equally (no matter the source). 2. I prefer application context to be defined by X/application focus behaviour, rather than to have to fake it with lircrc "modes". Global shortcuts may be kept global (with something like GNOME key shortcuts), and local key events retain their local meaning. So far it's been some lights and several shadows. I had to patch the input_map.sh script (patch attached), since it wasn't working and I got an empty namespace. I had to manually fix the generated .inc file, since it was choking on a multi-line comment (it would copy only the "/*" part, leaving the some of the following list entries commented). Once adapted my remote configuration most "normal" keys worked directly in all applications. I couldn't map the hask (#) key in my remote, since there's no such key symbol in the kernel. Autorepeat was triggering in too early, no matter how I configured GNOME keyboard properties. I've seen the code in lircd.c, and I reckon it's trying to use the auto-repeat support in the input layer. I've tried to change it so that it works better for me. Most experiments ended up with autorepeat going on even after I had released the remote key. The only behaviour I find reasonable is when I do the following: 1. Define an auto-repeat threshold T (T=0 disabled). 2. For the first press (reps = 0), emit a press (event.value = 1) and a release (event.value = 0) in succession. 3. If auto-repeat is enabled, for each press with reps >= T, emit a repeat-press (event.value = 2) and a release (event.value = 0) in succession. The last issue is x.org related. The Linux input layer has key codes for most of the keys in my remote, but many of them don't get mapped to x.org symbols by default. Some of them even lack any matching x.org symbol (there's nothing like XF86LiveTV or XF86RecordedTV, not even XF86TV). So you're stuck with either using some of the generic XF86Launch<n> or mapping "strange keys" to some arbitrarily chosen "standard" key (not key combination). Another option would be to map the "standard" keys via uinput, and let the strange ones to be processed via irxevent (as far as the kernel/x.org combination do not provide all the required keys). In short, I like the feature, and I think it is "the right way to go" (TM). I think it would be nice to talk to x.org people to see if they are open to include a good catalog of "remote strange keys" in their symbol definitions (since Linux is OK; it seems to include every key and its cousin), or are open to provide some way of creating new symbols either dynamically or at configuration time. So, thanks for your good work, Juan Jesus. -- Dream small if success is enough for you; dream big if you need to change the world. |
From: <li...@ba...> - 2008-12-29 15:03:29
|
Hi! Juan Jesús García de Soria Lucena "ska...@gm..." wrote: > I had to patch the input_map.sh script (patch attached), since it > wasn't working and I got an empty namespace. I had to manually fix the > generated .inc file, since it was choking on a multi-line comment (it > would copy only the "/*" part, leaving the some of the following list > entries commented). Can you send me the input.h that gives problems? [...] > Autorepeat was triggering in too early, no matter how I configured > GNOME keyboard properties. I've seen the code in lircd.c, and I reckon > it's trying to use the auto-repeat support in the input layer. During implementation I found that the input layer behaves not very intuitive here. > > I've tried to change it so that it works better for me. Most > experiments ended up with autorepeat going on even after I had > released the remote key. The only behaviour I find reasonable is when > I do the following: > > 1. Define an auto-repeat threshold T (T=0 disabled). > > 2. For the first press (reps = 0), emit a press (event.value = 1) and > a release (event.value = 0) in succession. > > 3. If auto-repeat is enabled, for each press with reps >= T, emit a > repeat-press (event.value = 2) and a release (event.value = 0) in > succession. I wonder if there is a "correct" way to use auto-repeat. Christoph |