HAL, and laptop Fn and hardware keys

[Matthias Grimm]

On Sat, 08 Oct 2005 19:34:09 +0100
Richard Hughes <hughsient at gmail.com> wrote:

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

This is not a very good reason, if it's the only one. We shouldn't
break existing and well proved methods because we are able to. ;-)
 
> > 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?

I talk about the kernel input layer, not the X events. X will get it's
events from the kernel input layer (beside other sources).

And yes, I think there is a easy method to send input events from user
space if necessary through the uinput device. I'm going to check the
next days.

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

Well.. then take this as suggestion from me :-)

  Best Regards
    Matthias