| Message ID | 49EE09D9.2060209@dell.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Delegated to: | Matthew Garrett |
| Headers | show |
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.
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
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?
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
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.
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
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?
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.
It's a precision M6300 - I'm afraid I'm not sure what BIOS it's running.
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, 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 :)
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
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.
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.
--- 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} };