Add support for Eject hotkey in dell-wmi

Hi:

I've gotten word that future Dell consumer laptops are transitioning several hotkeys to WMI instead. Here's a patch to enable the first to enable the Eject hotkey. I'm attaching it since my mail server (exchange) would mangle it otherwise.

Hi Matthew:

Quoted 3 lines · Matthew Garrett

On Mon, Apr 20, 2009 at 01:11:46PM -0500, Mario Limonciello wrote:

Quoted 3 lines

Looks good - can you confirm that it'll be removed from the normal keyboard interface at the same time?

No it won't be removed at the same time on all machines during the transition period. I've however requested to add a BIOS option for the machines that support this to try to enable or disable WMI support in the interim.

On Mon, Apr 20, 2009 at 01:11:46PM -0500, Mario Limonciello wrote:

Looks good - can you confirm that it'll be removed from the normal keyboard interface at the same time?

On Mon, Apr 20, 2009 at 01:25:57PM -0500, Mario Limonciello wrote:

Ok. How can we determine whether we're on a machine with this support? Applying this patch right now will result in systems receiving the event twice.

I've checked with the BIOS teams further, and they indicated at the time that this is enabled on those consumer systems, the hotkey should be switched over to a mechanical key rather than a software key, so the keyboard interface would not see this key. The support in the BIOS to turn on and off WMI would actually enable SMI hot key events instead (which could then be serviced by dell-laptop).

On Mon, Apr 20, 2009 at 01:44:09PM -0500, Mario Limonciello wrote:

Ah, ok, that's fine. As long as the event will only be delivered either via WMI or the keyboard controller then we should be good.

Hi:

I've got another patch to stack on top of yesterday's patch for Eject. These are more scancode/keycode combinations that will be supported via WMI. Many of them are commented out with an explanation of what their true functionality is.

On Tue, Apr 21, 2009 at 01:00:57PM -0500, Mario Limonciello wrote:

Hmm. I'll take a look over these - I was under the impression that Dell volume control was already of the software controlled type? The comments about the ones that will send events via both is a bit disconcerting, but I'll check how we're handling these keys at the moment.

Volume controls are still controlled via scan codes sent out by the EC. This means the behavior doesn't change at all. The keycodes that come via WMI are just to inform the OS (or more specifically an application on the OS) of the volume change.

Hm. But if we get the scancode, presumably we can do this anyway?

Hi Matthew:

Quoted 2 lines · Matthew Garrett

Hm. But if we get the scancode, presumably we can do this anyway?

Yes, this information might not be as useful on Linux as it is for the Windows situation. On Windows, the WMI event doesn't translate directly into a key, but rather a userspace application makes the changes. As it stands right now, the keys still don't do anything with my patch(s). They're at least documented however in case someone would like to change this behavior at some point.

On Tue, Apr 21, 2009 at 02:16:47PM -0500, Mario Limonciello wrote:

Ok. As long as there's a way of determining when a platform no longer sends scancodes (and so we can switch to WMI delivery), then that seems fine.

Taking another look at this, you've got:

drivers/platform/x86/dell-wmi.c renamed from drivers/platform/x86/dell-wmi.c~ +1 -1

-       {KE_KEY, 0xe045, KEY_PROG1},
+    {KE_KEY, 0xe045, KEY_NUMLOCK},

The hardware I have here uses 0xe045 for the power profile (or whatever it is) button above the keyboard. How do we differentiate these?

This is the version I'm planning on applying - look ok? I've skipped the OSD stuff, since right now we're not going to do anything terribly useful with them. I'd prefer some consensus on where we're going with these notifications.

commit d0cc3d9de1b8e97a7176ddc7efe48239896100c1

Author: Matthew Garrett <[email protected]>
Date:   Wed Apr 29 18:07:30 2009 +0100

From: Mario Limonciello <[email protected]>

dell-wmi: Add additional keyboard events

Upcoming Dell hardware will send more keyboard events via WMI. Add support for them.

Signed-off-by Mario Limonciello <[email protected]>

drivers/platform/x86/dell-wmi.c +34 -0

