Add support for Eject hotkey in dell-wmi

Add support for Eject hotkey in dell-wmi

[Mario Limonciello]

[-- Attachment #1.1: Type: text/plain, Size: 344 bytes --]

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.

Thanks,
-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: dell-wmi-eject.patch --]
[-- Type: text/x-patch; name="dell-wmi-eject.patch", Size: 310 bytes --]

--- a/drivers/platform/x86/dell-wmi.c~	2009-04-20 07:41:12.000000000 -0500
+++ b/drivers/platform/x86/dell-wmi.c	2009-04-20 07:42:04.000000000 -0500
@@ -50,6 +50,7 @@
 
 static struct key_entry dell_wmi_keymap[] = {
 	{KE_KEY, 0xe045, KEY_PROG1},
+	{KE_KEY, 0xe009, KEY_EJECTCD},
 	{KE_END, 0}
 };
 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Add support for Eject hotkey in dell-wmi

[Matthew Garrett]

On Mon, Apr 20, 2009 at 01:11:46PM -0500, Mario Limonciello wrote:
> 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.

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

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Add support for Eject hotkey in dell-wmi

[Mario Limonciello]

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

Hi Matthew:

Matthew Garrett wrote:
> 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?
>   
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.

Regards
-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Add support for Eject hotkey in dell-wmi

[Matthew Garrett]

On Mon, Apr 20, 2009 at 01:25:57PM -0500, Mario Limonciello wrote:
> Hi Matthew:
> Matthew Garrett wrote:
> > 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?
> >   
> 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.

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.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Add support for Eject hotkey in dell-wmi

[Mario Limonciello]

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

Hi Matthew

Matthew Garrett wrote:
> 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).

-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Add support for Eject hotkey in dell-wmi

[Matthew Garrett]

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

>    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).

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.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Add support for Eject hotkey in dell-wmi

[Mario Limonciello]

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

Hi Matthew:

Matthew Garrett wrote:
> 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.
>
>   
At least for consumer machines that I've heard, this will be the case. 
I'd expect the same policy for business client (Latitude etc), but I
don't know for sure.

Regards
-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[PATCH 1/3] Add support for more dell-wmi hotkeys

[Mario Limonciello]

[-- Attachment #1.1: Type: text/plain, Size: 340 bytes --]

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.

Regards
-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: dell-wmi-additional-keys.patch --]
[-- Type: text/x-patch; name="dell-wmi-additional-keys.patch", Size: 2749 bytes --]

--- a/drivers/platform/x86/dell-wmi.c~	2009-04-21 11:19:04.000000000 -0500
+++ a/drivers/platform/x86/dell-wmi.c	2009-04-21 11:51:39.000000000 -0500
@@ -49,8 +49,70 @@
 enum { KE_KEY, KE_SW, KE_END };
 
 static struct key_entry dell_wmi_keymap[] = {
-	{KE_KEY, 0xe045, KEY_PROG1},
 	{KE_KEY, 0xe009, KEY_EJECTCD},
+    
+    /* Inside the structure for a brightness keycode, a new brightness
+     * level will be reported after the scancode (at offset 6)
+     */
+    {KE_KEY, 0xe006, KEY_BRIGHTNESSUP},
+    {KE_KEY, 0xe005, KEY_BRIGHTNESSDOWN},
+    
+    /* The volume hotkeys are here so that the the OS
+     * can be notified and show an OSD. The keys will still
+     * send out a scan code via the EC.
+    {KE_KEY, 0xe030, KEY_VOLUMEUP},
+    {KE_KEY, 0xe02e, KEY_VOLUMEDOWN},
+    {KE_KEY, 0xe020, KEY_MUTE},
+    */
+    
+    /* A majority of platforms support a simple toggle event, but
+     * some actually have support to raise or lower the backlit keyboard
+     * brightness with different keys.
+     * The brightness is changed by the EC, these are here just to report
+     * that information to the OS to show an OSD.
+    {KE_KEY, 0xe00c, KEY_KBDILLUMTOGGLE},
+    {KE_KEY, 0xe033, KEY_KBDILLUMUP},
+    {KE_KEY, 0xe034, KEY_KBDILLUMDOWN},
+    */
+    
+    /* Inside the structure for a display switch, the next device is
+     * reported at offset 6, the active devices at offset 8, and the
+     * attached devices at offset 10
+     */
+    {KE_KEY, 0xe00b, KEY_DISPLAYTOGGLE},
+
+    /* This is actually for all radios on one button */
+    {KE_SW, 0xe008, KEY_WLAN},
+
+    /* Wifi Catcher */
+    {KE_KEY, 0xe011, KEY_PROG1},
+
+    /* Battery health status button */
+    {KE_KEY, 0xe007, KEY_BATTERY},
+    
+    /* This is the scan code sent when there is a BIOS error detected.
+     * What happens in these situations will need to be further elaborated
+     * upon
+    {KE_KEY, 0xe00d, error scan code},
+    */
+
+    /* Ambient light sensor is actually toggled by the BIOS and/or EC.
+     * This is for informative purposes of notifying the OS via an OSD.
+     * The new status will be at offset 6, the current limit at offset 8
+     * and the absolute limit at offset 10
+    {KE_KEY, 0xe013, ambient light sensor code},
+    */
+
+    /* The *lock keys are here so that the the OS
+     * can be notified and show an OSD. The keys will still
+     * send out a scan code via the EC.
+     * If the system contains LEDs for these buttons, the WMI
+     * events will not be sent out
+    {KE_KEY, 0x003a, KEY_CAPSLOCK},
+    {KE_KEY, 0xe045, KEY_NUMLOCK},
+    {KE_KEY, 0xe046, KEY_SCROLLLOCK},
+    */
+    
 	{KE_END, 0}
 };
 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Matthew Garrett]

