HAL FDI matched Buttons

[Matthias Grimm]

On Mon, 28 Nov 2005 09:45:38 +0100
Stefan Seyfried <seife at suse.de> wrote:

> Matthias Grimm wrote:
> > On Sun, 27 Nov 2005 17:40:28 +0000
> > Richard Hughes <hughsient at gmail.com> wrote:
> > 
> >  
> >> * Perhaps use a uinput kernel side input device for maximum
> >>   compatibility.
> > 
> > This one is the best. All you need is to assign a keycode to not
> > supported keys. Desktop applications would do the rest.
> 
> Well, there are also such things as ACPI hotkeys and the really nasty
> stuff like Toshiba and the SonyPI interfaces.

Yes, your are right, but all special keys have a defined purpose like
power key, volume up, volume down, etc. and if you have a look into
linux/input.h you will see that most of the keys already have a keycode
assigned. Unfortunately the kernel doesn't handle all buttons. New keys
on recent machines and especially the ACPI buttons won't be handles in
usual manner. Here it need help from user land.

> Timo's iald already handles those, maybe he can comment on the
> feasibility of hooking iald up as a HAL addon.

IALd is a nice tool and on top of the project list I want to learn from.
Basically this is exactly what we need. The only problem I have with
IALd is that it emits dbus signals instead of sending input events
though the kernel input layer. This way every program you listed below
could use this additional keys and attach functions to them.

> > Actually I wanted to tell you now that there are a lot of applications
> > already out there to do this, but to my surprise, they aren't. I looked
> > for a program that is able to start arbitrary programs on key trigger,
> > but I found only a single project. I thought that
> 
> fvwm2 (the one and only all time favorite :-) has of course a keygrabber
> built-in.
> bbkeys for "normal" keys that have a scancode assigned,
> khotkeys for KDE,
> iald / initial combo for everything else.

Yes, I already thought that but that't "Murpy": You won't find a
appropriate program when you need it. :-)
 
> > But by no means I would enforce the burden of key mapping on HAL. This
> > will conflict with too many other mechanisms like X11, kernel key
> > mapping, and whatelse more and would only be another never ending
> > construction site.
> 
> Well, some sort of "hardware vendor drops a .fdi-file somewhere and
> magically all its models will have the correct keymap assigned
> automagically" mechanism would definitely be useful. Lots of machines
> still generate "unknow scancode foobar" for the extra keys unless
> configured correctly. Those are easily configured, but if we can
> automate it, why not. Also, maybe we could even map them to the
> _correct_ keycodes, i have some machines / keyboards that all generate
> the same scancodes, but for different keys. If we provide a mechanism
> for vendors to provide a "driver" easily, they might actually do it.

That's exactly what I would like to do: map them to the correct keycodes.

My vision is to have a virtual keyboard device that collects all
unsupported keys, map them to the correct keycodes (from input.h) and
send input events back to the kernel input layer (through uinput). This
could be a seperate daemon (like IALd) or part of HAL. That doesn't matter.

 Best Regards
    Matthias