Untangling the sleep hotkey mess

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 ([email protected]) 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 | [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

Why bring Hal into this equation?

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 <[email protected]>
Gentoo Metadistribution | Mobile computing herd

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.

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

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 | [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

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

./Brix

Henrik Brix Andersen <[email protected]>
Gentoo Metadistribution | Mobile computing herd

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 | [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

Wholeheartedly agree.

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.

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.

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

Richard.

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 | [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

Okay, that's good for me.

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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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.

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.

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
@@ -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,

Index: hald/linux2/addons/addon-acpi.c
===================================================================
RCS file: /cvs/hal/hal/hald/linux2/addons/addon-acpi.c,v retrieving revision 1.13

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 | [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

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.

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

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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Like what?

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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html