Re: Linux input event generation using uinput

[J. J. G. de S. L. <ska...@gm...>]

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.