HAL, and laptop Fn and hardware keys

[Richard Hughes]

On Fri, 2005-10-07 at 18:04 +0200, Matthias Grimm wrote:
> On Wed, 21 Sep 2005 10:44:04 -0400
> David Zeuthen <david at fubar.dk> wrote:
> 
> Hi,
> 
> > Why on earth would I want Yet Another Daemon.. from Yet Another
> > Project... running for something as trivial as keys, when we got HAL and
> > it fits perfectly in with the model we use for other devices? Care to
> > explain why it's a bad idea to port this to HAL? 
> 
> I followed this discussing with interest but the longer I read the
> bolder a question popped up in my mind:
>             Why need HALd to handle key events at all? 

As its easy to add to HAL...

> There is already a very good abstraction of keys in Linux: The kernel
> input event layer with the keycodes in linux/input.h. This keys could
> also be used in X and contains already a lot of special keys.

Ahh yes, forgot about this. Is there an easy way to "fake" a X event,
e.g. KEY_POWER from a c file or command line?

> For example there are:
>   KEY_BRIGHTNESSUP
>   KEY VOLUMEDOWN
>   KEY_POWER
>   KEY_CLOSECD
>   KEY_EJECTCD
>   KEY_EJECTCLOSECD
>   KEY_NEXTSONG
>   KEY_PLAYPAUSE
>   KEY_PREVIOUSSONG
>   KEY_STOPCD
>   etc.
> 
> Why are you trying to establish a new dbus based key event system
> instead of extending the existing one? Why would you like to shoulder
> this extra load?

Well, because no-one's suggested using X events! I'm googling as I
speak.

> Distributing key events via the kernel input layer has another
> important advantage: It will support all applications with or without
> dbus support.

Yes, I know. You're right.

Richard.