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-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
