HAL FDI matched Buttons

Richard Hughes hughsient at gmail.com
Mon Nov 28 03:42:07 PST 2005


On Mon, 2005-11-28 at 09:45 +0100, Stefan Seyfried 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.
> Timo's iald already handles those, maybe he can comment on the
> feasibility of hooking iald up as a HAL addon.

Seems overkill. For the toshiba specific bits I just lifted the two
small functions for getting the keycodes (okay as licenced as GPL) and
the rest of the stuff is just HAL plumbing. I'm guessing the soni-pi
stuff is similar. Using two distinct addons means that if you have a
toshiba, the tosh addon gets loaded automatically, and if you have a
sony, the sony addon gets loaded, and only that module. Each addon is a
few k in size.

> >> For instance, one fdi file could map the alt-f4 key to the scancode for
> >> HELP, so that the image on the button matches the action. This would
> >> only be done for the system.vendor = VENDOR.
> > 
> > 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.

Yes, just like people contribute fdi files to get their music player
detected correctly, they could contribute a keymapping. Drop one file
into the fdi folder and it would just work (unless trucked up interface
like toshiba or sony, which would need a bit of glue code..)

Thanks for your feedback.

Richard.



More information about the hal mailing list