Untangling the sleep hotkey mess

Untangling the sleep hotkey mess

[Matthew Garrett]

Currently, there are three ways that a sleep hotkey may generate an 
event:

1) Exposed in DSDT as an ACPI object, generates an ACPI notification 
event (the "normal" way)

2) Uses hardware-specific ACPI driver, generates an ACPI notification 
event. Not exposed in the DSDT in any standard way (ibm-acpi, 
toshiba-acpi, panasonic-acpi)

3) Generates a scancode, which is picked up by the kernel and turned 
into a keycode (HP laptops work like this)

This is all quite horribly confusing, and makes life miserable for 
userspace. I would like to suggest the following standardisation:

a) Hal should assume that all hardware has a sleep key, since there's no 
way to actually tell.

b) Events generated in cases (1) and (2) should, for now, be caught by 
acpid (or something similar) and then fed back into the input layer via 
uinput. This should be scancode 142, which will end up as X keycode 223.

c) Most keyboards in case (3) will already send scancode 142. For 
laptops, those that shouldn't should be remapped at boot time by 
checking the system DMI information and consulting a lookup table.

Rationale:

Having one type of event rather than three makes it easier for userspace 
coders. Choosing to do it through the input layer lets people take 
advantage of pre-existing code for binding userspace events to keyboard 
events, and is significantly easier to do than getting keyboard events 
back to the ACPI layer. Keycode 142 is chosen because it's what 
Microsoft uses, and so most manufacturers who have taken this approach 
have copied them.

Future:

1) OSDL have just set up a mailing list 
(desktop_portables-qjLDD68F18O7TbgM5vRIOg@public.gmane.org) for discussion of userspace and 
laptop interaction. Can I encourage people who are interested in 
hammering out cross-distribution solutions to problems like this to 
subscribe?

2) /usr/include/linux/input.h defines two keycodes for suspend-type 
behaviour: KEY_SLEEP (scancode 142) and KEY_SUSPEND (scancode 205). I'd 
like to propose using the second of these for keys that trigger suspend 
to disk. There's much less standardisation here, though, so I'd be 
interested in hearing what other people think.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Untangling the sleep hotkey mess

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

On Sat, Jan 07, 2006 at 05:24:46PM +0000, Matthew Garrett wrote:
> a) Hal should assume that all hardware has a sleep key, since there's no 
> way to actually tell.

Why bring Hal into this equation?

> b) Events generated in cases (1) and (2) should, for now, be caught by 
> acpid (or something similar) and then fed back into the input layer via 
> uinput. This should be scancode 142, which will end up as X keycode 223.

And how would this work for users who doesn't have Hal installed?

Having ACPI hotkey events delivered as normal keyboard input makes it
difficult to run system scripts as root:root.

Regards,
Brix
-- 
Henrik Brix Andersen <brix-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

Re: Untangling the sleep hotkey mess

[Matthew Garrett]

On Sat, Jan 07, 2006 at 08:24:44PM +0100, Henrik Brix Andersen wrote:
> On Sat, Jan 07, 2006 at 05:24:46PM +0000, Matthew Garrett wrote:
> > a) Hal should assume that all hardware has a sleep key, since there's no 
> > way to actually tell.
> 
> Why bring Hal into this equation?

Because, over time, applications are likely to start worrying about what 
hal thinks in this respect. gnome-power-manager already listens for hal 
events related to the sleep button.

> > b) Events generated in cases (1) and (2) should, for now, be caught by 
> > acpid (or something similar) and then fed back into the input layer via 
> > uinput. This should be scancode 142, which will end up as X keycode 223.
> 
> And how would this work for users who doesn't have Hal installed?

I'm sorry, I don't understand the question. This is entirely independent 
of hal.

> Having ACPI hotkey events delivered as normal keyboard input makes it
> difficult to run system scripts as root:root.

But that does nothing to help systems which only expose sleep keys via 
the keyboard controller. It's not practical to get them to generate ACPI 
events - however, it /is/ practical to get ACPI events to generate input 
events. At that point there's nothing to stop a hotkey daemon running as 
root.
-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Untangling the sleep hotkey mess

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

