Add Hardware Input Device for ACPI

[Richard Hughes]

On Sun, 2006-02-26 at 16:58 -0500, David Zeuthen wrote:
> 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... 

I guess.

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

See my other mail.

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

Okay..

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

Sure, I wanted to know the best way this could be done, I can modify my
addons appropriately. 

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

Yes, as long as you don't mind me potentially adding 10+ buttons to the
HAL tree.

I'll come up with an alternate patch.

Thanks for the feedback.

Richard.