HAL, and laptop Fn and hardware keys

[Richard Hughes]

On Tue, 2005-09-20 at 18:11 +0200, Paolo Borelli wrote:
> Il giorno mar, 20/09/2005 alle 16.28 +0100, Richard Hughes ha scritto:
> > The extra key presses (e.g. Fn-F1, and other h/w buttons) on most
> > laptops are very vendor specific (Just like acpi brightness support) and
> > have lots of different hacky scripts and daemons to watch each of the
> > wacky interfaces. Sony has watched sonpid, and toshiba currently has
> > fnfxd. I'm sure the other laptop makes have their own scripts too.
> > 
> > What is the consensus of an addon, say hal-addon-<vendor>-buttons that
> > reports each of these events as a dbus signal, so that gnome control
> > center (or another more suitable gnome process) can do a specific
> > action?
> > 
> > The addon can be launched in the existing infrastructure just checking
> > for the existance of files/directories, e.g. /proc/acpi/toshiba/buttons
> > and would have *very low* overhead as most of the time it would be
> > sleeping.
> > 
> > This is currently a chicken and egg situation as no gnome application
> > can use the events, but there won't be any support until the events are
> > generated. 
> > 
> > Doing this in-HAL allows us to abstract out the vendor, and just have
> > the dbus interface, just like the LCD screen stuff.
> > 
> > Comments?
> 
> (some comments from your truly since I was discussing this with Richard
> on irc, but keep in mind that I am pretty clueless about this stuff)
> 
> Abstracting the quirks of Fn keys seems a worthwhile goal to me, if it
> belongs or not in HAL is not up to me to say.

Well, the ButtonPressed infrastructure is already there...

> A point raised on irc and which may be of interest is that afik some of
> the keys are hardwired to the HW while others go through the OS: this
> means that events fired in reponse to the first will cause a change
> (e.g. VGA out) no matter of which policy is configured by the program
> who listens to the d-bus event while the second kind of Fn keys can be
> configured to trigger arbitary actions. I think that this distintion
> should be made clear.

Sure, on toshiba the only button that is tied to h/w for me is Fn-F5,
which we can blacklist. I'm sure the other buttons on other makes (e.g.
Bluetooth disable on IBM) can be treated the same.

> Note that the first kind of events shouldn't be blacklisted just because
> they already trigger an action: for instance one could want to display a
> "Can you read this" message when the VGA out is activated.

Hmm.. I would rather make it all "just work" and blacklist/whitelist
where needed.

Richard.