On Tue, Apr 21, 2009 at 01:00:57PM -0500, Mario Limonciello wrote:
> 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.

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.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Mario Limonciello]

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

Hi Matthew:

Matthew Garrett wrote:
> 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.

On the Windows side this WMI event is used to display a volume OSD from
a Dell utility called Quick Set.

Regards
-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Matthew Garrett]

On Tue, Apr 21, 2009 at 02:06:45PM -0500, Mario Limonciello wrote:

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

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Mario Limonciello]

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

Hi Matthew:

Matthew Garrett wrote:
> 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.

Regards
-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Matthew Garrett]

On Tue, Apr 21, 2009 at 02:16:47PM -0500, Mario Limonciello wrote:
> Hi Matthew:
> 
> Matthew Garrett wrote:
> > 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.

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.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Mario Limonciello]

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

Hi Matthew:

Matthew Garrett wrote:
> 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.
>   
Looking at the specs for this next year, there is no plan to drop
sending the scancodes for the volume keys.  These were written with Win7
in mind, so at a minimum, this behavior wouldn't be changed until Win7+1.

A lot of the other keys I've hooked up through this however, platforms
will see these changes within the year.  I've tried to document which
keys will still send scan code events per that spec.

Regards
-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Matthew Garrett]

Taking another look at this, you've got:

-       {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?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Mario Limonciello]

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

Hi Matthew:

Matthew Garrett wrote:
> Taking another look at this, you've got:
>
> -       {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?
>   
What hardware is this?  I can look more to see why they are deviating
from the spec.  Also, are you on the latest BIOS for that box?  It's
possible it was a BIOS bug causing the wrong key to be sent.
-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Matthew Garrett]

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

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Valdis.Kletnieks]

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

On Wed, 29 Apr 2009 19:31:54 BST, Matthew Garrett said:
> 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


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

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Matthew Garrett]

On Wed, Apr 29, 2009 at 03:23:49PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 29 Apr 2009 19:31:54 BST, Matthew Garrett said:
> > 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
> 

Yeah, the issue is that the battery is flat and I can't find the PSU :)

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Mario Limonciello]

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

Hi Matthew:

Matthew Garrett wrote:
> 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.

Regards
-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Matthew Garrett]

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

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

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.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Mario Limonciello]

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

Hi Matthew:

Matthew Garrett wrote:
> 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.
>   
Not that I can easily discern.  The only relevant bit that i'm finding
is whether a key is reported as "programmable", which might be the case
for the M6300.  I'll try to look further into it to see if that's the
case here, and if that information can be flagged upon.
-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Matthew Garrett]

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 <mjg@redhat.com>
Date:   Wed Apr 29 18:07:30 2009 +0100

    From: Mario Limonciello <mario_limonciello@dell.com>
    
    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 <mario_limonciello@dell.com>

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 81d7179..847f486 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -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},
+
+	/* Wifi Catcher */
+	{KE_KEY, 0xe011, KEY_PROG2},
+
+	/* Battery health status button */
+	{KE_KEY, 0xe007, KEY_BATTERY},
+
 	{KE_END, 0}
 };
 

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Mario Limonciello]

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

