Re: [patch 1/1] thinkpad fn+fx key driver

[Vojtech Pavlik <vojtech-AlSwsSmVLrQ@public.gmane.org>]

On Thu, Sep 23, 2004 at 01:16:57AM -0400, Brown, Len wrote:
>  
> >On Wed, Sep 22, 2004 at 01:28:49PM -0700, akpm-3NddpPZAyC0@public.gmane.org wrote:
> >> 
> >> From: Erik Rigtorp <erik-aH8aFkyL5XJBDgjK7y7TUQ@public.gmane.org>
> >> 
> >> Changes since last version:
> >>  - use the acpi handle provided by acpi_bus_register_driver, 
> >this way it
> >>    should work on more models.
> >>  - correct handling of return value from acpi_bus_register_driver
> >> 
> >> Signed-off-by: Andrew Morton <akpm-3NddpPZAyC0@public.gmane.org>
> >
> >Very nice. Even nicer because I have a thinkpad and I was considering
> >writing an extra keys driver that'd poll the CMOS, which would be quite
> >a hack.
> >
> >I have a question, though:
> >	Wouldn't it be better to have the keys pass through the input
> >	event layer instead of the ACPI event layer?
> >
> >That way the keys would work the same as on regular machines/keyboards,
> >simplifying the userspace handling ... we could also take the opposite
> >approach and add handlers to the keymap to send ACPI events for regular
> >wake/sleep/power keys on keyboards.
> >
> >The same would apply to Toshiba and ASUS as well.
> 
> This is an emerging area, yes -- consider nothing final;-)
> 
> Others too have suggested using the input layer
> for hot keys.  I must plead ignorance of the input layer
> and how adaptable it is.
> 
> My PS/2 keyboard has sleep/wakeup/power buttons
> that work on Windows, at least the sleep one works.
> What is necessary for them to work on Linux?
> That will probably be an easier problem to solve,
> and the more exotic buttons on laptops which do
> things like switch the display and dim the screen
> via ACPI methods may be harder.

There are several ways to make both the keyboard and ACPI keys work as
intended:

1) Extend acpid to listen on all /dev/input/event keyboard devices and
   call scripts when the keys are pressed. No change to the kernel.

2) Change ACPI to use the Input API, and add possibility to map ACPI
   events in the keymap. Then have acpid listen to those.

3) Change ACPI to use the Input API and use the power.ko module for
   mapping the keys to system state change actions.

4) Change ACPI to use the Input API and have a daemon that handles
   all extra keys, including sound volume and application keys, possibly
   using D-bus to send the events to the desktop environment.

5) Change power.ko to just generate ACPI events for the keys. Handle
   the events via acpid.

I probably prefer 4), although all make sense. I think 3) is only useful
for embedded systems, because it's not configurable enough. 2) would
probably not work when in X, because it relies on the console subsystem.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php