Add Hardware Input Device for ACPI

[David Zeuthen]

On Sun, 2006-02-26 at 01:32 +0000, Richard Hughes wrote:
> The simple attached patch creates a node that we can use for
> ButtonPressed events from devices not in the DSDT. It doesn't do
> anything much now, but will, when hooked up with the other addons that
> are launched from fdi files.
> 
> These could include my Compaq server management buttons or Toshiba
> hardware buttons, and the acpi buttons not expressed in the DSDT. This
> could (and should?) be also used for the lid, power and sleep buttons we
> do now, but I think we should keep compatibility by not removing them
> just yet.

But why would we remove them? Again we really want to know the existence
of a button.. it's nicer to know it's there than suddenly having to deal
with a ButtonPressed event when and if someone presses that button... 

(and if the Linux kernel is going in the direction that this wont be
possible... then we seriously need to tell that to the right people
ASAP)

> 
> Creating one device per button is not flexible enough for ACPI, as we do
> not know if some buttons are present at coldplug, and therefore cannot
> create devices. We do not want a large number of button devices in the
> HAL tree (25+?) for single button action, e.g. BrightnessUp,
> BrightnessDown, LockScreen etc.

I do think, as far as it's possible, that we want to know exactly what
buttons are available. If HAL chokes on having 25 device objects for
this we should rather fix HAL...

> Okay to merge this simple patch?

No, I don't really think this is appropriate... you should still be able
to add buttons as you please.. Two paths

 1. Patch the HAL sources as we do today for various ACPI-specific
    buttons

 2. just launch a callout for Computer and use the libhal_new_device()
    and libhal_device_commit_to_gdl() API's.. see tools/hal-device.c
    for details.. also launch an addon and use libhal_emit_condition()
    to send ButtonPressed... Presto, problem solved..

Of course we should always choose path 1. if available... interestingly
enough, if I'm HP, Dell or whatever I can even ship code written using
path 2.. and if I'm an evil vendor I can even keep the source to myself
(libhal is AFL/GPLv2).. Not something I would encourage but entirely
possible...

Don't you think this approach is better?

    David