HAL FDI matched Buttons

[Richard Hughes]

On Mon, 2005-11-28 at 13:23 +0100, Stefan Seyfried wrote:
> 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.

Okay point taken, but if I enable iald, and I don't have a Sony or
Toshiba laptop it just sits there doing nothing, right? With the hal
addon system you just launch the addon that is applicable to your
system, or none at all if you just have a standard laptop that emits
acpi events (we already monitor those in the acpi addon, just we ignore
the extra buttons..)

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

Well, this is opensource software, and I figured that just because some
other program can do something shouldn't stop a new solution if it is
technically superior. I'm getting sick of this "but daemon x can already
do this" as an argument against new functionality. I'm not asking you to
help me, or forcing you to use it. I'm saying this functionality helps
me, and I think it's useful being in HAL.

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

Introducing yet another layer of abstraction?

> This way, users can choose _which_ hotkey daemon, _which_
> powermanagement daemon, _which_ cpufreq daemon etc. to use.

This would be a disaster for distros. Really, this stuff is supposed to
"just work" and the user shouldn't have to do lots of research, install
a random daemon, configure it, and work out how to interact with it.

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

Or we could put a little bit of code in HAL to make all this just work.

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

You can disable any of the addons by simply editing the fdi files, and
disabling them from being launched.

Richard.