ACPI to uinput bridge

[David Zeuthen]

On Sat, 2005-10-15 at 03:08 +0100, Richard Hughes wrote:
> Further to all the feedback and new ideas, I've spend a couple of hours
> hacking on a acpi to uinput hal addon, using IAL as a source for the
> Toshiba specific bits.
> 
> I've created two files, acpi_uinput.c and acpi_uinput.h which provide
> all the shared acpi->uinput code, and created an example addon,
> addon-acpi-buttons-toshiba which uses this shared code.
> 
> The toshiba addon uses just 2 small functions copied from IAL:
> 
> toshiba_key_flush
> toshiba_key_ready

If you copy code better make sure the licenses matches (I saw your code
using IAL licensed both under AFL2.1 and GPL - are you sure IAL is under
both of these? Btw, for Linux bits in HAL you only need to license under
the GPL).

> That's only 44 lines of copied code copied from approx 2500 lines of IAL
> daemon. The addon *and* shared headers added together are only 254 lines
> total.
> 
> Using this new hal addon (which is only launched for toshiba hardware
> using an FDI file to match against smbios) I can type:
> 
> gnome-keybinding-properties
> 
> and click "launch web-browser" and press Fn-F1. From this point onwards
> Fn-F1 generates a scancode to automatically launch my web browser.
> 
> I can also map my "next track" acpi button to the GNOME "Skip to Next
> Track" function, so that it works in rhythmbox and totem.
> 
> If you have an IBM laptop (i.e. not toshiba), the addon would never be
> matched, and there would be no extra memory usage or boot time delay.
> 
> Writing a vendor acpi button driver is easy -- you can use the source of
> the custom scripts people have used over the years.
> 
> You can map the other "weird" buttons to scancodes too. The wifi
> enable/disable could be mapped, as could the extra cdplayer buttons on
> some asus laptops.
> 
> I think it's important to add functionality like this to HAL.
> Now, feedback is very welcome. Initial code attached (WIP).

Putting *some* of the special button presses on uinput *might* make
sense but you really want a hal device object too for every special
button. That is the design of HAL, one single interface for the various
hardware we got - including special buttons. I want this so you don't
have to listen in e.g. g-p-m on both HAL and uinput to catch the when
some user presses what is designated as the "sleep button" on his
laptop.

So, really, what I'd like to see are two patch for HAL 

 1. that creates hal device objects for e.g. Toshiba buttons - will
    maybe need a special addon that reads the events and generates
    ButtonPressed signals

 2. A generic patch for hal that says "oh, I see ButtonPressed on
    a device object with button.type="webbrowser_button" - let me
    put that on our uinput channel

and these patches should be independent on each other. Does this make
sense?

Cheers,
David