On Sat, Jan 07, 2006 at 08:52:32PM +0000, Matthew Garrett wrote:
> On Sat, Jan 07, 2006 at 08:24:44PM +0100, Henrik Brix Andersen wrote:
> > Having ACPI hotkey events delivered as normal keyboard input makes it
> > difficult to run system scripts as root:root.
> 
> But that does nothing to help systems which only expose sleep keys via 
> the keyboard controller. It's not practical to get them to generate ACPI 
> events - however, it /is/ practical to get ACPI events to generate input 
> events. At that point there's nothing to stop a hotkey daemon running as 
> root.

So what you really propose is to abstract the handling of ACPI events
by yet another layer, a hotkey daemon?

./Brix
-- 
Henrik Brix Andersen <brix-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

Re: Untangling the sleep hotkey mess

[Matthew Garrett]

On Sat, Jan 07, 2006 at 10:01:03PM +0100, Henrik Brix Andersen wrote:

> So what you really propose is to abstract the handling of ACPI events
> by yet another layer, a hotkey daemon?

No, what I propose is that sleep keys end up generating the same 
userspace event no matter how they're connected. The easiest way to 
achieve that (that is, the one which requires the least amount of new 
code to be written) would be to do it through the input layer. If you 
then want to respond to events by running something as root, this would 
require a small daemon that monitors input events.

The current situation (where sleep keys may generate three different 
types of events) is getting somewhat untenable.
-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gpm] Untangling the sleep hotkey mess

[Richard Hughes]

On Sat, 2006-01-07 at 17:24 +0000, Matthew Garrett wrote:
> Currently, there are three ways that a sleep hotkey may generate an 
> event:
> 
> 1) Exposed in DSDT as an ACPI object, generates an ACPI notification 
> event (the "normal" way)
> 
> 2) Uses hardware-specific ACPI driver, generates an ACPI notification 
> event. Not exposed in the DSDT in any standard way (ibm-acpi, 
> toshiba-acpi, panasonic-acpi)
> 
> 3) Generates a scancode, which is picked up by the kernel and turned 
> into a keycode (HP laptops work like this)
> 
> This is all quite horribly confusing, and makes life miserable for 
> userspace.

Wholeheartedly agree.

>  I would like to suggest the following standardisation:
> 
> a) Hal should assume that all hardware has a sleep key, since there's no 
> way to actually tell.
> 
> b) Events generated in cases (1) and (2) should, for now, be caught by 
> acpid (or something similar) and then fed back into the input layer via 
> uinput. This should be scancode 142, which will end up as X keycode 223.

Yes, I proposed something similar here
[http://www.nabble.com/ACPI-to-uinput-bridge-t409384.html] -- using HAL
and uinput to send the keys to user-programs.

> c) Most keyboards in case (3) will already send scancode 142. For 
> laptops, those that shouldn't should be remapped at boot time by 
> checking the system DMI information and consulting a lookup table.

Yes, perhaps using the existing HAL infrastructure with FDI lookup
tables? We already have a HAL addon for watching ACPI events, and doing
things like refreshing the battery values, and emitting conditions for
the common buttons (lid, sleep, power) -- we could just extend this code
in the HAL addon.

The HAL addon is well tested, and plays nice with acpid if required.

> Rationale:
> 
> Having one type of event rather than three makes it easier for userspace 
> coders. Choosing to do it through the input layer lets people take 
> advantage of pre-existing code for binding userspace events to keyboard 
> events, and is significantly easier to do than getting keyboard events 
> back to the ACPI layer. Keycode 142 is chosen because it's what 
> Microsoft uses, and so most manufacturers who have taken this approach 
> have copied them.

Can we not go further and define Dock/UnDock,
BrightnessUp/BrightnessDown, Hibernate, etc?

Richard.

Re: [gpm] Untangling the sleep hotkey mess

[Matthew Garrett]

On Sun, Jan 08, 2006 at 12:58:44PM +0000, Richard Hughes wrote:

> Can we not go further and define Dock/UnDock,
> BrightnessUp/BrightnessDown, Hibernate, etc?

BrightnessUp/BrightnessDown have keycodes defined in 
/usr/src/linux/input.h, so that shouldn't be a problem. I suggested a 
keycode for hibernate (KEY_SUSPEND, with suspend to RAM on KEY_SLEEP). 
I'm less convinced about Dock/Undock - that's a problem that's so far 
from being solved I've no idea what sort of things userspace wants to 
know :)

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gpm] Untangling the sleep hotkey mess

[Richard Hughes]

