HAL FDI matched Buttons

[Stefan Seyfried]

Richard Hughes wrote:
> 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.

as is iald:

seife at susi:~> ls -l /usr/sbin/iald
-rwxr-xr-x  1 root root 20712 2005-09-30 04:25 /usr/sbin/iald
seife at susi:~> ldd /usr/sbin/iald
        linux-gate.so.1 =>  (0xffffe000)
        libdbus-glib-1.so.1 => /usr/lib/libdbus-glib-1.so.1 (0x40036000)
        libgobject-2.0.so.0 => /opt/gnome/lib/libgobject-2.0.so.0
(0x4004f000)
        libdbus-1.so.1 => /usr/lib/libdbus-1.so.1 (0x40089000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x400b8000)
        libglib-2.0.so.0 => /opt/gnome/lib/libglib-2.0.so.0 (0x400ce000)
        libxml2.so.2 => /usr/lib/libxml2.so.2 (0x40156000)
        libz.so.1 => /lib/libz.so.1 (0x40282000)
        libm.so.6 => /lib/tls/libm.so.6 (0x40295000)
        libial.so.0 => /usr/lib/libial.so.0 (0x402bb000)
        libdl.so.2 => /lib/libdl.so.2 (0x402be000)
        libc.so.6 => /lib/tls/libc.so.6 (0x402c2000)
        /lib/ld-linux.so.2 (0x40000000)

The ial modules are also not really big bloated monsters.

I cannot understand why you want to transform HAL to a
do-everything-big-unmaintainable ACME daemon. There are perfectly
working solutions for all your needs, so there is no need to reinvent
the wheel over and over again.

> 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..)

My idea would be to use HAL as a "configuration store" where a hotkey
daemon (regardless if it is iald or something else) can fetch its
instructions on how to interpret the hardware, but leave it to the
particular daemon to interpret them.
This way, users can choose _which_ hotkey daemon, _which_
powermanagement daemon, _which_ cpufreq daemon etc. to use. Those
daemons will use HAL as a "configuration backing store" and the user can
combine them as he likes (he can even use a daemon that provides more
than one of those functions - e.g. powersaved which currently can do
suspend / resume handling, cpufreq, device power management, LCD
brightness).
You then can still write your "do everything that i need in one big hunk
of code"-daemon, but nobody else will be forced to use it (and yes,
basically users are forced to use HAL nowadays if they want to use any
recent desktop environment, so IMO it should be as low-fat as possible).

Best regards,

     Stefan
-- 
"You sure you software suspend guys haven't been hanging out with the
 IDE maintainers?"                                     -- Rob Landley