Hi Matthew:

Matthew Garrett wrote:
> 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 <mjg@redhat.com>
> Date:   Wed Apr 29 18:07:30 2009 +0100
>
>     From: Mario Limonciello <mario_limonciello@dell.com>
>     
>     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 <mario_limonciello@dell.com>
>
> diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
> index 81d7179..847f486 100644
> --- a/drivers/platform/x86/dell-wmi.c
> +++ b/drivers/platform/x86/dell-wmi.c
> @@ -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},
> +
> +	/* Wifi Catcher */
> +	{KE_KEY, 0xe011, KEY_PROG2},
> +
> +	/* Battery health status button */
> +	{KE_KEY, 0xe007, KEY_BATTERY},
> +
>  	{KE_END, 0}
>  };
>   
Yeah, that patch looks good.  I personally still think it would  be 
better to "catch" the WMI events for those OSD type keys and do nothing
rather than litter them in dmesg, but this is sane for now otherwise.

-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Matthew Garrett]

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

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Mario Limonciello]

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

Hi Matthew:

Matthew Garrett wrote:
> Oh, hmm, that's true. I'll rework it with that in mind.
>   
Any updates on the rework?  What's wrong the approach I proposed before
to just tie them to a dummy key type until something better is available?

-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Matthew Garrett]

Sorry, I'm on vacation at the moment - I'll be back on the 18th, so 
should catch up with this then.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/3] Add support for more dell-wmi hotkeys

[Mario Limonciello]

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

Hi Matthew:

Matthew Garrett wrote:
> 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 <mjg@redhat.com>
> Date:   Wed Apr 29 18:07:30 2009 +0100
>
>     From: Mario Limonciello <mario_limonciello@dell.com>
>     
>     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 <mario_limonciello@dell.com>
>
> diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
> index 81d7179..847f486 100644
> --- a/drivers/platform/x86/dell-wmi.c
> +++ b/drivers/platform/x86/dell-wmi.c
> @@ -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},
> +
> +	/* Wifi Catcher */
> +	{KE_KEY, 0xe011, KEY_PROG2},
> +
> +	/* Battery health status button */
> +	{KE_KEY, 0xe007, KEY_BATTERY},
> +
>  	{KE_END, 0}
>  };
>   
Two additional comments:

1) Rather  than KEY_DISPLAYTOGGLE, it would make more sense to use
KEY_SWITCHVIDEOMODE.

2) There is another scancode that should be tied to KEY_SWITCHVIDEOMODE,
0xe09b.  Machines will support one or the other, but not both.

Regards

-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[PATCH 2/3] Don't load Dell-WMI on non WMI systems

[Mario Limonciello]

[-- Attachment #1.1: Type: text/plain, Size: 282 bytes --]

Hi:

I've noticed that the dell-wmi module will load on systems even if WMI
isn't supported.  As this is dependent upon BIOS version, dell-wmi
should return -ENODEV in these situations.

Regards
-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: dell-wmi-dont-load-on-non-wmi-system.patch --]
[-- Type: text/x-patch; name="dell-wmi-dont-load-on-non-wmi-system.patch", Size: 393 bytes --]

--- a/drivers/platform/x86/dell-wmi.c~	2009-04-21 12:41:50.000000000 -0500
+++ b/drivers/platform/x86/dell-wmi.c	2009-04-21 12:30:35.000000000 -0500
@@ -255,8 +255,10 @@
 			return err;
 		}
 
-	} else
-		printk(KERN_WARNING "dell-wmi: No known WMI GUID found\n");
+	} else {
+		printk(KERN_ERR "dell-wmi: No known WMI GUID found\n");
+		return -ENODEV;
+    }
 
 	return 0;
 }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[PATCH 3/3] Mark OSD type scancodes

[Mario Limonciello]

[-- Attachment #1.1: Type: text/plain, Size: 352 bytes --]

Hi:

This patch introduces a new scan code type for the purpose of events
that shouldn't send a keycode but the WMI event is still relevant. 
Eventually, these will need to be hooked up to the proper sysfs and
procfs interfaces for those types of events.

Regards
-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: dell-wmi-osd-events.patch --]
[-- Type: text/x-patch; name="dell-wmi-osd-events.patch", Size: 3170 bytes --]