On Sun, 2006-01-08 at 13:47 +0000, Matthew Garrett wrote:
> On Sun, Jan 08, 2006 at 12:58:44PM +0000, Richard Hughes wrote:
> 
> > Can we not go further and define Dock/UnDock,
> > BrightnessUp/BrightnessDown, Hibernate, etc?
> 
> BrightnessUp/BrightnessDown have keycodes defined in 
> /usr/src/linux/input.h, so that shouldn't be a problem. I suggested a 
> keycode for hibernate (KEY_SUSPEND, with suspend to RAM on KEY_SLEEP). 

Okay, that's good for me.

> I'm less convinced about Dock/Undock - that's a problem that's so far 
> from being solved I've no idea what sort of things userspace wants to 
> know :)

Sure, just an example of "other stuff". Lock is maybe a better example
as gnome-screensaver (or equiv) can respond to this.

The main problem now is implementation.

1. We use the current hodge-podge of methods now (like sony-pi, toshiba,
asus, raw etc) and define backends for all these modules.

2. We use the raw acpi device like Ubuntu do (exposes /dev/acpi) -- Is
this a long term solution? And this requires a kernel patch that I think
the linux-acpi people are unhappy with, and distros such as Fedora
wouldn't like (due to not being in vanilla kernel).

3. Use the new acpi kernel hotkeys stuff -- not that I really understand
the interface, nor how to use it correctly. Plus I'm not sure how much
of the vendor kernel modules can use this new interface, or if it's
suitable. It all seemed a bit fragile last time I looked.

Richard.

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gpm] Untangling the sleep hotkey mess

[Yu Luming]

>  3. Use the new acpi kernel hotkeys stuff -- not that I really understand
>  the interface, nor how to use it correctly. Plus I'm not sure how much
>  of the vendor kernel modules can use this new interface, or if it's
>  suitable. It all seemed a bit fragile last time I looked.

Please take a look at 
http://bugzilla.kernel.org/show_bug.cgi?id=5749

There are some examples to use hotkey.c for specific laptops with dedicated
hotkey acpi device objects , and dedicated AML methods.
This patch: http://bugzilla.kernel.org/show_bug.cgi?id=5749#c3
can be used to replace sony_acpi.c

This patch: http://bugzilla.kernel.org/show_bug.cgi?id=5749#c4
can be used to support brightness control for panasonic laptop.

This patch: http://bugzilla.kernel.org/show_bug.cgi?id=5749#c5
can be used to support brighness contrl for ASUS laptop.

Please notes, I will update these patch against len's testing tree, and 
ask for inclusion.

-- 
Thanks,
Luming
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gpm] Untangling the sleep hotkey mess

[Richard Hughes]

On Mon, 2006-01-09 at 09:10 +0800, Yu Luming wrote:
> >  3. Use the new acpi kernel hotkeys stuff -- not that I really understand
> >  the interface, nor how to use it correctly. Plus I'm not sure how much
> >  of the vendor kernel modules can use this new interface, or if it's
> >  suitable. It all seemed a bit fragile last time I looked.
> 
> Please take a look at 
> http://bugzilla.kernel.org/show_bug.cgi?id=5749
> 
> There are some examples to use hotkey.c for specific laptops with dedicated
> hotkey acpi device objects , and dedicated AML methods.
> This patch: http://bugzilla.kernel.org/show_bug.cgi?id=5749#c3
> can be used to replace sony_acpi.c
> 
> This patch: http://bugzilla.kernel.org/show_bug.cgi?id=5749#c4
> can be used to support brightness control for panasonic laptop.
> 
> This patch: http://bugzilla.kernel.org/show_bug.cgi?id=5749#c5
> can be used to support brighness contrl for ASUS laptop.
> 
> Please notes, I will update these patch against len's testing tree, and 
> ask for inclusion.

Why do we want to use the new hotkey stuff when we can just process all
the events in userspace using acpi events? The hotkey stuff seems
overcomplicated and fragile in my opinion.

Sending and receiving :::data:in:some::odd:format seems a little unusual
to me when we can just listen for the event in one place (like HAL) --
but then maybe I don't understand all the details. It's not like we will
have different programs registering for different acpi button events,
right?

Richard.

Re: [gpm] Untangling the sleep hotkey mess

[Richard Hughes]

