Dell Vostro V131: special keys not working

[Peter Meiser]

Bug filed, following conversation on IRC at:

  http://irclogs.ubuntu.com/2013/07/28/%23ubuntu-devel.html#t07:45

I own a Dell Vostro V131. This model has 3 special hotkeys (quick launch keys:

  http://www.notebookcheck.net/fileadmin/_migrated/pics/v131tastatur_01.jpg

There are documented in page 1 of the manual:

  ftp://ftp.dell.com/Manuals/all-products/esuprt_laptop/esuprt_vostro_notebook/vostro-v131_Setup%20Guide_en-us.pdf

as being:

  1. "Windows mobility center" (this hotkey generates [Mod]+[x])
  2. "Dell support center"
  3. "Dell instant launch manager"

This was previous raised at:

  http://<email address hidden>/msg03124.html
  http://<email address hidden>/msg04444.html

The "Dell support center" key generates keycode 0xEE, but misses release event. I got it working with an udev "keyboard force release" quirk, see attached patch in the '4444' email.

However, the "Dell instant launch manager" key doesn't generate anything, neither through dell-wmi nor i8042. It's the rightmost button in the right upper corner of the keyboard. The ACPI interrupt-count appears to increment, as seen with:

  http://<email address hidden>/msg03126.html
  watch -n 0,1 cat /proc/interrupts

[Paul Sladen (sladen)]

Whoopie: please can you attach a copy of 'lspnp'.

[Peter Meiser (meiser79)]

BTW, SMO8800 is the freefall sensor.

[Paul Sladen (sladen)]

Page 12 of:

  http://odm.ubuntu.com/uhs/2011/Enabling%20Hotkey%20Features%20on%20Ubuntu.pdf

gives this as the Dell WMI GUID:

  9DBB5994-A997-11DA-B012-B622A1EF5492 dell_wmi

Whoopie: are you seeing "unhandled WMI event" at the same time as the key is pressed?

If this is not obviously the case it worth poking Seth Forshee (Canonical) and Rezwanul Kabir (Dell) to find out if a knock-code or something else is required.

[Peter Meiser (meiser79)]

No, I don't see this "unhandled" event in syslog.

[Peter Meiser (meiser79)]

Please find attached the WMI dump taken with wmidump (https://github.com/iksaif/wmidump).

[Michał Kępień (kempniu)]

I know I'm a bit late to the party, but I'm also affected by this bug on Ubuntu 15.04 (kernel 3.19.0-16) and I would very much like to see it resolved, so I tried to push the investigation forward. I'll refer to hotkeys using the numbers from the original post for simplicity.

I believe these hotkeys are not handled using WMI, because no matter what debug options I turned on for WMI-related modules, nothing appeared in the kernel ring buffer after pressing the hotkeys.

In my case pressing hotkey 3 only incremented the ACPI interrupt counter in /proc/interrupts, so I checked where these interrupts were actually coming from by running:

$ watch -n 0.1 grep enabled /sys/firmware/acpi/interrupts/*

This revealed that when I press hotkey 2 or 3, the counter in /sys/firmware/acpi/interrupts/gpe17 is incremented, which means pressing these hotkeys raises GPE 0x17. This in turn causes the _L17 ACPI method to be called. If we look at the DSDT dump, you'll find that method _L17 only calls method NEVT, where some value is retrieved using another method, ECG1, and acted upon accordingly. Thanks to ACPI method customization at runtime (/sys/kernel/debug/acpi/custom_method), I was able to check the return value of the ECG1 method when the hotkeys are pressed. It turns out it is 0x2000 for hotkey 2 and 0x1000 for hotkey 3.

Unfortunately, this is where I got stuck. If you look at the code of the NEVT method again, you'll find that no code branch is executed for ECG1 values of 0x1000 and 0x2000, so NEVT is essentially a no-op for these. I'm hoping some ACPI expert can point us to the right direction from here. The only thing I thought of was writing a custom handler for GPE 0x17 which would evaluate the value of ECG1 and act accordingly, but judging by the amount of acpi_install_gpe_handler() calls in kernel code, I sense this is not the way to go.

[Darek Stojaczyk (darsto)]

I'm also affected by this bug on Dell Inspiron M5110 (Q15R). This laptop has the same set of special buttons as Vostro V131.

Mentioned ECG1 method was also returning values 0x2000 and 0x1000 for me, but after applying the dell-laptop patch given by Michał Kępień ( http://www.spinics.net/lists/platform-driver-x86/msg07195.html ) it started returning values 0x2800 and 0x1800, so that NEVT method could catch these events by default.

Even though these keys have the same symbols on keyboard and they should work the same on M5110 and V131, mine dell-wmi detects them as events 0xe06e for key #2 and 0xe029 for key #3 (instead of 0xe026 and 0xe025 as on V131). As M5110 doesn't use dell_new_hk_type, I was able to simply map these events in dell-wmi in legacy keymap as unused XF86Launch keys and use them straight away in Xorg. But that's just a workaround for now.

[Peter Meiser (meiser79)]

Could you maybe attach a patch here? I'm not sure what to change in dell-laptop.c based on Michał's email. Thanks!

[Michał Kępień (kempniu)]

@Darek: Thanks for reporting, this proves there are more Dell laptop models than just the Vostro V131 that need a specially crafted SMI in order to receive events via WMI. BTW, hotkey #2 reports WMI event 0xe06e on Vostro V131 (the same one as on your Inspiron), not sure why you mentioned 0xe026.

Could you perhaps create a list for your laptop similar to the one below?

http://www.spinics.net/lists/platform-driver-x86/msg07191.html

The more the merrier: the situation right now is that we know the solution, but it cannot be merged into mainline just yet because we need a method to determine which laptop models need this special SMI and which ones don't. There is also another issue with keycode generation happening on some models and not happening on others:

http://www.spinics.net/lists/platform-driver-x86/msg07226.html

To solve both these problems The Right Way™, we could really use some help from Dell, but unfortunately it doesn't seem to be coming.

[Peter Meiser (meiser79)]

Hmm, I applied the patch to the Ubuntu 3.13 kernel, but it doesn't generate an event on hotkey #3.

Do I have to backport more patches to 3.13 to get it working?

[Darek Stojaczyk (darsto)]

Whoopie, do you mean wmi event?
If not, can you enable pr_debug in dell-wmi and post list of your wmi events? The same one that Michał asked me to create.

[Michał Kępień (kempniu)]

@Whoopie: I'm betting that's because of the KE_IGNORE entry for event 0xe025 in the legacy keymap (the second link from my previous message touches upon that issue). Try replacing that entry with the following one:

{ KE_KEY, 0xe025, { KEY_PROG3 } },

Then recompile the kernel, restart and try again.

[Darek Stojaczyk (darsto)]

While checking wmi event codes I discovered that after pm-suspend and resume wmi events are no longer sent. All wmi buttons stopped working (except for volume buttons).

Reloading dell-laptop fixed it. However, that is unrelated issue, I believe. I will try without Michał's patch to see if that's the case.

[Darek Stojaczyk (darsto)]

The issue I've mentioned above is not related to Michał's patch.

[Michał Kępień (kempniu)]

@Darek: thank you for taking your time to prepare the WMI event listing. I forwarded your findings upstream:

http://www.spinics.net/lists/platform-driver-x86/msg07317.html

[Peter Meiser (meiser79)]

Works perfectly now, thanks a lot!

[Peter Meiser (meiser79)]

Patches submitted by Hans de Goede for kernel 4.2 to make it work. --> http://thread.gmane.org/gmane.linux.drivers.platform.x86.devel/8205

[Peter Meiser (meiser79)]

For upstream kernel, I meant of course.

[Michał Kępień (kempniu)]

These are not the patches you are looking for. *ba dum tsss*

They fix a related issue, which I discovered while trying to get the Instant Launch hotkey working. They are of course an improvement, but those patches alone won't solve the problem for which this bug was created.

The actual fix is in the making. It will take a while more as some refactoring of Dell-related code already present in the kernel has to be done before implementing this fix. Rest assured that I have not forgotten about this bug and will let you guys know once things move forward.

[Michał Kępień (kempniu)]

The relevant patches have been accepted for testing:

    https://www.spinics.net/lists/platform-driver-x86/msg08631.html

If everything goes smoothly, chances are they will land in 4.6. I will report back once that happens.

[Michał Kępień (kempniu)]

Linux 4.6 has been released a few hours ago and it contains the patches that fix this issue.

[Peter Meiser (meiser79)]

For documentation purpose, to get the "Dell support center" key working, you can add the following file and content:

$ cat /etc/udev/hwdb.d/01-dell.hwdb
# Dell v131
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnDell*:pn*V131*:pvr*
 KEYBOARD_KEY_ee=!screenlock

[Kai-Heng Feng (kaihengfeng)]

Whoopie,

Will you make a pull request to systemd?