--- a/drivers/platform/x86/dell-wmi.c~	2009-04-21 12:56:26.000000000 -0500
+++ b/drivers/platform/x86/dell-wmi.c	2009-04-21 12:54:41.000000000 -0500
@@ -46,7 +46,7 @@
 	u16 keycode;
 };
 
-enum { KE_KEY, KE_SW, KE_END };
+enum { KE_KEY, KE_SW, KE_OSD, KE_END };
 
 static struct key_entry dell_wmi_keymap[] = {
 	{KE_KEY, 0xe009, KEY_EJECTCD},
@@ -59,21 +59,20 @@
     
     /* The volume hotkeys are here so that the the OS
      * can be notified and show an OSD. The keys will still
-     * send out a scan code via the EC.
-    {KE_KEY, 0xe030, KEY_VOLUMEUP},
-    {KE_KEY, 0xe02e, KEY_VOLUMEDOWN},
-    {KE_KEY, 0xe020, KEY_MUTE},
-    */
+     * send out a scan code via the EC. */
+    {KE_OSD, 0xe030, KEY_VOLUMEUP},
+    {KE_OSD, 0xe02e, KEY_VOLUMEDOWN},
+    {KE_OSD, 0xe020, KEY_MUTE},
+    
     
     /* A majority of platforms support a simple toggle event, but
      * some actually have support to raise or lower the backlit keyboard
      * brightness with different keys.
      * The brightness is changed by the EC, these are here just to report
-     * that information to the OS to show an OSD.
-    {KE_KEY, 0xe00c, KEY_KBDILLUMTOGGLE},
-    {KE_KEY, 0xe033, KEY_KBDILLUMUP},
-    {KE_KEY, 0xe034, KEY_KBDILLUMDOWN},
-    */
+     * that information to the OS to show an OSD. */
+    {KE_OSD, 0xe00c, KEY_KBDILLUMTOGGLE},
+    {KE_OSD, 0xe033, KEY_KBDILLUMUP},
+    {KE_OSD, 0xe034, KEY_KBDILLUMDOWN},
     
     /* Inside the structure for a display switch, the next device is
      * reported at offset 6, the active devices at offset 8, and the
@@ -82,7 +81,7 @@
     {KE_KEY, 0xe00b, KEY_DISPLAYTOGGLE},
 
     /* This is actually for all radios on one button */
-    {KE_KEY, 0xe008, KEY_WLAN},
+    {KE_SW, 0xe008, SW_RFKILL_ALL},
 
     /* Wifi Catcher */
     {KE_KEY, 0xe011, KEY_PROG1},
@@ -99,19 +98,17 @@
     /* Ambient light sensor is actually toggled by the BIOS and/or EC.
      * This is for informative purposes of notifying the OS via an OSD.
      * The new status will be at offset 6, the current limit at offset 8
-     * and the absolute limit at offset 10
-    {KE_KEY, 0xe013, ambient light sensor code},
-    */
+     * and the absolute limit at offset 10 */
+    {KE_OSD, 0xe013, LED_MISC},
 
     /* The *lock keys are here so that the the OS
      * can be notified and show an OSD. The keys will still
      * send out a scan code via the EC.
      * If the system contains LEDs for these buttons, the WMI
-     * events will not be sent out
-    {KE_KEY, 0x003a, KEY_CAPSLOCK},
-    {KE_KEY, 0xe045, KEY_NUMLOCK},
-    {KE_KEY, 0xe046, KEY_SCROLLLOCK},
-    */
+     * events will not be sent out */
+    {KE_OSD, 0x003a, LED_CAPSL},
+    {KE_OSD, 0xe045, LED_NUML},
+    {KE_OSD, 0xe046, LED_SCROLLL},
     
 	{KE_END, 0}
 };
@@ -223,6 +220,10 @@
 			set_bit(EV_SW, dell_wmi_input_dev->evbit);
 			set_bit(key->keycode, dell_wmi_input_dev->swbit);
 			break;
+        case KE_OSD:
+            /* TODO, hook up to the right proc or sysfs interface for showing
+             * these status bits */
+            break;
 		}
 	}
 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]