| Message ID | 1463916983-12562-4-git-send-email-pali.rohar@gmail.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On 22/05/2016 13:36, Pali Rohár wrote: > ACPI DSDT tables have defined other WMI codes, but does not contain any > description when those codes are emitted. Some other codes can be found in > logs on internet. In this patch are all which I saw, but lot of them are > not tested properly (e.g. for duplicate events with AT keyboard). Now we > have all WMI event codes at one place and in future after proper testing > those codes can be correctly enabled or disabled... > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > --- > drivers/platform/x86/dell-wmi.c | 32 ++++++++++++++++++++++++++++++++ > 1 file changed, 32 insertions(+) > > diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c > index 363d927..7aac1dc 100644 > --- a/drivers/platform/x86/dell-wmi.c > +++ b/drivers/platform/x86/dell-wmi.c > @@ -110,6 +110,9 @@ static const struct key_entry dell_wmi_legacy_keymap[] __initconst = { > /* BIOS error detected */ > { KE_IGNORE, 0xe00d, { KEY_RESERVED } }, > > + /* Unknown, defined in ACPI DSDT */ > + /* { KE_IGNORE, 0xe00e, { KEY_RESERVED } }, */ > + I'm interested in knowing what's the meaning of this 0xe00e. This event is sent multiple times when I suspend/resume my laptop and it's definitely not a keypress. Anyway, I've been using this patch set and didn't notice any issue, so Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> > /* Wifi Catcher */ > { KE_KEY, 0xe011, { KEY_PROG2 } }, > > @@ -118,21 +121,45 @@ static const struct key_entry dell_wmi_legacy_keymap[] __initconst = { > > { KE_IGNORE, 0xe020, { KEY_MUTE } }, > > + /* Unknown, defined in ACPI DSDT */ > + /* { KE_IGNORE, 0xe023, { KEY_RESERVED } }, */ > + > + /* Untested, Dell Instant Launch key on Inspiron 7520 */ > + /* { KE_IGNORE, 0xe024, { KEY_RESERVED } }, */ > + > /* Dell Instant Launch key */ > { KE_KEY, 0xe025, { KEY_PROG4 } }, > > /* Audio panel key */ > { KE_IGNORE, 0xe026, { KEY_RESERVED } }, > > + /* Untested, Multimedia key on Dell Vostro 3560 */ > + /* { KE_IGNORE, 0xe028, { KEY_RESERVED } }, */ > + > /* Dell Instant Launch key */ > { KE_KEY, 0xe029, { KEY_PROG4 } }, > > + /* Untested, Windows Mobility Center button on Inspiron 7520 */ > + /* { KE_IGNORE, 0xe02a, { KEY_RESERVED } }, */ > + > + /* Unknown, defined in ACPI DSDT */ > + /* { KE_IGNORE, 0xe02b, { KEY_RESERVED } }, */ > + > + /* Untested, Dell Audio With Preset Switch button on Inspiron 7520 */ > + /* { KE_IGNORE, 0xe02c, { KEY_RESERVED } }, */ > + > { KE_IGNORE, 0xe02e, { KEY_VOLUMEDOWN } }, > { KE_IGNORE, 0xe030, { KEY_VOLUMEUP } }, > { KE_IGNORE, 0xe033, { KEY_KBDILLUMUP } }, > { KE_IGNORE, 0xe034, { KEY_KBDILLUMDOWN } }, > { KE_IGNORE, 0xe03a, { KEY_CAPSLOCK } }, > > + /* NIC Link is Up */ > + { KE_IGNORE, 0xe043, { KEY_RESERVED } }, > + > + /* NIC Link is Down */ > + { KE_IGNORE, 0xe044, { KEY_RESERVED } }, > + > /* > * This entry is very suspicious! > * Originally Matthew Garrett created this dell-wmi driver specially for > @@ -145,7 +172,12 @@ static const struct key_entry dell_wmi_legacy_keymap[] __initconst = { > */ > { KE_IGNORE, 0xe045, { KEY_NUMLOCK } }, > > + /* Scroll lock and also going to tablet mode on portable devices */ > { KE_IGNORE, 0xe046, { KEY_SCROLLLOCK } }, > + > + /* Untested, going from tablet mode on portable devices */ > + /* { KE_IGNORE, 0xe047, { KEY_RESERVED } }, */ > + > { KE_IGNORE, 0xe0f7, { KEY_MUTE } }, > { KE_IGNORE, 0xe0f8, { KEY_VOLUMEDOWN } }, > { KE_IGNORE, 0xe0f9, { KEY_VOLUMEUP } }, > -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> ACPI DSDT tables have defined other WMI codes, but does not contain any > description when those codes are emitted. Some other codes can be found in > logs on internet. In this patch are all which I saw, but lot of them are > not tested properly (e.g. for duplicate events with AT keyboard). Now we > have all WMI event codes at one place and in future after proper testing > those codes can be correctly enabled or disabled... > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > --- > drivers/platform/x86/dell-wmi.c | 32 ++++++++++++++++++++++++++++++++ > 1 file changed, 32 insertions(+) > > diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c > index 363d927..7aac1dc 100644 > --- a/drivers/platform/x86/dell-wmi.c > +++ b/drivers/platform/x86/dell-wmi.c > @@ -110,6 +110,9 @@ static const struct key_entry dell_wmi_legacy_keymap[] __initconst = { > /* BIOS error detected */ > { KE_IGNORE, 0xe00d, { KEY_RESERVED } }, > > + /* Unknown, defined in ACPI DSDT */ > + /* { KE_IGNORE, 0xe00e, { KEY_RESERVED } }, */ > + > /* Wifi Catcher */ > { KE_KEY, 0xe011, { KEY_PROG2 } }, > > @@ -118,21 +121,45 @@ static const struct key_entry dell_wmi_legacy_keymap[] __initconst = { > > { KE_IGNORE, 0xe020, { KEY_MUTE } }, > > + /* Unknown, defined in ACPI DSDT */ > + /* { KE_IGNORE, 0xe023, { KEY_RESERVED } }, */ > + > + /* Untested, Dell Instant Launch key on Inspiron 7520 */ > + /* { KE_IGNORE, 0xe024, { KEY_RESERVED } }, */ > + > /* Dell Instant Launch key */ > { KE_KEY, 0xe025, { KEY_PROG4 } }, > > /* Audio panel key */ > { KE_IGNORE, 0xe026, { KEY_RESERVED } }, > > + /* Untested, Multimedia key on Dell Vostro 3560 */ > + /* { KE_IGNORE, 0xe028, { KEY_RESERVED } }, */ > + > /* Dell Instant Launch key */ > { KE_KEY, 0xe029, { KEY_PROG4 } }, > > + /* Untested, Windows Mobility Center button on Inspiron 7520 */ > + /* { KE_IGNORE, 0xe02a, { KEY_RESERVED } }, */ > + > + /* Unknown, defined in ACPI DSDT */ > + /* { KE_IGNORE, 0xe02b, { KEY_RESERVED } }, */ > + > + /* Untested, Dell Audio With Preset Switch button on Inspiron 7520 */ > + /* { KE_IGNORE, 0xe02c, { KEY_RESERVED } }, */ > + > { KE_IGNORE, 0xe02e, { KEY_VOLUMEDOWN } }, > { KE_IGNORE, 0xe030, { KEY_VOLUMEUP } }, > { KE_IGNORE, 0xe033, { KEY_KBDILLUMUP } }, > { KE_IGNORE, 0xe034, { KEY_KBDILLUMDOWN } }, > { KE_IGNORE, 0xe03a, { KEY_CAPSLOCK } }, > > + /* NIC Link is Up */ > + { KE_IGNORE, 0xe043, { KEY_RESERVED } }, > + > + /* NIC Link is Down */ > + { KE_IGNORE, 0xe044, { KEY_RESERVED } }, > + > /* > * This entry is very suspicious! > * Originally Matthew Garrett created this dell-wmi driver specially for > @@ -145,7 +172,12 @@ static const struct key_entry dell_wmi_legacy_keymap[] __initconst = { > */ > { KE_IGNORE, 0xe045, { KEY_NUMLOCK } }, > > + /* Scroll lock and also going to tablet mode on portable devices */ > { KE_IGNORE, 0xe046, { KEY_SCROLLLOCK } }, > + > + /* Untested, going from tablet mode on portable devices */ > + /* { KE_IGNORE, 0xe047, { KEY_RESERVED } }, */ > + I have one more entry to add here: { KE_IGNORE, 0xe06e, { KEY_RESERVED } }, WMI event 0xe06e is emitted on a Vostro V131 when the Dell Support Center hotkey is pressed, along with an i8042 interrupt.
On Thursday 02 June 2016 12:41:53 Michał Kępień wrote: > I have one more entry to add here: > > { KE_IGNORE, 0xe06e, { KEY_RESERVED } }, > > WMI event 0xe06e is emitted on a Vostro V131 when the Dell Support > Center hotkey is pressed, along with an i8042 interrupt. Ok, I will add it to this list.
On Friday 27 May 2016 00:04:23 Gabriele Mazzotta wrote: > On 22/05/2016 13:36, Pali Rohár wrote: > > ACPI DSDT tables have defined other WMI codes, but does not contain any > > description when those codes are emitted. Some other codes can be found in > > logs on internet. In this patch are all which I saw, but lot of them are > > not tested properly (e.g. for duplicate events with AT keyboard). Now we > > have all WMI event codes at one place and in future after proper testing > > those codes can be correctly enabled or disabled... > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > > --- > > drivers/platform/x86/dell-wmi.c | 32 ++++++++++++++++++++++++++++++++ > > 1 file changed, 32 insertions(+) > > > > diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c > > index 363d927..7aac1dc 100644 > > --- a/drivers/platform/x86/dell-wmi.c > > +++ b/drivers/platform/x86/dell-wmi.c > > @@ -110,6 +110,9 @@ static const struct key_entry dell_wmi_legacy_keymap[] __initconst = { > > /* BIOS error detected */ > > { KE_IGNORE, 0xe00d, { KEY_RESERVED } }, > > > > + /* Unknown, defined in ACPI DSDT */ > > + /* { KE_IGNORE, 0xe00e, { KEY_RESERVED } }, */ > > + > > I'm interested in knowing what's the meaning of this 0xe00e. This > event is sent multiple times when I suspend/resume my laptop and > it's definitely not a keypress. From DSDT dumps which I have seen, I guess it could be something with battery charging... but that is only my guess. Mario, do you have any idea, what these unknown events are? > Anyway, I've been using this patch set and didn't notice any issue, so > > Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> > > > /* Wifi Catcher */ > > { KE_KEY, 0xe011, { KEY_PROG2 } }, > > > > @@ -118,21 +121,45 @@ static const struct key_entry dell_wmi_legacy_keymap[] __initconst = { > > > > { KE_IGNORE, 0xe020, { KEY_MUTE } }, > > > > + /* Unknown, defined in ACPI DSDT */ > > + /* { KE_IGNORE, 0xe023, { KEY_RESERVED } }, */ > > + > > + /* Untested, Dell Instant Launch key on Inspiron 7520 */ > > + /* { KE_IGNORE, 0xe024, { KEY_RESERVED } }, */ > > + > > /* Dell Instant Launch key */ > > { KE_KEY, 0xe025, { KEY_PROG4 } }, > > > > /* Audio panel key */ > > { KE_IGNORE, 0xe026, { KEY_RESERVED } }, > > > > + /* Untested, Multimedia key on Dell Vostro 3560 */ > > + /* { KE_IGNORE, 0xe028, { KEY_RESERVED } }, */ > > + > > /* Dell Instant Launch key */ > > { KE_KEY, 0xe029, { KEY_PROG4 } }, > > > > + /* Untested, Windows Mobility Center button on Inspiron 7520 */ > > + /* { KE_IGNORE, 0xe02a, { KEY_RESERVED } }, */ > > + > > + /* Unknown, defined in ACPI DSDT */ > > + /* { KE_IGNORE, 0xe02b, { KEY_RESERVED } }, */ > > + > > + /* Untested, Dell Audio With Preset Switch button on Inspiron 7520 */ > > + /* { KE_IGNORE, 0xe02c, { KEY_RESERVED } }, */ > > + > > { KE_IGNORE, 0xe02e, { KEY_VOLUMEDOWN } }, > > { KE_IGNORE, 0xe030, { KEY_VOLUMEUP } }, > > { KE_IGNORE, 0xe033, { KEY_KBDILLUMUP } }, > > { KE_IGNORE, 0xe034, { KEY_KBDILLUMDOWN } }, > > { KE_IGNORE, 0xe03a, { KEY_CAPSLOCK } }, > > > > + /* NIC Link is Up */ > > + { KE_IGNORE, 0xe043, { KEY_RESERVED } }, > > + > > + /* NIC Link is Down */ > > + { KE_IGNORE, 0xe044, { KEY_RESERVED } }, > > + > > /* > > * This entry is very suspicious! > > * Originally Matthew Garrett created this dell-wmi driver specially for > > @@ -145,7 +172,12 @@ static const struct key_entry dell_wmi_legacy_keymap[] __initconst = { > > */ > > { KE_IGNORE, 0xe045, { KEY_NUMLOCK } }, > > > > + /* Scroll lock and also going to tablet mode on portable devices */ > > { KE_IGNORE, 0xe046, { KEY_SCROLLLOCK } }, > > + > > + /* Untested, going from tablet mode on portable devices */ > > + /* { KE_IGNORE, 0xe047, { KEY_RESERVED } }, */ > > + > > { KE_IGNORE, 0xe0f7, { KEY_MUTE } }, > > { KE_IGNORE, 0xe0f8, { KEY_VOLUMEDOWN } }, > > { KE_IGNORE, 0xe0f9, { KEY_VOLUMEUP } }, > >
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQYWxpIFJvaMOhciBbbWFpbHRv OnBhbGkucm9oYXJAZ21haWwuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDcsIDIwMTYgNjow MCBQTQ0KPiBUbzogR2FicmllbGUgTWF6em90dGEgPGdhYnJpZWxlLm16dEBnbWFpbC5jb20+OyBM aW1vbmNpZWxsbywgTWFyaW8NCj4gPE1hcmlvX0xpbW9uY2llbGxvQERlbGwuY29tPg0KPiBDYzog TWF0dGhldyBHYXJyZXR0IDxtamc1OUBzcmNmLnVjYW0ub3JnPjsgRGFycmVuIEhhcnQNCj4gPGR2 aGFydEBpbmZyYWRlYWQub3JnPjsgTWljaGHFgiBLxJlwaWXFhCA8a2VybmVsQGtlbXBuaXUucGw+ OyBBbmR5IEx1dG9taXJza2kNCj4gPGx1dG9Aa2VybmVsLm9yZz47IEFsZXggSHVuZyA8YWxleC5o dW5nQGNhbm9uaWNhbC5jb20+OyBwbGF0Zm9ybS1kcml2ZXItDQo+IHg4NkB2Z2VyLmtlcm5lbC5v cmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCAz LzRdIGRlbGwtd21pOiBBZGQgaW5mb3JtYXRpb24gYWJvdXQgb3RoZXIgV01JIGV2ZW50DQo+IGNv ZGVzDQo+IA0KPiBPbiBGcmlkYXkgMjcgTWF5IDIwMTYgMDA6MDQ6MjMgR2FicmllbGUgTWF6em90 dGEgd3JvdGU6DQo+ID4gT24gMjIvMDUvMjAxNiAxMzozNiwgUGFsaSBSb2jDoXIgd3JvdGU6DQo+ ID4gPiBBQ1BJIERTRFQgdGFibGVzIGhhdmUgZGVmaW5lZCBvdGhlciBXTUkgY29kZXMsIGJ1dCBk b2VzIG5vdCBjb250YWluDQo+ID4gPiBhbnkgZGVzY3JpcHRpb24gd2hlbiB0aG9zZSBjb2RlcyBh cmUgZW1pdHRlZC4gU29tZSBvdGhlciBjb2RlcyBjYW4NCj4gPiA+IGJlIGZvdW5kIGluIGxvZ3Mg b24gaW50ZXJuZXQuIEluIHRoaXMgcGF0Y2ggYXJlIGFsbCB3aGljaCBJIHNhdywgYnV0DQo+ID4g PiBsb3Qgb2YgdGhlbSBhcmUgbm90IHRlc3RlZCBwcm9wZXJseSAoZS5nLiBmb3IgZHVwbGljYXRl IGV2ZW50cyB3aXRoDQo+ID4gPiBBVCBrZXlib2FyZCkuIE5vdyB3ZSBoYXZlIGFsbCBXTUkgZXZl bnQgY29kZXMgYXQgb25lIHBsYWNlIGFuZCBpbg0KPiA+ID4gZnV0dXJlIGFmdGVyIHByb3BlciB0 ZXN0aW5nIHRob3NlIGNvZGVzIGNhbiBiZSBjb3JyZWN0bHkgZW5hYmxlZCBvcg0KPiBkaXNhYmxl ZC4uLg0KPiA+ID4NCj4gPiA+IFNpZ25lZC1vZmYtYnk6IFBhbGkgUm9ow6FyIDxwYWxpLnJvaGFy QGdtYWlsLmNvbT4NCj4gPiA+IC0tLQ0KPiA+ID4gIGRyaXZlcnMvcGxhdGZvcm0veDg2L2RlbGwt d21pLmMgfCAgIDMyDQo+ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQo+ID4gPiAg MSBmaWxlIGNoYW5nZWQsIDMyIGluc2VydGlvbnMoKykNCj4gPiA+DQo+ID4gPiBkaWZmIC0tZ2l0 IGEvZHJpdmVycy9wbGF0Zm9ybS94ODYvZGVsbC13bWkuYw0KPiA+ID4gYi9kcml2ZXJzL3BsYXRm b3JtL3g4Ni9kZWxsLXdtaS5jIGluZGV4IDM2M2Q5MjcuLjdhYWMxZGMgMTAwNjQ0DQo+ID4gPiAt LS0gYS9kcml2ZXJzL3BsYXRmb3JtL3g4Ni9kZWxsLXdtaS5jDQo+ID4gPiArKysgYi9kcml2ZXJz L3BsYXRmb3JtL3g4Ni9kZWxsLXdtaS5jDQo+ID4gPiBAQCAtMTEwLDYgKzExMCw5IEBAIHN0YXRp YyBjb25zdCBzdHJ1Y3Qga2V5X2VudHJ5DQo+IGRlbGxfd21pX2xlZ2FjeV9rZXltYXBbXSBfX2lu aXRjb25zdCA9IHsNCj4gPiA+ICAJLyogQklPUyBlcnJvciBkZXRlY3RlZCAqLw0KPiA+ID4gIAl7 IEtFX0lHTk9SRSwgMHhlMDBkLCB7IEtFWV9SRVNFUlZFRCB9IH0sDQo+ID4gPg0KPiA+ID4gKwkv KiBVbmtub3duLCBkZWZpbmVkIGluIEFDUEkgRFNEVCAqLw0KPiA+ID4gKwkvKiB7IEtFX0lHTk9S RSwgMHhlMDBlLCB7IEtFWV9SRVNFUlZFRCB9IH0sICovDQo+ID4gPiArDQo+ID4NCj4gPiBJJ20g aW50ZXJlc3RlZCBpbiBrbm93aW5nIHdoYXQncyB0aGUgbWVhbmluZyBvZiB0aGlzIDB4ZTAwZS4g VGhpcw0KPiA+IGV2ZW50IGlzIHNlbnQgbXVsdGlwbGUgdGltZXMgd2hlbiBJIHN1c3BlbmQvcmVz dW1lIG15IGxhcHRvcCBhbmQgaXQncw0KPiA+IGRlZmluaXRlbHkgbm90IGEga2V5cHJlc3MuDQo+ IA0KPiBGcm9tIERTRFQgZHVtcHMgd2hpY2ggSSBoYXZlIHNlZW4sIEkgZ3Vlc3MgaXQgY291bGQg YmUgc29tZXRoaW5nIHdpdGggYmF0dGVyeQ0KPiBjaGFyZ2luZy4uLiBidXQgdGhhdCBpcyBvbmx5 IG15IGd1ZXNzLg0KPiANCj4gTWFyaW8sIGRvIHlvdSBoYXZlIGFueSBpZGVhLCB3aGF0IHRoZXNl IHVua25vd24gZXZlbnRzIGFyZT8NCg0KT2ZmLWhhbmQgSSdtIG5vdCBzdXJlLCBpdCB3b3VsZCBy ZXF1aXJlIHNvbWUgbW9yZSBkaWdnaW5nLg0KDQpDYW4geW91IHBsZWFzZSByZW1pbmQgbWUgd2hh dCBtb2RlbCBudW1iZXJzIGFuZCBCSU9TIGNvbWJpbmF0aW9ucyB5b3UgaGF2ZSANCmZvdW5kIGUw MGUgaW4gRFNEVCBhbmQgd2hhdCBjb250ZXh0IHRoZSBldmVudHMgYXJlIGFjdHVhbGx5IGhhcHBl bmluZz8gICANCkFueXRoaW5nIHJlbGVhc2VkIGluIHRoZSBwYXN0IHR3byB5ZWFycz8NCg0K -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/06/2016 08:02, Mario_Limonciello@Dell.com wrote: >> -----Original Message----- >> From: Pali Rohár [mailto:pali.rohar@gmail.com] >> Sent: Tuesday, June 7, 2016 6:00 PM >> To: Gabriele Mazzotta <gabriele.mzt@gmail.com>; Limonciello, Mario >> <Mario_Limonciello@Dell.com> >> Cc: Matthew Garrett <mjg59@srcf.ucam.org>; Darren Hart >> <dvhart@infradead.org>; Michał Kępień <kernel@kempniu.pl>; Andy Lutomirski >> <luto@kernel.org>; Alex Hung <alex.hung@canonical.com>; platform-driver- >> x86@vger.kernel.org; linux-kernel@vger.kernel.org >> Subject: Re: [PATCH 3/4] dell-wmi: Add information about other WMI event >> codes >> >> On Friday 27 May 2016 00:04:23 Gabriele Mazzotta wrote: >>> On 22/05/2016 13:36, Pali Rohár wrote: >>>> ACPI DSDT tables have defined other WMI codes, but does not contain >>>> any description when those codes are emitted. Some other codes can >>>> be found in logs on internet. In this patch are all which I saw, but >>>> lot of them are not tested properly (e.g. for duplicate events with >>>> AT keyboard). Now we have all WMI event codes at one place and in >>>> future after proper testing those codes can be correctly enabled or >> disabled... >>>> >>>> Signed-off-by: Pali Rohár <pali.rohar@gmail.com> >>>> --- >>>> drivers/platform/x86/dell-wmi.c | 32 >> ++++++++++++++++++++++++++++++++ >>>> 1 file changed, 32 insertions(+) >>>> >>>> diff --git a/drivers/platform/x86/dell-wmi.c >>>> b/drivers/platform/x86/dell-wmi.c index 363d927..7aac1dc 100644 >>>> --- a/drivers/platform/x86/dell-wmi.c >>>> +++ b/drivers/platform/x86/dell-wmi.c >>>> @@ -110,6 +110,9 @@ static const struct key_entry >> dell_wmi_legacy_keymap[] __initconst = { >>>> /* BIOS error detected */ >>>> { KE_IGNORE, 0xe00d, { KEY_RESERVED } }, >>>> >>>> + /* Unknown, defined in ACPI DSDT */ >>>> + /* { KE_IGNORE, 0xe00e, { KEY_RESERVED } }, */ >>>> + >>> >>> I'm interested in knowing what's the meaning of this 0xe00e. This >>> event is sent multiple times when I suspend/resume my laptop and it's >>> definitely not a keypress. >> >> From DSDT dumps which I have seen, I guess it could be something with battery >> charging... but that is only my guess. >> >> Mario, do you have any idea, what these unknown events are? > > Off-hand I'm not sure, it would require some more digging. > > Can you please remind me what model numbers and BIOS combinations you have > found e00e in DSDT and what context the events are actually happening? > Anything released in the past two years? > XPS13 9333, BIOS A07. I think I saw the event only after resuming from suspend and it's sent four times in a row. As Pali says, it seems to be related to the battery. There are three _Qxx ACPI methods in my DSDT sending this event: one stops battery charging, one detaches the battery and the last one stores a value on the GNVS. -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 08 June 2016 12:44:44 Gabriele Mazzotta wrote: > On 08/06/2016 08:02, Mario_Limonciello@Dell.com wrote: > >> -----Original Message----- > >> From: Pali Rohár [mailto:pali.rohar@gmail.com] > >> Sent: Tuesday, June 7, 2016 6:00 PM > >> To: Gabriele Mazzotta <gabriele.mzt@gmail.com>; Limonciello, Mario > >> <Mario_Limonciello@Dell.com> > >> Cc: Matthew Garrett <mjg59@srcf.ucam.org>; Darren Hart > >> <dvhart@infradead.org>; Michał Kępień <kernel@kempniu.pl>; Andy > >> Lutomirski <luto@kernel.org>; Alex Hung > >> <alex.hung@canonical.com>; platform-driver- x86@vger.kernel.org; > >> linux-kernel@vger.kernel.org > >> Subject: Re: [PATCH 3/4] dell-wmi: Add information about other WMI > >> event codes > >> > >> On Friday 27 May 2016 00:04:23 Gabriele Mazzotta wrote: > >>> On 22/05/2016 13:36, Pali Rohár wrote: > >>>> ACPI DSDT tables have defined other WMI codes, but does not > >>>> contain any description when those codes are emitted. Some > >>>> other codes can be found in logs on internet. In this patch are > >>>> all which I saw, but lot of them are not tested properly (e.g. > >>>> for duplicate events with AT keyboard). Now we have all WMI > >>>> event codes at one place and in future after proper testing > >>>> those codes can be correctly enabled or > >> > >> disabled... > >> > >>>> Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > >>>> --- > >>>> > >>>> drivers/platform/x86/dell-wmi.c | 32 > >> > >> ++++++++++++++++++++++++++++++++ > >> > >>>> 1 file changed, 32 insertions(+) > >>>> > >>>> diff --git a/drivers/platform/x86/dell-wmi.c > >>>> b/drivers/platform/x86/dell-wmi.c index 363d927..7aac1dc 100644 > >>>> --- a/drivers/platform/x86/dell-wmi.c > >>>> +++ b/drivers/platform/x86/dell-wmi.c > >>>> @@ -110,6 +110,9 @@ static const struct key_entry > >> > >> dell_wmi_legacy_keymap[] __initconst = { > >> > >>>> /* BIOS error detected */ > >>>> { KE_IGNORE, 0xe00d, { KEY_RESERVED } }, > >>>> > >>>> + /* Unknown, defined in ACPI DSDT */ > >>>> + /* { KE_IGNORE, 0xe00e, { KEY_RESERVED } }, */ > >>>> + > >>> > >>> I'm interested in knowing what's the meaning of this 0xe00e. This > >>> event is sent multiple times when I suspend/resume my laptop and > >>> it's definitely not a keypress. > >> > >> From DSDT dumps which I have seen, I guess it could be something > >> with battery charging... but that is only my guess. > >> > >> Mario, do you have any idea, what these unknown events are? > > > > Off-hand I'm not sure, it would require some more digging. > > > > Can you please remind me what model numbers and BIOS combinations > > you have found e00e in DSDT and what context the events are > > actually happening? Anything released in the past two years? > > XPS13 9333, BIOS A07. > > I think I saw the event only after resuming from suspend and > it's sent four times in a row. > > As Pali says, it seems to be related to the battery. There are > three _Qxx ACPI methods in my DSDT sending this event: one stops > battery charging, one detaches the battery and the last one stores > a value on the GNVS. Mario, were you able to identify something?
> -----Original Message----- > From: Pali Rohár [mailto:pali.rohar@gmail.com] > Sent: Wednesday, June 15, 2016 2:51 PM > To: Limonciello, Mario <Mario_Limonciello@Dell.com> > Cc: Gabriele Mazzotta <gabriele.mzt@gmail.com>; mjg59@srcf.ucam.org; > dvhart@infradead.org; kernel@kempniu.pl; luto@kernel.org; > alex.hung@canonical.com; platform-driver-x86@vger.kernel.org; linux- > kernel@vger.kernel.org > Subject: Re: [PATCH 3/4] dell-wmi: Add information about other WMI event > codes > > On Wednesday 08 June 2016 12:44:44 Gabriele Mazzotta wrote: > > On 08/06/2016 08:02, Mario_Limonciello@Dell.com wrote: > > >> -----Original Message----- > > >> From: Pali Rohár [mailto:pali.rohar@gmail.com] > > >> Sent: Tuesday, June 7, 2016 6:00 PM > > >> To: Gabriele Mazzotta <gabriele.mzt@gmail.com>; Limonciello, Mario > > >> <Mario_Limonciello@Dell.com> > > >> Cc: Matthew Garrett <mjg59@srcf.ucam.org>; Darren Hart > > >> <dvhart@infradead.org>; Michał Kępień <kernel@kempniu.pl>; Andy > > >> Lutomirski <luto@kernel.org>; Alex Hung > > >> <alex.hung@canonical.com>; platform-driver- x86@vger.kernel.org; > > >> linux-kernel@vger.kernel.org > > >> Subject: Re: [PATCH 3/4] dell-wmi: Add information about other WMI > > >> event codes > > >> > > >> On Friday 27 May 2016 00:04:23 Gabriele Mazzotta wrote: > > >>> On 22/05/2016 13:36, Pali Rohár wrote: > > >>>> ACPI DSDT tables have defined other WMI codes, but does not > > >>>> contain any description when those codes are emitted. Some > > >>>> other codes can be found in logs on internet. In this patch are > > >>>> all which I saw, but lot of them are not tested properly (e.g. > > >>>> for duplicate events with AT keyboard). Now we have all WMI > > >>>> event codes at one place and in future after proper testing > > >>>> those codes can be correctly enabled or > > >> > > >> disabled... > > >> > > >>>> Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > > >>>> --- > > >>>> > > >>>> drivers/platform/x86/dell-wmi.c | 32 > > >> > > >> ++++++++++++++++++++++++++++++++ > > >> > > >>>> 1 file changed, 32 insertions(+) > > >>>> > > >>>> diff --git a/drivers/platform/x86/dell-wmi.c > > >>>> b/drivers/platform/x86/dell-wmi.c index 363d927..7aac1dc 100644 > > >>>> --- a/drivers/platform/x86/dell-wmi.c > > >>>> +++ b/drivers/platform/x86/dell-wmi.c > > >>>> @@ -110,6 +110,9 @@ static const struct key_entry > > >> > > >> dell_wmi_legacy_keymap[] __initconst = { > > >> > > >>>> /* BIOS error detected */ > > >>>> { KE_IGNORE, 0xe00d, { KEY_RESERVED } }, > > >>>> > > >>>> + /* Unknown, defined in ACPI DSDT */ > > >>>> + /* { KE_IGNORE, 0xe00e, { KEY_RESERVED } }, */ > > >>>> + > > >>> > > >>> I'm interested in knowing what's the meaning of this 0xe00e. This > > >>> event is sent multiple times when I suspend/resume my laptop and > > >>> it's definitely not a keypress. > > >> > > >> From DSDT dumps which I have seen, I guess it could be something > > >> with battery charging... but that is only my guess. > > >> > > >> Mario, do you have any idea, what these unknown events are? > > > > > > Off-hand I'm not sure, it would require some more digging. > > > > > > Can you please remind me what model numbers and BIOS combinations > > > you have found e00e in DSDT and what context the events are > > > actually happening? Anything released in the past two years? > > > > XPS13 9333, BIOS A07. > > > > I think I saw the event only after resuming from suspend and > > it's sent four times in a row. > > > > As Pali says, it seems to be related to the battery. There are > > three _Qxx ACPI methods in my DSDT sending this event: one stops > > battery charging, one detaches the battery and the last one stores > > a value on the GNVS. > > Mario, were you able to identify something? > Pali, You aren't seeing this on the DSDT of your Latitude right? Gabriele, Your machine is from the year before XPS switched over to running the Dell business client (eg Latitude, Precision, Optiplex) BIOS. The EC in that machine does have support for "Battery Health" via that scancode. On Windows it's used for relaying battery information to an application called Quick Set. Thanks,
On Tuesday 21 June 2016 19:51:06 Mario_Limonciello@Dell.com wrote: > > -----Original Message----- > > From: Pali Rohár [mailto:pali.rohar@gmail.com] > > Sent: Wednesday, June 15, 2016 2:51 PM > > To: Limonciello, Mario <Mario_Limonciello@Dell.com> > > Cc: Gabriele Mazzotta <gabriele.mzt@gmail.com>; mjg59@srcf.ucam.org; > > dvhart@infradead.org; kernel@kempniu.pl; luto@kernel.org; > > alex.hung@canonical.com; platform-driver-x86@vger.kernel.org; linux- > > kernel@vger.kernel.org > > Subject: Re: [PATCH 3/4] dell-wmi: Add information about other WMI event > > codes > > > > On Wednesday 08 June 2016 12:44:44 Gabriele Mazzotta wrote: > > > On 08/06/2016 08:02, Mario_Limonciello@Dell.com wrote: > > > >> -----Original Message----- > > > >> From: Pali Rohár [mailto:pali.rohar@gmail.com] > > > >> Sent: Tuesday, June 7, 2016 6:00 PM > > > >> To: Gabriele Mazzotta <gabriele.mzt@gmail.com>; Limonciello, Mario > > > >> <Mario_Limonciello@Dell.com> > > > >> Cc: Matthew Garrett <mjg59@srcf.ucam.org>; Darren Hart > > > >> <dvhart@infradead.org>; Michał Kępień <kernel@kempniu.pl>; Andy > > > >> Lutomirski <luto@kernel.org>; Alex Hung > > > >> <alex.hung@canonical.com>; platform-driver- x86@vger.kernel.org; > > > >> linux-kernel@vger.kernel.org > > > >> Subject: Re: [PATCH 3/4] dell-wmi: Add information about other WMI > > > >> event codes > > > >> > > > >> On Friday 27 May 2016 00:04:23 Gabriele Mazzotta wrote: > > > >>> On 22/05/2016 13:36, Pali Rohár wrote: > > > >>>> ACPI DSDT tables have defined other WMI codes, but does not > > > >>>> contain any description when those codes are emitted. Some > > > >>>> other codes can be found in logs on internet. In this patch are > > > >>>> all which I saw, but lot of them are not tested properly (e.g. > > > >>>> for duplicate events with AT keyboard). Now we have all WMI > > > >>>> event codes at one place and in future after proper testing > > > >>>> those codes can be correctly enabled or > > > >> > > > >> disabled... > > > >> > > > >>>> Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > > > >>>> --- > > > >>>> > > > >>>> drivers/platform/x86/dell-wmi.c | 32 > > > >> > > > >> ++++++++++++++++++++++++++++++++ > > > >> > > > >>>> 1 file changed, 32 insertions(+) > > > >>>> > > > >>>> diff --git a/drivers/platform/x86/dell-wmi.c > > > >>>> b/drivers/platform/x86/dell-wmi.c index 363d927..7aac1dc 100644 > > > >>>> --- a/drivers/platform/x86/dell-wmi.c > > > >>>> +++ b/drivers/platform/x86/dell-wmi.c > > > >>>> @@ -110,6 +110,9 @@ static const struct key_entry > > > >> > > > >> dell_wmi_legacy_keymap[] __initconst = { > > > >> > > > >>>> /* BIOS error detected */ > > > >>>> { KE_IGNORE, 0xe00d, { KEY_RESERVED } }, > > > >>>> > > > >>>> + /* Unknown, defined in ACPI DSDT */ > > > >>>> + /* { KE_IGNORE, 0xe00e, { KEY_RESERVED } }, */ > > > >>>> + > > > >>> > > > >>> I'm interested in knowing what's the meaning of this 0xe00e. This > > > >>> event is sent multiple times when I suspend/resume my laptop and > > > >>> it's definitely not a keypress. > > > >> > > > >> From DSDT dumps which I have seen, I guess it could be something > > > >> with battery charging... but that is only my guess. > > > >> > > > >> Mario, do you have any idea, what these unknown events are? > > > > > > > > Off-hand I'm not sure, it would require some more digging. > > > > > > > > Can you please remind me what model numbers and BIOS combinations > > > > you have found e00e in DSDT and what context the events are > > > > actually happening? Anything released in the past two years? > > > > > > XPS13 9333, BIOS A07. > > > > > > I think I saw the event only after resuming from suspend and > > > it's sent four times in a row. > > > > > > As Pali says, it seems to be related to the battery. There are > > > three _Qxx ACPI methods in my DSDT sending this event: one stops > > > battery charging, one detaches the battery and the last one stores > > > a value on the GNVS. > > > > Mario, were you able to identify something? > > > Pali, > > You aren't seeing this on the DSDT of your Latitude right? Yes, I do not see it on Latitude. > Gabriele, > > Your machine is from the year before XPS switched over to running > the Dell business client (eg Latitude, Precision, Optiplex) BIOS. > > The EC in that machine does have support for "Battery Health" via > that scancode. On Windows it's used for relaying battery information > to an application called Quick Set. Do you have some details when it is send to OS? And how to read that that "battery health"?
> > You aren't seeing this on the DSDT of your Latitude right? > > Yes, I do not see it on Latitude. Thanks, the usage of this scan code is specific to consumer BIOSes. > > > Gabriele, > > > > Your machine is from the year before XPS switched over to running the > > Dell business client (eg Latitude, Precision, Optiplex) BIOS. > > > > The EC in that machine does have support for "Battery Health" via that > > scancode. On Windows it's used for relaying battery information to an > > application called Quick Set. > > Do you have some details when it is send to OS? And how to read that that > "battery health"? When a battery is removed or inserted this event is supposed to be received by quickset over WMI and then Quickset will re-read battery information. For Linux I don’t think this is necessary and a NOOP is appropriate. There is also a second place that some older laptops had a battery "hotkey" that would also emit 0xE00E. This was also picked up by quickset and would show battery information. This shouldn't be blocked by kernel, I'd expect if someone wants to bind this to another application from userspace they should be able to.
On Wednesday 22 June 2016 13:40:57 Mario_Limonciello@Dell.com wrote: > > > You aren't seeing this on the DSDT of your Latitude right? > > > > Yes, I do not see it on Latitude. > > Thanks, the usage of this scan code is specific to consumer BIOSes. > > > > > > Gabriele, > > > > > > Your machine is from the year before XPS switched over to running the > > > Dell business client (eg Latitude, Precision, Optiplex) BIOS. > > > > > > The EC in that machine does have support for "Battery Health" via that > > > scancode. On Windows it's used for relaying battery information to an > > > application called Quick Set. > > > > Do you have some details when it is send to OS? And how to read that that > > "battery health"? > > When a battery is removed or inserted this event is supposed to be received > by quickset over WMI and then Quickset will re-read battery information. So event is sent only if battery is removed or inserted? > For Linux I don’t think this is necessary and a NOOP is appropriate. > > There is also a second place that some older laptops had a battery "hotkey" > that would also emit 0xE00E. This was also picked up by quickset and would > show battery information. > > This shouldn't be blocked by kernel, I'd expect if someone wants to bind this > to another application from userspace they should be able to. Great! Can I send patch after which 0xe00e will be send to input layer as event KEY_BATTERY?
> -----Original Message----- > From: Pali Rohár [mailto:pali.rohar@gmail.com] > Sent: Wednesday, June 22, 2016 9:13 AM > To: Limonciello, Mario <Mario_Limonciello@Dell.com> > Cc: gabriele.mzt@gmail.com; mjg59@srcf.ucam.org; dvhart@infradead.org; > kernel@kempniu.pl; luto@kernel.org; alex.hung@canonical.com; platform- > driver-x86@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 3/4] dell-wmi: Add information about other WMI event > codes > > On Wednesday 22 June 2016 13:40:57 Mario_Limonciello@Dell.com wrote: > > > > You aren't seeing this on the DSDT of your Latitude right? > > > > > > Yes, I do not see it on Latitude. > > > > Thanks, the usage of this scan code is specific to consumer BIOSes. > > > > > > > > > Gabriele, > > > > > > > > Your machine is from the year before XPS switched over to running the > > > > Dell business client (eg Latitude, Precision, Optiplex) BIOS. > > > > > > > > The EC in that machine does have support for "Battery Health" via that > > > > scancode. On Windows it's used for relaying battery information to an > > > > application called Quick Set. > > > > > > Do you have some details when it is send to OS? And how to read that > that > > > "battery health"? > > > > When a battery is removed or inserted this event is supposed to be > received > > by quickset over WMI and then Quickset will re-read battery information. > > So event is sent only if battery is removed or inserted? > Yeah, that's what my spec says, I haven't tested this on actual system to see. I'm guessing what's going on is that during suspend ACPI battery drops off system and comes back up on resume. Maybe Gabriele can comment if any other times were noticed, but in any case I think it's appropriate for dell-wmi driver when receiving this on WMI to not do anything. Sending KEY_BATTERY would be wrong behavior. > > For Linux I don’t think this is necessary and a NOOP is appropriate. > > > > There is also a second place that some older laptops had a battery "hotkey" > > that would also emit 0xE00E. This was also picked up by quickset and would > > show battery information. > > > > This shouldn't be blocked by kernel, I'd expect if someone wants to bind > this > > to another application from userspace they should be able to. > > Great! Can I send patch after which 0xe00e will be send to input layer as > event KEY_BATTERY? > Well that's why I was mentioning this in two places. If it's received from keyboard recoding it as KEY_BATTERY sounds appropriate to me. If it's received from WMI, it really shouldn't be set as anything for Linux to do. I don't think any apps will benefit from the notification to re-read battery Information today.
On Wednesday 22 June 2016 14:21:25 Mario_Limonciello@Dell.com wrote: > > > For Linux I don’t think this is necessary and a NOOP is appropriate. > > > > > > There is also a second place that some older laptops had a battery "hotkey" > > > that would also emit 0xE00E. This was also picked up by quickset and would > > > show battery information. > > > > > > This shouldn't be blocked by kernel, I'd expect if someone wants to bind > > this > > > to another application from userspace they should be able to. > > > > Great! Can I send patch after which 0xe00e will be send to input layer as > > event KEY_BATTERY? > > > > Well that's why I was mentioning this in two places. If it's received from keyboard > recoding it as KEY_BATTERY sounds appropriate to me. If it's received from WMI, > it really shouldn't be set as anything for Linux to do. > > I don't think any apps will benefit from the notification to re-read battery > Information today. I mean for dell-wmi.c code. Why it should not be set to anything on Linux?
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQYWxpIFJvaMOhciBbbWFpbHRv OnBhbGkucm9oYXJAZ21haWwuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMjIsIDIwMTYg OToyNCBBTQ0KPiBUbzogTGltb25jaWVsbG8sIE1hcmlvIDxNYXJpb19MaW1vbmNpZWxsb0BEZWxs LmNvbT4NCj4gQ2M6IGdhYnJpZWxlLm16dEBnbWFpbC5jb207IG1qZzU5QHNyY2YudWNhbS5vcmc7 IGR2aGFydEBpbmZyYWRlYWQub3JnOw0KPiBrZXJuZWxAa2VtcG5pdS5wbDsgbHV0b0BrZXJuZWwu b3JnOyBhbGV4Lmh1bmdAY2Fub25pY2FsLmNvbTsgcGxhdGZvcm0tDQo+IGRyaXZlci14ODZAdmdl ci5rZXJuZWwub3JnOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJl OiBbUEFUQ0ggMy80XSBkZWxsLXdtaTogQWRkIGluZm9ybWF0aW9uIGFib3V0IG90aGVyIFdNSSBl dmVudA0KPiBjb2Rlcw0KPiANCj4gT24gV2VkbmVzZGF5IDIyIEp1bmUgMjAxNiAxNDoyMToyNSBN YXJpb19MaW1vbmNpZWxsb0BEZWxsLmNvbSB3cm90ZToNCj4gPiA+ID4gRm9yIExpbnV4IEkgZG9u 4oCZdCB0aGluayB0aGlzIGlzIG5lY2Vzc2FyeSBhbmQgYSBOT09QIGlzIGFwcHJvcHJpYXRlLg0K PiA+ID4gPg0KPiA+ID4gPiBUaGVyZSBpcyBhbHNvIGEgc2Vjb25kIHBsYWNlIHRoYXQgc29tZSBv bGRlciBsYXB0b3BzIGhhZCBhIGJhdHRlcnkNCj4gImhvdGtleSINCj4gPiA+ID4gdGhhdCB3b3Vs ZCBhbHNvIGVtaXQgMHhFMDBFLiAgVGhpcyB3YXMgYWxzbyBwaWNrZWQgdXAgYnkgcXVpY2tzZXQg YW5kDQo+IHdvdWxkDQo+ID4gPiA+IHNob3cgYmF0dGVyeSBpbmZvcm1hdGlvbi4NCj4gPiA+ID4N Cj4gPiA+ID4gVGhpcyBzaG91bGRuJ3QgYmUgYmxvY2tlZCBieSBrZXJuZWwsIEknZCBleHBlY3Qg aWYgc29tZW9uZSB3YW50cyB0bw0KPiBiaW5kDQo+ID4gPiB0aGlzDQo+ID4gPiA+IHRvIGFub3Ro ZXIgYXBwbGljYXRpb24gZnJvbSB1c2Vyc3BhY2UgdGhleSBzaG91bGQgYmUgYWJsZSB0by4NCj4g PiA+DQo+ID4gPiBHcmVhdCEgQ2FuIEkgc2VuZCBwYXRjaCBhZnRlciB3aGljaCAweGUwMGUgd2ls bCBiZSBzZW5kIHRvIGlucHV0IGxheWVyIGFzDQo+ID4gPiBldmVudCBLRVlfQkFUVEVSWT8NCj4g PiA+DQo+ID4NCj4gPiBXZWxsIHRoYXQncyB3aHkgSSB3YXMgbWVudGlvbmluZyB0aGlzIGluIHR3 byBwbGFjZXMuICBJZiBpdCdzIHJlY2VpdmVkIGZyb20NCj4ga2V5Ym9hcmQNCj4gPiByZWNvZGlu ZyBpdCBhcyBLRVlfQkFUVEVSWSBzb3VuZHMgYXBwcm9wcmlhdGUgdG8gbWUuICBJZiBpdCdzIHJl Y2VpdmVkIGZyb20NCj4gV01JLA0KPiA+IGl0IHJlYWxseSBzaG91bGRuJ3QgYmUgc2V0IGFzIGFu eXRoaW5nIGZvciBMaW51eCB0byBkby4NCj4gPg0KPiA+IEkgZG9uJ3QgdGhpbmsgYW55IGFwcHMg d2lsbCBiZW5lZml0IGZyb20gdGhlIG5vdGlmaWNhdGlvbiB0byByZS1yZWFkIGJhdHRlcnkNCj4g PiBJbmZvcm1hdGlvbiB0b2RheS4NCj4gDQo+IEkgbWVhbiBmb3IgZGVsbC13bWkuYyBjb2RlLg0K PiBXaHkgaXQgc2hvdWxkIG5vdCBiZSBzZXQgdG8gYW55dGhpbmcgb24gTGludXg/DQo+IA0KDQpP biBXaW5kb3dzIFF1aWNrc2V0IGlzIGEgc2VwYXJhdGUgYXBwbGljYXRpb24gZnJvbSBidWlsdC1p biBXaW5kb3dzIGJhdHRlcnkgDQphcHBsZXQuICBJdCBzaG93cyBzaW1pbGFyIHR5cGVzIG9mIGlu Zm9ybWF0aW9uIGFzIGdub21lLXBvd2VyLW1hbmFnZXIgZG9lcywgDQpidXQgYmVjYXVzZSBpdCdz IG5vdCBwYXJ0IG9mIHRoZSBPUywgaXQgZG9lc24ndCBnZXQgbm90aWZpY2F0aW9ucyBsaWtlIHRo aXMgc28gDQpzcGVjaWFsIEJJT1MgaG9va3MgYXJlIGluIHBsYWNlIGZvciBpdCB0byBrbm93IHdo ZW4gdG8gcmUtcmVhZCBiYXR0ZXJ5DQppbmZvcm1hdGlvbi4NCg0KT24gTGludXgsIHRoZXJlIGFy ZSBhbHJlYWR5IGluZnJhc3RydWN0dXJlIGZvciBiYXR0ZXJ5IHJlbW92YWwgYW5kIGFkZGluZyAN Cm5vdGlmaWNhdGlvbnMgZnJvbSBBQ1BJLiAgU2VuZGluZyB0aGlzIHVwIHRvIHVzZXIgc3BhY2Ug d29uJ3QgYmUgdXNlZnVsLg0K -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 22 June 2016 14:28:37 Mario_Limonciello@Dell.com wrote: > > -----Original Message----- > > From: Pali Rohár [mailto:pali.rohar@gmail.com] > > Sent: Wednesday, June 22, 2016 9:24 AM > > To: Limonciello, Mario <Mario_Limonciello@Dell.com> > > Cc: gabriele.mzt@gmail.com; mjg59@srcf.ucam.org; dvhart@infradead.org; > > kernel@kempniu.pl; luto@kernel.org; alex.hung@canonical.com; platform- > > driver-x86@vger.kernel.org; linux-kernel@vger.kernel.org > > Subject: Re: [PATCH 3/4] dell-wmi: Add information about other WMI event > > codes > > > > On Wednesday 22 June 2016 14:21:25 Mario_Limonciello@Dell.com wrote: > > > > > For Linux I don’t think this is necessary and a NOOP is appropriate. > > > > > > > > > > There is also a second place that some older laptops had a battery > > "hotkey" > > > > > that would also emit 0xE00E. This was also picked up by quickset and > > would > > > > > show battery information. > > > > > > > > > > This shouldn't be blocked by kernel, I'd expect if someone wants to > > bind > > > > this > > > > > to another application from userspace they should be able to. > > > > > > > > Great! Can I send patch after which 0xe00e will be send to input layer as > > > > event KEY_BATTERY? > > > > > > > > > > Well that's why I was mentioning this in two places. If it's received from > > keyboard > > > recoding it as KEY_BATTERY sounds appropriate to me. If it's received from > > WMI, > > > it really shouldn't be set as anything for Linux to do. > > > > > > I don't think any apps will benefit from the notification to re-read battery > > > Information today. > > > > I mean for dell-wmi.c code. > > Why it should not be set to anything on Linux? > > > > On Windows Quickset is a separate application from built-in Windows battery > applet. It shows similar types of information as gnome-power-manager does, > but because it's not part of the OS, it doesn't get notifications like this so > special BIOS hooks are in place for it to know when to re-read battery > information. > > On Linux, there are already infrastructure for battery removal and adding > notifications from ACPI. Sending this up to user space won't be useful. Errr. I mean WMI event 0xe00e which you wrote is emitted when user press battery key. And I think this event should be sent by dell-wmi.c as KEY_BATTERY.
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQYWxpIFJvaMOhciBbbWFpbHRv OnBhbGkucm9oYXJAZ21haWwuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMjIsIDIwMTYg OTozMSBBTQ0KPiBUbzogTGltb25jaWVsbG8sIE1hcmlvIDxNYXJpb19MaW1vbmNpZWxsb0BEZWxs LmNvbT4NCj4gQ2M6IGdhYnJpZWxlLm16dEBnbWFpbC5jb207IG1qZzU5QHNyY2YudWNhbS5vcmc7 IGR2aGFydEBpbmZyYWRlYWQub3JnOw0KPiBrZXJuZWxAa2VtcG5pdS5wbDsgbHV0b0BrZXJuZWwu b3JnOyBhbGV4Lmh1bmdAY2Fub25pY2FsLmNvbTsgcGxhdGZvcm0tDQo+IGRyaXZlci14ODZAdmdl ci5rZXJuZWwub3JnOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJl OiBbUEFUQ0ggMy80XSBkZWxsLXdtaTogQWRkIGluZm9ybWF0aW9uIGFib3V0IG90aGVyIFdNSSBl dmVudA0KPiBjb2Rlcw0KPiANCj4gT24gV2VkbmVzZGF5IDIyIEp1bmUgMjAxNiAxNDoyODozNyBN YXJpb19MaW1vbmNpZWxsb0BEZWxsLmNvbSB3cm90ZToNCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBQYWxpIFJvaMOhciBbbWFpbHRvOnBhbGkucm9oYXJAZ21h aWwuY29tXQ0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDIyLCAyMDE2IDk6MjQgQU0NCj4g PiA+IFRvOiBMaW1vbmNpZWxsbywgTWFyaW8gPE1hcmlvX0xpbW9uY2llbGxvQERlbGwuY29tPg0K PiA+ID4gQ2M6IGdhYnJpZWxlLm16dEBnbWFpbC5jb207IG1qZzU5QHNyY2YudWNhbS5vcmc7DQo+ IGR2aGFydEBpbmZyYWRlYWQub3JnOw0KPiA+ID4ga2VybmVsQGtlbXBuaXUucGw7IGx1dG9Aa2Vy bmVsLm9yZzsgYWxleC5odW5nQGNhbm9uaWNhbC5jb207DQo+IHBsYXRmb3JtLQ0KPiA+ID4gZHJp dmVyLXg4NkB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmcNCj4g PiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMy80XSBkZWxsLXdtaTogQWRkIGluZm9ybWF0aW9uIGFi b3V0IG90aGVyIFdNSQ0KPiBldmVudA0KPiA+ID4gY29kZXMNCj4gPiA+DQo+ID4gPiBPbiBXZWRu ZXNkYXkgMjIgSnVuZSAyMDE2IDE0OjIxOjI1IE1hcmlvX0xpbW9uY2llbGxvQERlbGwuY29tDQo+ IHdyb3RlOg0KPiA+ID4gPiA+ID4gRm9yIExpbnV4IEkgZG9u4oCZdCB0aGluayB0aGlzIGlzIG5l Y2Vzc2FyeSBhbmQgYSBOT09QIGlzIGFwcHJvcHJpYXRlLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+IFRoZXJlIGlzIGFsc28gYSBzZWNvbmQgcGxhY2UgdGhhdCBzb21lIG9sZGVyIGxhcHRvcHMg aGFkIGEgYmF0dGVyeQ0KPiA+ID4gImhvdGtleSINCj4gPiA+ID4gPiA+IHRoYXQgd291bGQgYWxz byBlbWl0IDB4RTAwRS4gIFRoaXMgd2FzIGFsc28gcGlja2VkIHVwIGJ5IHF1aWNrc2V0DQo+IGFu ZA0KPiA+ID4gd291bGQNCj4gPiA+ID4gPiA+IHNob3cgYmF0dGVyeSBpbmZvcm1hdGlvbi4NCj4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBUaGlzIHNob3VsZG4ndCBiZSBibG9ja2VkIGJ5IGtlcm5l bCwgSSdkIGV4cGVjdCBpZiBzb21lb25lIHdhbnRzIHRvDQo+ID4gPiBiaW5kDQo+ID4gPiA+ID4g dGhpcw0KPiA+ID4gPiA+ID4gdG8gYW5vdGhlciBhcHBsaWNhdGlvbiBmcm9tIHVzZXJzcGFjZSB0 aGV5IHNob3VsZCBiZSBhYmxlIHRvLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gR3JlYXQhIENhbiBJ IHNlbmQgcGF0Y2ggYWZ0ZXIgd2hpY2ggMHhlMDBlIHdpbGwgYmUgc2VuZCB0byBpbnB1dCBsYXll cg0KPiBhcw0KPiA+ID4gPiA+IGV2ZW50IEtFWV9CQVRURVJZPw0KPiA+ID4gPiA+DQo+ID4gPiA+ DQo+ID4gPiA+IFdlbGwgdGhhdCdzIHdoeSBJIHdhcyBtZW50aW9uaW5nIHRoaXMgaW4gdHdvIHBs YWNlcy4gIElmIGl0J3MgcmVjZWl2ZWQgZnJvbQ0KPiA+ID4ga2V5Ym9hcmQNCj4gPiA+ID4gcmVj b2RpbmcgaXQgYXMgS0VZX0JBVFRFUlkgc291bmRzIGFwcHJvcHJpYXRlIHRvIG1lLiAgSWYgaXQn cyByZWNlaXZlZA0KPiBmcm9tDQo+ID4gPiBXTUksDQo+ID4gPiA+IGl0IHJlYWxseSBzaG91bGRu J3QgYmUgc2V0IGFzIGFueXRoaW5nIGZvciBMaW51eCB0byBkby4NCj4gPiA+ID4NCj4gPiA+ID4g SSBkb24ndCB0aGluayBhbnkgYXBwcyB3aWxsIGJlbmVmaXQgZnJvbSB0aGUgbm90aWZpY2F0aW9u IHRvIHJlLXJlYWQNCj4gYmF0dGVyeQ0KPiA+ID4gPiBJbmZvcm1hdGlvbiB0b2RheS4NCj4gPiA+ DQo+ID4gPiBJIG1lYW4gZm9yIGRlbGwtd21pLmMgY29kZS4NCj4gPiA+IFdoeSBpdCBzaG91bGQg bm90IGJlIHNldCB0byBhbnl0aGluZyBvbiBMaW51eD8NCj4gPiA+DQo+ID4NCj4gPiBPbiBXaW5k b3dzIFF1aWNrc2V0IGlzIGEgc2VwYXJhdGUgYXBwbGljYXRpb24gZnJvbSBidWlsdC1pbiBXaW5k b3dzDQo+IGJhdHRlcnkNCj4gPiBhcHBsZXQuICBJdCBzaG93cyBzaW1pbGFyIHR5cGVzIG9mIGlu Zm9ybWF0aW9uIGFzIGdub21lLXBvd2VyLW1hbmFnZXINCj4gZG9lcywNCj4gPiBidXQgYmVjYXVz ZSBpdCdzIG5vdCBwYXJ0IG9mIHRoZSBPUywgaXQgZG9lc24ndCBnZXQgbm90aWZpY2F0aW9ucyBs aWtlIHRoaXMgc28NCj4gPiBzcGVjaWFsIEJJT1MgaG9va3MgYXJlIGluIHBsYWNlIGZvciBpdCB0 byBrbm93IHdoZW4gdG8gcmUtcmVhZCBiYXR0ZXJ5DQo+ID4gaW5mb3JtYXRpb24uDQo+ID4NCj4g PiBPbiBMaW51eCwgdGhlcmUgYXJlIGFscmVhZHkgaW5mcmFzdHJ1Y3R1cmUgZm9yIGJhdHRlcnkg cmVtb3ZhbCBhbmQgYWRkaW5nDQo+ID4gbm90aWZpY2F0aW9ucyBmcm9tIEFDUEkuICBTZW5kaW5n IHRoaXMgdXAgdG8gdXNlciBzcGFjZSB3b24ndCBiZSB1c2VmdWwuDQo+IA0KPiBFcnJyLiBJIG1l YW4gV01JIGV2ZW50IDB4ZTAwZSB3aGljaCB5b3Ugd3JvdGUgaXMgZW1pdHRlZCB3aGVuIHVzZXIg cHJlc3MNCj4gYmF0dGVyeSBrZXkuIEFuZCBJIHRoaW5rIHRoaXMgZXZlbnQgc2hvdWxkIGJlIHNl bnQgYnkgZGVsbC13bWkuYyBhcw0KPiBLRVlfQkFUVEVSWS4NCj4gDQoNCk5vLCBJIG1lYW4gMHhl MDBlIHNjYW5jb2RlIGlzIGVtaXR0ZWQgd2hlbiB1c2VyIHByZXNzZXMgdGhlIGJhdHRlcnkga2V5 IG9uDQpvbGRlciBsYXB0b3BzLiAgSSdtIG9ubHkgbWVudGlvbmluZyBpdCBiZWNhdXNlIGl0IGhh cHBlbnMgdG8gaGF2ZSB0aGUgc2FtZQ0Kc2NhbmNvZGUgYXMgaXMgcmVjZWl2ZWQgZm9yIFdNSSBm b3IgYW5vdGhlciBwdXJwb3NlIGFuZCBJIHdhbnRlZCB0byBtYWtlIHN1cmUNCml0IHdhcyBjbGVh ciB3aGF0IGJvdGggYXJlIGZvci4gIA0KVGhpcyBidXR0b24gcHJlc3MgaXNuJ3QgZW1pdHRlZCB2 aWEgV01JLCBpdCdzIG92ZXIgc3RhbmRhcmQgc2VyaW8uDQoNClRoZSBldmVudCByZWNlaXZlZCBv dmVyIFdNSSBmb3IgYmF0dGVyeSByZWZyZXNoIHRoYXQgc2hhcmVzIHRoZSBzYW1lIGNvZGUgc2hv dWxkbid0DQpiZSBlbWl0dGVkIGFzIEtFWV9CQVRURVJZIHRvIHRoZSBPUyBpcyBhbGwgSSB3YXMg dHJ5aW5nIHRvIHNheS4NCg0K -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 22 June 2016 14:34:01 Mario_Limonciello@Dell.com wrote: > > -----Original Message----- > > From: Pali Rohár [mailto:pali.rohar@gmail.com] > > Sent: Wednesday, June 22, 2016 9:31 AM > > To: Limonciello, Mario <Mario_Limonciello@Dell.com> > > Cc: gabriele.mzt@gmail.com; mjg59@srcf.ucam.org; dvhart@infradead.org; > > kernel@kempniu.pl; luto@kernel.org; alex.hung@canonical.com; platform- > > driver-x86@vger.kernel.org; linux-kernel@vger.kernel.org > > Subject: Re: [PATCH 3/4] dell-wmi: Add information about other WMI event > > codes > > > > On Wednesday 22 June 2016 14:28:37 Mario_Limonciello@Dell.com wrote: > > > > -----Original Message----- > > > > From: Pali Rohár [mailto:pali.rohar@gmail.com] > > > > Sent: Wednesday, June 22, 2016 9:24 AM > > > > To: Limonciello, Mario <Mario_Limonciello@Dell.com> > > > > Cc: gabriele.mzt@gmail.com; mjg59@srcf.ucam.org; > > dvhart@infradead.org; > > > > kernel@kempniu.pl; luto@kernel.org; alex.hung@canonical.com; > > platform- > > > > driver-x86@vger.kernel.org; linux-kernel@vger.kernel.org > > > > Subject: Re: [PATCH 3/4] dell-wmi: Add information about other WMI > > event > > > > codes > > > > > > > > On Wednesday 22 June 2016 14:21:25 Mario_Limonciello@Dell.com > > wrote: > > > > > > > For Linux I don’t think this is necessary and a NOOP is appropriate. > > > > > > > > > > > > > > There is also a second place that some older laptops had a battery > > > > "hotkey" > > > > > > > that would also emit 0xE00E. This was also picked up by quickset > > and > > > > would > > > > > > > show battery information. > > > > > > > > > > > > > > This shouldn't be blocked by kernel, I'd expect if someone wants to > > > > bind > > > > > > this > > > > > > > to another application from userspace they should be able to. > > > > > > > > > > > > Great! Can I send patch after which 0xe00e will be send to input layer > > as > > > > > > event KEY_BATTERY? > > > > > > > > > > > > > > > > Well that's why I was mentioning this in two places. If it's received from > > > > keyboard > > > > > recoding it as KEY_BATTERY sounds appropriate to me. If it's received > > from > > > > WMI, > > > > > it really shouldn't be set as anything for Linux to do. > > > > > > > > > > I don't think any apps will benefit from the notification to re-read > > battery > > > > > Information today. > > > > > > > > I mean for dell-wmi.c code. > > > > Why it should not be set to anything on Linux? > > > > > > > > > > On Windows Quickset is a separate application from built-in Windows > > battery > > > applet. It shows similar types of information as gnome-power-manager > > does, > > > but because it's not part of the OS, it doesn't get notifications like this so > > > special BIOS hooks are in place for it to know when to re-read battery > > > information. > > > > > > On Linux, there are already infrastructure for battery removal and adding > > > notifications from ACPI. Sending this up to user space won't be useful. > > > > Errr. I mean WMI event 0xe00e which you wrote is emitted when user press > > battery key. And I think this event should be sent by dell-wmi.c as > > KEY_BATTERY. > > > > No, I mean 0xe00e scancode is emitted when user presses the battery key on > older laptops. I'm only mentioning it because it happens to have the same > scancode as is received for WMI for another purpose and I wanted to make sure > it was clear what both are for. > This button press isn't emitted via WMI, it's over standard serio. > > The event received over WMI for battery refresh that shares the same code shouldn't > be emitted as KEY_BATTERY to the OS is all I was trying to say. Ah right, sorry I was confused. WMI e00e is that battery insert/delete event which we should ignore in dell-wmi. So I will prepare patch which disable e00e event in dell-wmi.
On 22/06/2016 16:21, Mario_Limonciello@Dell.com wrote: >> -----Original Message----- >> From: Pali Rohár [mailto:pali.rohar@gmail.com] >> Sent: Wednesday, June 22, 2016 9:13 AM >> To: Limonciello, Mario <Mario_Limonciello@Dell.com> >> Cc: gabriele.mzt@gmail.com; mjg59@srcf.ucam.org; dvhart@infradead.org; >> kernel@kempniu.pl; luto@kernel.org; alex.hung@canonical.com; platform- >> driver-x86@vger.kernel.org; linux-kernel@vger.kernel.org >> Subject: Re: [PATCH 3/4] dell-wmi: Add information about other WMI event >> codes >> >> On Wednesday 22 June 2016 13:40:57 Mario_Limonciello@Dell.com wrote: >>>>> You aren't seeing this on the DSDT of your Latitude right? >>>> >>>> Yes, I do not see it on Latitude. >>> >>> Thanks, the usage of this scan code is specific to consumer BIOSes. >>> >>>> >>>>> Gabriele, >>>>> >>>>> Your machine is from the year before XPS switched over to running the >>>>> Dell business client (eg Latitude, Precision, Optiplex) BIOS. >>>>> >>>>> The EC in that machine does have support for "Battery Health" via that >>>>> scancode. On Windows it's used for relaying battery information to an >>>>> application called Quick Set. >>>> >>>> Do you have some details when it is send to OS? And how to read that >> that >>>> "battery health"? >>> >>> When a battery is removed or inserted this event is supposed to be >> received >>> by quickset over WMI and then Quickset will re-read battery information. >> >> So event is sent only if battery is removed or inserted? >> > > Yeah, that's what my spec says, I haven't tested this on actual system to see. > > I'm guessing what's going on is that during suspend ACPI battery drops > off system and comes back up on resume. > > Maybe Gabriele can comment if any other times were noticed, but in any > case I think it's appropriate for dell-wmi driver when receiving this on WMI > to not do anything. Sending KEY_BATTERY would be wrong behavior. I think I saw the event only after resume, but I don't read my dmesg that often to notice other special cases. Surely it's not related to any hotkey nor actual battery removal. FYI I have a "battery button" and the associated code is 0xe007. I guess most of the laptop nowadays use that code for QuickSet, given that the entry for it was added to dell-wmi.c back in 2009. I would also like to remind that my laptop receives four WMI events with code 0xe00e after resume. If we send an input event for each WMI event with code 0xe00e, I'd get four bogus button keypresses. -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Gabriele Mazzotta [mailto:gabriele.mzt@gmail.com] > Sent: Wednesday, June 22, 2016 9:40 AM > To: Limonciello, Mario <Mario_Limonciello@Dell.com>; pali.rohar@gmail.com > Cc: mjg59@srcf.ucam.org; dvhart@infradead.org; kernel@kempniu.pl; > luto@kernel.org; alex.hung@canonical.com; platform-driver- > x86@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 3/4] dell-wmi: Add information about other WMI event > codes > > On 22/06/2016 16:21, Mario_Limonciello@Dell.com wrote: > >> -----Original Message----- > >> From: Pali Rohár [mailto:pali.rohar@gmail.com] > >> Sent: Wednesday, June 22, 2016 9:13 AM > >> To: Limonciello, Mario <Mario_Limonciello@Dell.com> > >> Cc: gabriele.mzt@gmail.com; mjg59@srcf.ucam.org; > dvhart@infradead.org; > >> kernel@kempniu.pl; luto@kernel.org; alex.hung@canonical.com; > platform- > >> driver-x86@vger.kernel.org; linux-kernel@vger.kernel.org > >> Subject: Re: [PATCH 3/4] dell-wmi: Add information about other WMI > event > >> codes > >> > >> On Wednesday 22 June 2016 13:40:57 Mario_Limonciello@Dell.com > wrote: > >>>>> You aren't seeing this on the DSDT of your Latitude right? > >>>> > >>>> Yes, I do not see it on Latitude. > >>> > >>> Thanks, the usage of this scan code is specific to consumer BIOSes. > >>> > >>>> > >>>>> Gabriele, > >>>>> > >>>>> Your machine is from the year before XPS switched over to running > the > >>>>> Dell business client (eg Latitude, Precision, Optiplex) BIOS. > >>>>> > >>>>> The EC in that machine does have support for "Battery Health" via that > >>>>> scancode. On Windows it's used for relaying battery information to an > >>>>> application called Quick Set. > >>>> > >>>> Do you have some details when it is send to OS? And how to read that > >> that > >>>> "battery health"? > >>> > >>> When a battery is removed or inserted this event is supposed to be > >> received > >>> by quickset over WMI and then Quickset will re-read battery > information. > >> > >> So event is sent only if battery is removed or inserted? > >> > > > > Yeah, that's what my spec says, I haven't tested this on actual system to > see. > > > > I'm guessing what's going on is that during suspend ACPI battery drops > > off system and comes back up on resume. > > > > Maybe Gabriele can comment if any other times were noticed, but in any > > case I think it's appropriate for dell-wmi driver when receiving this on WMI > > to not do anything. Sending KEY_BATTERY would be wrong behavior. > > I think I saw the event only after resume, but I don't read my dmesg > that often to notice other special cases. Surely it's not related to > any hotkey nor actual battery removal. > > FYI I have a "battery button" and the associated code is 0xe007. I > guess most of the laptop nowadays use that code for QuickSet, given > that the entry for it was added to dell-wmi.c back in 2009. Ah yes to make sure that's clear - that battery button is "Battery Health Meter". For QuickSet that function was for just showing a little popup with remaining battery life. For Linux I do think KEY_BATTERY is still appropriate there. > > I would also like to remind that my laptop receives four WMI events > with code 0xe00e after resume. If we send an input event for each > WMI event with code 0xe00e, I'd get four bogus button keypresses. Yep, exactly why dell-wmi should just ignore this code.
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c index 363d927..7aac1dc 100644 --- a/drivers/platform/x86/dell-wmi.c +++ b/drivers/platform/x86/dell-wmi.c @@ -110,6 +110,9 @@ static const struct key_entry dell_wmi_legacy_keymap[] __initconst = { /* BIOS error detected */ { KE_IGNORE, 0xe00d, { KEY_RESERVED } }, + /* Unknown, defined in ACPI DSDT */ + /* { KE_IGNORE, 0xe00e, { KEY_RESERVED } }, */ + /* Wifi Catcher */ { KE_KEY, 0xe011, { KEY_PROG2 } }, @@ -118,21 +121,45 @@ static const struct key_entry dell_wmi_legacy_keymap[] __initconst = { { KE_IGNORE, 0xe020, { KEY_MUTE } }, + /* Unknown, defined in ACPI DSDT */ + /* { KE_IGNORE, 0xe023, { KEY_RESERVED } }, */ + + /* Untested, Dell Instant Launch key on Inspiron 7520 */ + /* { KE_IGNORE, 0xe024, { KEY_RESERVED } }, */ + /* Dell Instant Launch key */ { KE_KEY, 0xe025, { KEY_PROG4 } }, /* Audio panel key */ { KE_IGNORE, 0xe026, { KEY_RESERVED } }, + /* Untested, Multimedia key on Dell Vostro 3560 */ + /* { KE_IGNORE, 0xe028, { KEY_RESERVED } }, */ + /* Dell Instant Launch key */ { KE_KEY, 0xe029, { KEY_PROG4 } }, + /* Untested, Windows Mobility Center button on Inspiron 7520 */ + /* { KE_IGNORE, 0xe02a, { KEY_RESERVED } }, */ + + /* Unknown, defined in ACPI DSDT */ + /* { KE_IGNORE, 0xe02b, { KEY_RESERVED } }, */ + + /* Untested, Dell Audio With Preset Switch button on Inspiron 7520 */ + /* { KE_IGNORE, 0xe02c, { KEY_RESERVED } }, */ + { KE_IGNORE, 0xe02e, { KEY_VOLUMEDOWN } }, { KE_IGNORE, 0xe030, { KEY_VOLUMEUP } }, { KE_IGNORE, 0xe033, { KEY_KBDILLUMUP } }, { KE_IGNORE, 0xe034, { KEY_KBDILLUMDOWN } }, { KE_IGNORE, 0xe03a, { KEY_CAPSLOCK } }, + /* NIC Link is Up */ + { KE_IGNORE, 0xe043, { KEY_RESERVED } }, + + /* NIC Link is Down */ + { KE_IGNORE, 0xe044, { KEY_RESERVED } }, + /* * This entry is very suspicious! * Originally Matthew Garrett created this dell-wmi driver specially for @@ -145,7 +172,12 @@ static const struct key_entry dell_wmi_legacy_keymap[] __initconst = { */ { KE_IGNORE, 0xe045, { KEY_NUMLOCK } }, + /* Scroll lock and also going to tablet mode on portable devices */ { KE_IGNORE, 0xe046, { KEY_SCROLLLOCK } }, + + /* Untested, going from tablet mode on portable devices */ + /* { KE_IGNORE, 0xe047, { KEY_RESERVED } }, */ + { KE_IGNORE, 0xe0f7, { KEY_MUTE } }, { KE_IGNORE, 0xe0f8, { KEY_VOLUMEDOWN } }, { KE_IGNORE, 0xe0f9, { KEY_VOLUMEUP } },
ACPI DSDT tables have defined other WMI codes, but does not contain any description when those codes are emitted. Some other codes can be found in logs on internet. In this patch are all which I saw, but lot of them are not tested properly (e.g. for duplicate events with AT keyboard). Now we have all WMI event codes at one place and in future after proper testing those codes can be correctly enabled or disabled... Signed-off-by: Pali Rohár <pali.rohar@gmail.com> --- drivers/platform/x86/dell-wmi.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+)