Re: [PATCH 2.6.15.3 1/1] ACPI: Atlas ACPI driver

[Matthew Garrett <mjg59@srcf.ucam.org>]

On Mon, Feb 20, 2006 at 06:49:54PM +0800, Jaya Kumar wrote:

> I'm not sure how standard that is. For example, I looked at the asus
> and toshiba drivers. These ACPI board drivers use
> /proc/acpi/somedevice/lcd. For example,

And, from a userspace perspective, it sucks. I'm in the process of 
writing patches to transition them all over, and I'd prefer not to have 
to write one for your driver as well :)

> I'll go take a look at that. I didn't look for an acpi driver outside
> of the drivers/acpi directory. But if that's the consensus, shouldn't
> someone also mod the toshiba and asus drivers?

I'm doing so.

> Standard wallmount stuff. There's 8 buttons on the one I'm using for
> testing. Vol up/down. Brightness up/down. Then several buttons for
> miscellaneous usage by people who customize the chassis. Most apps for
> this type of board are custom written and tend to just select on
> /proc/acpi/event.

Volume and brightness are things that can easily be exposed through the 
input layer, and if you're running X then it's much easier to handle 
events that come through the input layer than ones which come from 
acpi/events. There's four keycodes for programmable buttons specced (see 
/usr/include/linux/input.h - _PROG1-4), so that would fit quite nicely 
as well.

Doing it via the input layer adds flexibility - it makes it easier for 
non-root uesrspace to handle things, but you can still have a root-level 
daemon that monitors /dev/input/event* and runs commands in response to 
keycodes.

-- 
Matthew Garrett | mjg59@srcf.ucam.org