[-- Attachment #1: Type: text/plain, Size: 2163 bytes --]

On Sun, 2006-01-08 at 14:13 +0000, Richard Hughes wrote:
> On Sun, 2006-01-08 at 13:47 +0000, Matthew Garrett wrote:
> > On Sun, Jan 08, 2006 at 12:58:44PM +0000, Richard Hughes wrote:
> > 
> > > Can we not go further and define Dock/UnDock,
> > > BrightnessUp/BrightnessDown, Hibernate, etc?
> > 
> > BrightnessUp/BrightnessDown have keycodes defined in 
> > /usr/src/linux/input.h, so that shouldn't be a problem. I suggested a 
> > keycode for hibernate (KEY_SUSPEND, with suspend to RAM on KEY_SLEEP). 
> 
> Okay, that's good for me.
> 
> > I'm less convinced about Dock/Undock - that's a problem that's so far 
> > from being solved I've no idea what sort of things userspace wants to 
> > know :)
> 
> Sure, just an example of "other stuff". Lock is maybe a better example
> as gnome-screensaver (or equiv) can respond to this.
> 
> The main problem now is implementation.

Further to the conversation on IRC, I've attached two ACPI patches to
provoke discussion.

The first creates the /org/freedesktop/Hal/devices/acpi_uinput like I
did for the toshiba specific HAL addon.
The second uses the acpi events for creating uinput events that can be
captured using gnome-keybindings, and also creates HAL ButtonPressed
events so that DBUS aware applications (like g-v-m and g-p-m) can
monitor the events.

To use this on toshiba, you have to use the kernel patch:
http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=commitdiff;h=84bd08e019f34628e6e5c276115db5baa46ea824;hp=cfed69e108d0ff7e3cc1e9330f662a1e758eb04d
which may be upstreamed soon. Plus you'll need 
"options toshiba_acpi hotkeys_over_acpi=1" in /etc/modprobe.conf to
enable the new stuff.

Also, to create the input events, you have to "modprobe uinput" and then
restart haldaemon -- so you could say this patch is rough and ready. :-)

Adding other id's (for example for IBM), the keys will just work with no
kernel patches required. Toshiba is special as the interface is unique
(and broken), so that's why we need the patch. Thanks to Matthew for the
pointer to the patch.

This 30 minute hack works for me, but has had little real-world testing.

Comments please.

Richard.

[-- Attachment #2: hal-add-vbutton.patch --]
[-- Type: text/x-patch, Size: 2342 bytes --]

Index: hald/linux2/acpi.c
===================================================================
RCS file: /cvs/hal/hal/hald/linux2/acpi.c,v
retrieving revision 1.43
diff -u -r1.43 acpi.c
--- hald/linux2/acpi.c	2 Dec 2005 17:11:00 -0000	1.43
+++ hald/linux2/acpi.c	2 Dec 2005 18:09:30 -0000
@@ -47,6 +47,7 @@
 	ACPI_TYPE_IBM_DISPLAY,
 	ACPI_TYPE_PANASONIC_DISPLAY,
 	ACPI_TYPE_SONY_DISPLAY,
+	ACPI_TYPE_VBUTTON,
 	ACPI_TYPE_BUTTON
 };
 
@@ -375,6 +376,27 @@
 	return TRUE;
 }
 