index 81d7179..847f486 100644
@@ -48,8 +48,49 @@ struct key_entry {
 
 enum { KE_KEY, KE_SW, KE_END };
 
+/*
+ * There are some additional events sent as scancodes, but these are
+ * not currently terribly relevant to Linux. They are:
+ * 
+ * 0xe020: Mute
+ * 0xe02e: Volume down
+ * 0xe030: Volume up
+ * 0xe00c: Keyboard illumination toggle
+ * 0xe033: Keyboard illumination up
+ * 0xe034: Keyboard illumination down
+ * 0xe00d: BIOS error detected
+ * 0xe013: Ambient light sensor toggle
+ * 0xe03a: Caps lock
+ * 0xe045: Num lock
+ * 0xe046: Scroll lock
+ *
+ * All of these are either notifications (rather than requests for change) or
+ * are also sent via the keyboard controller
+ */
+
 static struct key_entry dell_wmi_keymap[] = {
 	{KE_KEY, 0xe045, KEY_PROG1},
+        {KE_KEY, 0xe009, KEY_EJECTCD},
+
+	/* These also contain the brightness level at offset 6 */
+	{KE_KEY, 0xe006, KEY_BRIGHTNESSUP},
+	{KE_KEY, 0xe005, KEY_BRIGHTNESSDOWN},
+
+	/* The next device is at offset 6, the active devices are at
+	   offset 8 and the attached devices at offset 10 */
+	{KE_KEY, 0xe00b, KEY_DISPLAYTOGGLE},
+
+	/* This is actually for all radios. Although physically a
+	 * switch, the notification does not provide an indication of
+	 * state and so it should be reported as a key */
+	{KE_KEY, 0xe008, KEY_WLAN},

It's a precision M6300 - I'm afraid I'm not sure what BIOS it's running.

Quoted 1 line · Matthew Garrett

It's a precision M6300 - I'm afraid I'm not sure what BIOS it's running.

This works on Latitudes and Optiplexes, should be good for Precision as well:

# dmidecode | grep -C 5 'BIOS Info'

should get you (somewhere) this:

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: Dell Inc.
Version: A09
Release Date: 06/04/2008

It's a precision M6300 - I'm afraid I'm not sure what BIOS it's running.

I've obtained one of these and taken a look at it with a copy of Win 7 and compared with dell-wmi and my patchset applied. This platform's WMI support was introduced before Win7's WMI spec was drafted, and so it doesn't adhere to the spec. I think the best thing to do will be create a DMI table to match for keys that are only on a per system basis for anything before this spec was ready. I don't expect many other platforms like this, but it will allow for additional granularity in case something in the future ever deviates spec as well.

On Wed, Apr 29, 2009 at 04:24:47PM -0500, Mario Limonciello wrote:

Ok. Is there any programmatic way to determine whether a given Dell complies with your WMI spec or not? I'd prefer not to use DMI tables unless it's the only way to identify the machines - the risk is that there'll be something else that also uses its own codes and will just behave oddly until someone figures out why it's broken.

Oh, hmm, that's true. I'll rework it with that in mind.

This is the version I'm planning on applying - look ok? I've skipped the OSD stuff, since right now we're not going to do anything terribly useful with them. I'd prefer some consensus on where we're going with these notifications.

commit d0cc3d9de1b8e97a7176ddc7efe48239896100c1

Author: Matthew Garrett <[email protected]>
Date:   Wed Apr 29 18:07:30 2009 +0100

From: Mario Limonciello <[email protected]>

dell-wmi: Add additional keyboard events

Upcoming Dell hardware will send more keyboard events via WMI. Add support for them.

Signed-off-by Mario Limonciello <[email protected]>

drivers/platform/x86/dell-wmi.c +34 -0

index 81d7179..847f486 100644
@@ -48,8 +48,49 @@ struct key_entry {
 
 enum { KE_KEY, KE_SW, KE_END };
 
+/*
+ * There are some additional events sent as scancodes, but these are
+ * not currently terribly relevant to Linux. They are:
+ * 
+ * 0xe020: Mute
+ * 0xe02e: Volume down
+ * 0xe030: Volume up
+ * 0xe00c: Keyboard illumination toggle
+ * 0xe033: Keyboard illumination up
+ * 0xe034: Keyboard illumination down
+ * 0xe00d: BIOS error detected
+ * 0xe013: Ambient light sensor toggle
+ * 0xe03a: Caps lock
+ * 0xe045: Num lock
+ * 0xe046: Scroll lock
+ *
+ * All of these are either notifications (rather than requests for change) or
+ * are also sent via the keyboard controller
+ */
+
 static struct key_entry dell_wmi_keymap[] = {
 	{KE_KEY, 0xe045, KEY_PROG1},
+        {KE_KEY, 0xe009, KEY_EJECTCD},
+
+	/* These also contain the brightness level at offset 6 */
+	{KE_KEY, 0xe006, KEY_BRIGHTNESSUP},
+	{KE_KEY, 0xe005, KEY_BRIGHTNESSDOWN},
+
+	/* The next device is at offset 6, the active devices are at
+	   offset 8 and the attached devices at offset 10 */
+	{KE_KEY, 0xe00b, KEY_DISPLAYTOGGLE},
+
+	/* This is actually for all radios. Although physically a
+	 * switch, the notification does not provide an indication of
+	 * state and so it should be reported as a key */
+	{KE_KEY, 0xe008, KEY_WLAN},