Re: [gpm] Untangling the sleep hotkey mess

[Richard Hughes <hughsient gmail com>]

On Mon, 2006-01-09 at 02:30 +0000, Matthew Garrett wrote:
> On Mon, Jan 09, 2006 at 10:19:00AM +0800, Yu Luming wrote:
> 
> > Re: dev_acpi:
> > The key point is AML code shouldn't be exposed in userspace. It is too ugly.
> 
> It may be ugly, but it /works/. We can't predict what vendors will do in 
> terms of providing hotkey support in future, and exposing a limited 
> interface to userspace would probably just result in it having to be 
> extended later on, which again forces us into kernel patching.
> 
> With my Ubuntu hat on:
> 
> dev_acpi would make life a lot easier for us than the current solutions. 
> A single userspace application has the advantage that it can be 
> maintained in a nice cross-distribution way, and we can rapidly fold in 
> extra support based on testing reports.

With my Redhat on*:

I think maybe dev_acpi may work well for the power-user case (if you
know *exactly* what you are doing), but just using the simple acpi
events (like we can do now on some machines) works well. This means that
we can get bug reports from users for obscure machines and keyboards
just from looking at an acpid log. Adding support for different keys can
be done just by adding values to an FDI xml file, or a small addon.
I think trying to pre-process the information in the kernel is a bad
thing to do -- debugging, and getting a user to test a kernel patch is
much harder than a similar userspace patch.

In my ideal world:

* All ACPI keyboard events would come through /proc/acpi/event as hkey's
* You could change the brightness on *any* lcdpanel by doing a simple
  #echo 3 > /proc/acpi/video/brightness
* You could get the number of brightness levels supported doing
  #cat /proc/acpi/video/brightness_levels

Richard.

* I don't work for Redhat, but I do lots of work with Fedora and HAL.