+static gboolean
+vbutton_refresh (HalDevice *d, ACPIDevHandler *handler)
+{
+	const char *path;
+	path = hal_device_property_get_string (d, "linux.acpi_path");
+	if (path == NULL)
+		return FALSE;
+
+	/* only set up device new if really needed */
+	if (!hal_device_has_capability (d, "button")){
+		device_property_atomic_update_begin ();
+		hal_device_property_set_string (d, "info.product", "Virtual Button");
+		hal_device_property_set_string (d, "info.category", "button");
+		hal_device_property_set_string (d, "button.type", "virtual");
+		hal_device_property_set_bool (d, "button.has_state", FALSE);
+		hal_device_add_capability (d, "button");
+		device_property_atomic_update_end ();
+	}
+	return TRUE;
+}
+
 /** Removes all the possible battery.* keys.
  *
  *  @param	d		Valid battery HalDevice
@@ -880,6 +902,10 @@
 	snprintf (path, sizeof (path), "%s/acpi/button/sleep", get_hal_proc_path ());
 	acpi_synthesize (path, ACPI_TYPE_BUTTON);
 
+	/* create the extra vbutton button */
+	snprintf (path, sizeof (path), "/dev/uinput");
+	acpi_synthesize_item (path, ACPI_TYPE_VBUTTON);
+
 	/*
 	 * Collect video adaptors (from vendor added modules)
 	 * I *know* we should use the /proc/acpi/video/LCD method, but this
@@ -1022,12 +1048,21 @@
 	.remove      = acpi_generic_remove
 };
 
+static ACPIDevHandler acpidev_handler_vbutton = {
+	.acpi_type   = ACPI_TYPE_VBUTTON,
+	.add         = acpi_generic_add,
+	.compute_udi = acpi_generic_compute_udi,
+	.refresh     = vbutton_refresh,
+	.remove      = acpi_generic_remove
+};
+
 static ACPIDevHandler *acpi_handlers[] = {
 	&acpidev_handler_battery,
 	&acpidev_handler_processor,
 	&acpidev_handler_fan,
 	&acpidev_handler_button,
 	&acpidev_handler_ac_adapter,
+	&acpidev_handler_vbutton,
 	&acpidev_handler_laptop_panel_toshiba,
 	&acpidev_handler_laptop_panel_ibm,
 	&acpidev_handler_laptop_panel_panasonic,

[-- Attachment #3: hal-uinput-new_part.patch --]
[-- Type: text/x-patch, Size: 5751 bytes --]

Index: hald/linux2/addons/addon-acpi.c
===================================================================
RCS file: /cvs/hal/hal/hald/linux2/addons/addon-acpi.c,v
retrieving revision 1.13
diff -u -r1.13 addon-acpi.c
--- hald/linux2/addons/addon-acpi.c	9 Nov 2005 21:13:30 -0000	1.13
+++ hald/linux2/addons/addon-acpi.c	9 Jan 2006 00:38:27 -0000
@@ -5,6 +5,7 @@
  *
  * Copyright (C) 2005 David Zeuthen, <david-o55+BOBDEFg@public.gmane.org>
  * Copyright (C) 2005 Ryan Lortie <desrt-0xnayjDhYQY@public.gmane.org>
+ * Copyright (C) 2006 Richard Hughes <richard-DRAXeJJ+PL1BDgjK7y7TUQ@public.gmane.org>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -26,6 +27,8 @@
 #  include <config.h>
 #endif
 
+#define	ACPI_UINPUT
+
 #include <stdio.h>
 #include <stdlib.h>
 #include <unistd.h>
@@ -37,10 +40,22 @@
 #include <sys/un.h>
 #include <fcntl.h>
 
+#ifdef ACPI_UINPUT
+#include <linux/input.h>
+#include <linux/uinput.h>
+#endif
+
 #include "libhal/libhal.h"
 
 #include "../probing/shared.h"
 
+#ifdef ACPI_UINPUT
+static int out_fd = -1;
+static int uinput_open (void);
+static int uinput_event (unsigned int key);
+static int uinput_close (void);
+#endif
+
 #ifdef ACPI_PROC
 static FILE *
 acpi_get_event_fp_kernel (void)
@@ -91,6 +106,142 @@
 }
 #endif
 
+#ifdef ACPI_UINPUT
+/** Opens the kernel uinput device
+ *  @return			Success
+ */
+static int
+uinput_open (void)
+{
+	int j, i;
+	struct uinput_user_dev udev_spec = { .name = "Virtual ACPI Keyboard" };
+
+	/* try to open uinput from all the different places it could be */
+	out_fd = open ("/dev/uinput", O_WRONLY | O_NDELAY);
+	if (out_fd < 0)		/* try harder */
+		out_fd = open ("/dev/input/uinput", O_WRONLY | O_NDELAY);
+	if (out_fd < 0)		/* try harder */
+		out_fd = open ("/dev/misc/uinput", O_WRONLY | O_NDELAY);
+	if (out_fd < 0) {	/* try harder */
+		printf ("Cannot open uinput (maybe not root?)\n");
+		return FALSE;
+	}
+
+	/* inform that we'll generate key events */
+	j  = ioctl (out_fd, UI_SET_EVBIT, EV_KEY) < 0;
+	j |= ioctl (out_fd, UI_SET_EVBIT, EV_REP) < 0;
+
+	/* set key events we can generate (in this case, all) */
+	for (i = KEY_RESERVED; i < BTN_MISC; i++)
+		j |= ioctl (out_fd, UI_SET_KEYBIT, i) < 0;
+	if (j) {
+		printf ("error setting up keyboard input device (maybe not root?)\n");
+		return FALSE;
+	}
+	/* write down information for creating a new device */
+	if (write (out_fd, &udev_spec, sizeof udev_spec) != sizeof udev_spec) {
+		printf ("error writing input device spec\n");
+		return FALSE;
+	}
+	/* create, and check */
+	if (ioctl (out_fd, UI_DEV_CREATE, 0) < 0) {
+		printf ("error creating input device\n");
+		return FALSE;
+	}
+	return TRUE;
+}
+#endif
+
+/** Writes to the /dev/uinput device a keypress, i.e. down then up
+ *
+ *  @param	key		The event, e.g KEY_BRIGHTNESSUP
+ *  @return			Success
+ */
+static int
+uinput_event (unsigned int key)
+{
+#ifdef ACPI_UINPUT
+	struct input_event event;
+	event.type = EV_KEY;
+	event.code = key;
+	event.value = 1;
+	if (write (out_fd, &event, sizeof event) != sizeof event) {
+		printf ("error writing down %d/%d/%d to device", EV_KEY, event.value, 1);
+		return FALSE;
+	}
+	event.value = 0;
+	if (write (out_fd, &event, sizeof event) != sizeof event) {
+		printf ("error writing up %d/%d/%d to device", EV_KEY, event.value, 0);
+		return FALSE;
+	}
+	return TRUE;
+#endif
+}
+
+#ifdef ACPI_UINPUT
+/** Closes the /dev/uinput device
+ *
+ *  @return			Success
+ */
+static int
+uinput_close (void)
+{
+	static struct input_event event = {
+		.type = EV_SYN,
+		.code = SYN_REPORT
+	};
+	if (!out_fd)
+		return FALSE;
+	write (out_fd, &event, sizeof event);
+	return TRUE;
+}
+#endif
+
+/** If found, does a uinput event and returns the condition name
+ *
+ *  @param	event		The acpi event
+ *  @return			The ButtonPressed condition
+ */
+static char *
+do_hkey_event (unsigned int event)
+{
+	/* Toshiba FnESC */
+	if (event == 0x101) {
+		uinput_event (KEY_MUTE);
+		return "Mute";
+	}
+	/* Toshiba FnF1 */
+	if (event == 0x13b) {
+		uinput_event (KEY_EXIT); /* need KEY_LOCK */
+		return "Lock";
+	}
+	/* Toshiba FnF2 */
+	if (event == 0x13c) {
+		uinput_event (KEY_SEARCH);
+		return "Search";
+	}
+	/* Toshiba FnF3 */
+	if (event == 0x13d) {
+		uinput_event (KEY_SUSPEND);
+		return "Suspend";
+	}
+	/* Toshiba FnF4 */
+	if (event == 0x13e) {
+		uinput_event (KEY_SLEEP);
+		return "Hibernate";
+	}
+	/* Toshiba FnF6 */
+	if (event == 0x140) {
+		uinput_event (KEY_BRIGHTNESSDOWN);
+		return "BrightnessDown";
+	}
+	/* Toshiba FnF7 */
+	if (event == 0x141) {
+		uinput_event (KEY_BRIGHTNESSUP);
+		return "BrightnessUp";
+	}
+	return NULL;
+}
 
 static void
 main_loop (LibHalContext *ctx, FILE *eventfp)
