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 | [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
