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*
[email protected]
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 | [email protected]
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 | [email protected]
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*
[email protected]
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*
[email protected]
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 | [email protected]
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*
[email protected]
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*
[email protected]
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*
[email protected]
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*
[email protected]
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 | [email protected]
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*
[email protected]
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 | [email protected]
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*
[email protected]
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 | [email protected]
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*
[email protected]
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 | [email protected]
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]>
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 | [email protected]
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*
[email protected]
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 <[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]>
>
> 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*
[email protected]
Oh, hmm, that's true. I'll rework it with that in mind.
--
Matthew Garrett | [email protected]
It's a precision M6300 - I'm afraid I'm not sure what BIOS it's running.
--
Matthew Garrett | [email protected]
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
On Wed, Apr 29, 2009 at 03:23:49PM -0400, [email protected] 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 | [email protected]
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*
[email protected]
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 | [email protected]
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*
[email protected]