@@ -127,8 +278,18 @@
 			} else if (strncmp (acpi_path, "battery", sizeof ("battery") - 1) == 0) {
 				dbg ("battery event");
 				libhal_device_rescan (ctx, udi, &error);
+			} else if (strncmp (acpi_path, "hkey", sizeof ("hkey") - 1) == 0) {
+				dbg ("hotkey event; acpi_name=%s, acpi_num1=%i, acpi_num2=%i", acpi_name, acpi_num1, acpi_num2);
+				/* we only do events when the button is pressed, not released */
+				if (acpi_num1 == 1) {
+					char *desc;
+					const char *uinput_udi = "/org/freedesktop/Hal/devices/acpi_uinput";
+					desc = do_hkey_event (acpi_num2);
+					if (desc)
+						libhal_device_emit_condition (ctx, 
+							uinput_udi, "ButtonPressed", desc, &error);
+				}
 			}
-
 		} else {
 			dbg ("cannot parse event");
 		}
@@ -156,6 +317,10 @@
 		return 1;
 	}
 
+#ifdef ACPI_UINPUT
+	uinput_open ();
+#endif
+
 	while (1)
 	{
 #ifdef ACPI_PROC
@@ -178,6 +343,10 @@
 		sleep (5);
 	}
 
+#ifdef ACPI_UINPUT
+	uinput_close ();
+#endif
+
 	return 1;
 }
 

Re: [gpm] Untangling the sleep hotkey mess

[Dmitry Torokhov]

On Sunday 08 January 2006 20:14, Richard Hughes wrote:
> On Sun, 2006-01-08 at 14:13 +0000, Richard Hughes wrote:
> > On Sun, 2006-01-08 at 13:47 +0000, Matthew Garrett wrote:
> > > On Sun, Jan 08, 2006 at 12:58:44PM +0000, Richard Hughes wrote:
> > > 
> > > > Can we not go further and define Dock/UnDock,
> > > > BrightnessUp/BrightnessDown, Hibernate, etc?
> > > 
> > > BrightnessUp/BrightnessDown have keycodes defined in 
> > > /usr/src/linux/input.h, so that shouldn't be a problem. I suggested a 
> > > keycode for hibernate (KEY_SUSPEND, with suspend to RAM on KEY_SLEEP). 
> > 
> > Okay, that's good for me.
> > 
> > > I'm less convinced about Dock/Undock - that's a problem that's so far 
> > > from being solved I've no idea what sort of things userspace wants to 
> > > know :)
> > 
> > Sure, just an example of "other stuff". Lock is maybe a better example
> > as gnome-screensaver (or equiv) can respond to this.
> > 
> > The main problem now is implementation.
> 
> Further to the conversation on IRC, I've attached two ACPI patches to
> provoke discussion.
> 
> The first creates the /org/freedesktop/Hal/devices/acpi_uinput like I
> did for the toshiba specific HAL addon.
> The second uses the acpi events for creating uinput events that can be
> captured using gnome-keybindings, and also creates HAL ButtonPressed
> events so that DBUS aware applications (like g-v-m and g-p-m) can
> monitor the events.
>

I am sorry, but the scheme

	acpi->acpid->hal?->uinput->input_core->keyboard->...>userspace

is way too crazy.

Why don't we create an input handler that would feed certain events
from input layer to acpid via bus_acpi_generate_event(). This will
allow grateful migration of acpi buttons and other stuff to use
input layer:

	acpi->input_core->[new handler]->acpid


In the mean time hal can start using /dev/input/eventX to get those
events.

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gpm] Untangling the sleep hotkey mess

[Dmitry Torokhov]

On Monday 09 January 2006 00:24, Matthew Garrett wrote:
> On Mon, Jan 09, 2006 at 12:07:43AM -0500, Dmitry Torokhov wrote:
> 
> > Why don't we create an input handler that would feed certain events
> > from input layer to acpid via bus_acpi_generate_event().
> 
> I'm not convinced that making the input layer depend on ACPI (even 
> optionally) would go down terribly well. It also strikes me as *wrong* - 
> the sleep key on this keyboard has nothing to do with ACPI, whereas keys 
> presented through ACPI are still an input device.
> 

The handler is just for compatibility with present installations.
New installations will use the new interface, whatver it will be.
But input layer will be a hub of sorts and I am arguing for ACPI
to be converted to use input layer directly.

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gpm] Untangling the sleep hotkey mess

[Richard Hughes]

On Mon, 2006-01-09 at 01:09 -0500, Dmitry Torokhov wrote:
> On Monday 09 January 2006 00:24, Matthew Garrett wrote:
> > On Mon, Jan 09, 2006 at 12:07:43AM -0500, Dmitry Torokhov wrote:
> > 
> > > Why don't we create an input handler that would feed certain events
> > > from input layer to acpid via bus_acpi_generate_event().
> > 
> > I'm not convinced that making the input layer depend on ACPI (even 
> > optionally) would go down terribly well. It also strikes me as *wrong* - 
> > the sleep key on this keyboard has nothing to do with ACPI, whereas keys 
> > presented through ACPI are still an input device.
> > 
> 
> The handler is just for compatibility with present installations.
> New installations will use the new interface, whatver it will be.

Like what?

> But input layer will be a hub of sorts and I am arguing for ACPI
> to be converted to use input layer directly.

What does lkml think of ACPI using the input layer directly? 

Richard

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gpm] Untangling the sleep hotkey mess

[Matthew Garrett]

On Mon, Jan 09, 2006 at 12:07:43AM -0500, Dmitry Torokhov wrote:

> Why don't we create an input handler that would feed certain events
> from input layer to acpid via bus_acpi_generate_event().

I'm not convinced that making the input layer depend on ACPI (even 
optionally) would go down terribly well. It also strikes me as *wrong* - 
the sleep key on this keyboard has nothing to do with ACPI, whereas keys 
presented through ACPI are still an input device.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gpm] Untangling the sleep hotkey mess

[Richard Hughes]

On Mon, 2006-01-09 at 00:07 -0500, Dmitry Torokhov wrote: 
> On Sunday 08 January 2006 20:14, Richard Hughes wrote:
> > On Sun, 2006-01-08 at 14:13 +0000, Richard Hughes wrote:
> > > On Sun, 2006-01-08 at 13:47 +0000, Matthew Garrett wrote:
> > > > On Sun, Jan 08, 2006 at 12:58:44PM +0000, Richard Hughes wrote:
> > > > 
> > > > > Can we not go further and define Dock/UnDock,
> > > > > BrightnessUp/BrightnessDown, Hibernate, etc?
> > > > 
> > > > BrightnessUp/BrightnessDown have keycodes defined in 
> > > > /usr/src/linux/input.h, so that shouldn't be a problem. I suggested a 
> > > > keycode for hibernate (KEY_SUSPEND, with suspend to RAM on KEY_SLEEP). 
> > > 
> > > Okay, that's good for me.
> > > 
> > > > I'm less convinced about Dock/Undock - that's a problem that's so far 
> > > > from being solved I've no idea what sort of things userspace wants to 
> > > > know :)
> > > 
> > > Sure, just an example of "other stuff". Lock is maybe a better example
> > > as gnome-screensaver (or equiv) can respond to this.
> > > 
> > > The main problem now is implementation.
> > 
> > Further to the conversation on IRC, I've attached two ACPI patches to
> > provoke discussion.
> > 
> > The first creates the /org/freedesktop/Hal/devices/acpi_uinput like I
> > did for the toshiba specific HAL addon.
> > The second uses the acpi events for creating uinput events that can be
> > captured using gnome-keybindings, and also creates HAL ButtonPressed
> > events so that DBUS aware applications (like g-v-m and g-p-m) can
> > monitor the events.
> >
> 
> I am sorry, but the scheme
> 
> 	acpi->acpid->hal?->uinput->input_core->keyboard->...>userspace
> 

HAL does not require acpid to be running as it can listen to the socket
directly. Using HAL allows us to emit a ButtonPressed DBUS event for
session/system applications to listen for (like gnome-volume-manager and
gnome-power-manager) and also could use uinput so that stuff like the
"mute" hotkey can be caught by gnome-keybinding-properties so that the
session action could be taken.

So the call chain would look like this:

acpi->hal->gnome-volume-manager                (ButtonPressed)
acpi->hal->uinput->input_core->keyboard->g-k-p (uinput)

Plus, doing all the processing user-side, we can put the policy in HAL
(saying that hkey 0x140 is KEY_BRIGHTNESSDOWN), meaning we don't have to
update the kernel for every new laptop hotkey layout change.

> Why don't we create an input handler that would feed certain events
> from input layer to acpid via bus_acpi_generate_event(). This will
> allow grateful migration of acpi buttons and other stuff to use
> input layer:
> 
> 	acpi->input_core->[new handler]->acpid

What if the application wants a DBUS event rather than listening on /dev/input/X?

> In the mean time hal can start using /dev/input/eventX to get those
> events.

So in the kernel you want to put all the policy so that if
laptopmodel=foo and bios=bar and key=0x140 then output
KEY_BRIGHTNESSDOWN?

I've no problem using any input interface with HAL, as long as it's
unified between all the different acpi modules.

Even in the acpi kernel bits, there appears to be about half a dozen
different ways that buttons *could* get to userspace, without any
cooperation from the desktop guys and the kernel guys to an optimal
solution.

Sorry if this sounds a bit like a rant.

Richard.

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html