Hotkeys not working, every key triggers an WMI event with code 0x80

[cytrinox]

Calling acpi_listen and pressing any hotkey button result in the following output:

59142400-C6A3-40 00000080 00000000
59142400-C6A3-40 00000080 00000000
59142400-C6A3-40 00000080 00000000
59142400-C6A3-40 00000080 00000000
59142400-C6A3-40 00000080 00000000
59142400-C6A3-40 00000080 00000000

The code from the module (if removing the wmi_evaluate_method() call):

    if (obj && obj->type == ACPI_TYPE_INTEGER) {
        code = obj->integer.value;

        printk(KERN_INFO "ACPI button code: %x", code);

is called for every hotkey press, but the code value is always 0x80.

[jerin04]

Hello cytrinox,

Pleaese continue the work on this project if you can. Just want to say there are people who do want this issue fixed.

[breznak]

Hi @cytrinox thanks for your work 👍 Any update or ideas? I think the issue prevails in Matebook X Pro (2018)

[aymanbagabas]

Hey! I'm working on a WMI driver that targets Huawei laptops. I have written one that works for the MBXP and now I think it is time to show its successor some love. I need testers to try it on both laptops and hopefully, we can get it to work for the MBX.
Huawei-WMI

[cytrinox]

@aymanbagabas Great news! I can run a test on my MBX this weekend.

[aymanbagabas]

@aymanbagabas Great news! I can run a test on my MBX this weekend.

Whenever you have time, can you try if this module reports any messages to dmesg. Just compile it, insmod it and watch dmesg while you pressing the hotkeys.

huawei_wmi.zip

[cytrinox]

Can I compile it from your git tree?

[aymanbagabas]

No it's different, here I added MBX WMI event and method.

[cytrinox]

@aymanbagabas compiled and loaded. dmesg reports:

[  500.535490] input: Huawei WMI hotkeys as /devices/virtual/input/input17

acpi_listen still reports 0x80 and xev receive no events when a hotkey is pressed. No kernel log message when a hot key is pressed.

[aymanbagabas]

@cytrinox can you please attach a dmesg log? The acpi_call module might come handy for testing acpi methods. By looking at the DSDT table, it seems that \WMI0.WM05 is responsible for executing WMI code.

[cytrinox]

@aymanbagabas the dmesg log contains only the line in my comment above, even if I press any hotkey after the module was loaded.

[aymanbagabas]

@cytrinox can test the following with acpi_call while huawei_wmi is loaded. Observe any kernel messages.

echo '\WMI0.WM05 0 0 1' | sudo tee /proc/acpi/call
echo '\WMI0.WM05 0 0 0x03' | sudo tee /proc/acpi/call
echo '\WMI0.WM05 0 0 0x06' | sudo tee /proc/acpi/call
echo '\_SB.PCI0.LPCB.EC0._Q0A' | sudo tee /proc/acpi/call
echo '\_SB.PCI0.LPCB.EC0._Q0D' | sudo tee /proc/acpi/call
echo '\_SB.PCI0.LPCB.EC0._Q13' | sudo tee /proc/acpi/call

[aymanbagabas]

@cytrinox can you try this one please, I changed the event guid. According to the bmf, this guid reports the value of \WMI0.EVCD which I believe contain the event codes for the hotkeys.
huawei_wmi_mbxv2.zip

[cytrinox]

root@antares:~# modprobe acpi_call
root@antares:~# dmesg -c
root@antares:~# 
root@antares:~# echo '\WMI0.WM05 0 0 1' | sudo tee /proc/acpi/call
\WMI0.WM05 0 0 1
root@antares:~# dmesg
root@antares:~# echo '\WMI0.WM05 0 0 0x03' | sudo tee /proc/acpi/call
\WMI0.WM05 0 0 0x03
root@antares:~# dmesg
root@antares:~# echo '\WMI0.WM05 0 0 0x06' | sudo tee /proc/acpi/call
\WMI0.WM05 0 0 0x06
root@antares:~# dmesg
root@antares:~# echo '\_SB.PCI0.LPCB.EC0._Q0A' | sudo tee /proc/acpi/call
\_SB.PCI0.LPCB.EC0._Q0A
root@antares:~# dmesg
root@antares:~# echo '\_SB.PCI0.LPCB.EC0._Q0D' | sudo tee /proc/acpi/call
\_SB.PCI0.LPCB.EC0._Q0D
root@antares:~# dmesg
root@antares:~# echo '\_SB.PCI0.LPCB.EC0._Q13' | sudo tee /proc/acpi/call
\_SB.PCI0.LPCB.EC0._Q13
root@antares:~# dmesg
root@antares:~# lsmod | grep huawei
huawei_wmi             16384  0
sparse_keymap          16384  1 huawei_wmi
wmi                    28672  2 huawei_wmi,wmi_bmof
root@antares:~# 
root@antares:~# rmmod huawei_wmi
root@antares:~# dmesg
[10474.934068] huawei_wmi: Driver unloaded successfully

[cytrinox]

root@antares:~/huawei_wmi# dmesg -c
[10474.934068] huawei_wmi: Driver unloaded successfully
root@antares:~/huawei_wmi# modprobe huawei_wmi
root@antares:~/huawei_wmi# dmesg -c
[10670.921996] input: Huawei WMI hotkeys as /devices/virtual/input/input19
root@antares:~/huawei_wmi# echo '\WMI0.WM05 0 0 1' | sudo tee /proc/acpi/call
\WMI0.WM05 0 0 1
root@antares:~/huawei_wmi# echo '\WMI0.WM05 0 0 0x03' | sudo tee /proc/acpi/call
\WMI0.WM05 0 0 0x03
root@antares:~/huawei_wmi# echo '\WMI0.WM05 0 0 0x06' | sudo tee /proc/acpi/call
\WMI0.WM05 0 0 0x06
root@antares:~/huawei_wmi# echo '\_SB.PCI0.LPCB.EC0._Q0A' | sudo tee /proc/acpi/call
\_SB.PCI0.LPCB.EC0._Q0A
root@antares:~/huawei_wmi# echo '\_SB.PCI0.LPCB.EC0._Q0D' | sudo tee /proc/acpi/call
\_SB.PCI0.LPCB.EC0._Q0D
root@antares:~/huawei_wmi# echo '\_SB.PCI0.LPCB.EC0._Q13' | sudo tee /proc/acpi/call
\_SB.PCI0.LPCB.EC0._Q13
root@antares:~/huawei_wmi# dmesg
root@antares:~/huawei_wmi# 

Nothing changed with huawei_wmi_mbxv2.zip. acpi_listen still reports 0x80 for each hotkey, dmesg is empty.

[aymanbagabas]

Try dmesg -w on a separate terminal and test the module. Look for any messages that start with 'huawei_wmi' don't use acpi_listen

[cytrinox]

No output on dmesg -w by any of the above commands or hotkeys.

[aymanbagabas]

@cytrinox So does the first one prints kernel messages with the value 0x80 on a hotkey press? If that is the case, then we are on the right track. Try the attached one and watch dmesg for any output.

With MBXP, any hotkey event notifies the WMI device and then the device returns the event value. However, the MBX does not return the event value, instead, it returns the argument which does not make any sense. You can see that in the wake event under WMI0._WED. _QXX are the available events. The ones that start with 0x2XX are the ones we are interested in, it matches the MBXP.
I noticed that the method '\WMI0.WQ00' returns the value of the event so what this does is it gets the value of that method every time we get a value of 0x80.

This issue might be already solved with a bios update or a patched DSDT. Do you have the latest bios? What kernel version you have?

huawei_wmi_mbxv3.zip

[cytrinox]

@aymanbagabas 0x80 is the value which is reported by acpi_listen (description of this issue) when a hot key is pressed.
None of your huawei_wmi modules logs something to the kernel log when a hotkey is pressed.
I've talked to the developer of https://github.com/benatto/pegatron_acpi a few months ago (the wmi implementation for the MBX was probably written by Pegatron). He mention that the WMI subsystem responds to every hotkey press with 0x80, until some initialization routines are called. But I was not able to figure out which routines are required. And I'm unsure if this is really true for the MBX.
I will check what BIOS version is running and if there is a newer version, I'll give it a try.

[cytrinox]

Your latest zip module has changed to output to

[25867.214571] huawei_wmi: Matebook X Pro
[25867.214728] input: Huawei WMI hotkeys as /devices/virtual/input/input20

but still no more logs when a hotkey is pressed.

[cytrinox]

Well, nice one. I've updated the BIOS from 1.12 to 2.06 (only a exe tool is provided to flash the bios).
After that, it boots direct into windows, grub2 boot loader disappears. Maybe some recovery/protection strategy, but I'm pissed. Before I can test again, I've to recover my debian installation...

[aymanbagabas]

@cytrinox I'm sorry to hear that. If you have grub installed on UEFI, you could boot directly to grub from the boot menu, according to this it should be the F12 key. Then reinstall grub or set it as the default using efibootmgr.
Again I'm sorry for the trouble that I put you through.

Your latest zip module has changed to output to

[25867.214571] huawei_wmi: Matebook X Pro
[25867.214728] input: Huawei WMI hotkeys as /devices/virtual/input/input20

but still no more logs when a hotkey is pressed.

That is my bad. I was checking if the module finds any MBXP GUIDs at the beginning and I shouldn't have done that. That is probably why we are not getting any messages back. If 0x80 is being reported by acpi_listen on guid 59142400-C6A3-40fa-BADB-8A2652834100, it should also be reported by the module. You can see that by debugging the DSDT table using acpiexec.

If you still interested, please try this one.
huawei_wmi_mbxv4.zip

[cytrinox]

@aymanbagabas Not your fault, the Huawei software is sometimes crappy and/or windows-only oriented. I've fixed my EFI loaders and can again boot into Debian.

i've tested your latest v4 source and it looks far better now. When pressing a hot key, the kernel log reports:

# dmesg -w
[  216.418221] huawei_wmi: Key is pressed, code: 0x0080
[  216.418343] huawei_wmi: returned value from acpi method \WMI0.WQ00: 642
[  217.406440] huawei_wmi: Key is pressed, code: 0x0080
[  217.406564] huawei_wmi: returned value from acpi method \WMI0.WQ00: 659
[  217.746233] huawei_wmi: Key is pressed, code: 0x0080
[  217.746357] huawei_wmi: returned value from acpi method \WMI0.WQ00: 642
[  218.006274] huawei_wmi: Key is pressed, code: 0x0080
[  218.006397] huawei_wmi: returned value from acpi method \WMI0.WQ00: 644
[  218.402155] huawei_wmi: Key is pressed, code: 0x0080
[  218.402279] huawei_wmi: returned value from acpi method \WMI0.WQ00: 641
[  218.942082] huawei_wmi: Key is pressed, code: 0x0080
[  218.942205] huawei_wmi: returned value from acpi method \WMI0.WQ00: 642
[  219.570377] huawei_wmi: Key is pressed, code: 0x0080
[  219.570500] huawei_wmi: returned value from acpi method \WMI0.WQ00: 660
.....

Good work! What do you need to map the returned values? Here is a list of all keys I've discovered:

641 KEY_BRIGHTNESSDOWN
642 KEY_BRIGHTNESSUP
659 KEY_KBDILLUMTOGGLE
660 KEY_KBDILLUMTOGGLE
661 KEY_KBDILLUMTOGGLE (each toogle state has it's own code on the same button)
644 KEY_MUTE
645 KEY_VOLUMEDOWN
646 KEY_VOLUMEUP
647 KEY_MICMUTE
649 KEY_WLAN
650 KEY_PROG1

[cytrinox]

I've modified the code a little bit, all keys are mapped and reported as XF86.... keys by xev (except MICMUTE). I've mapped the keys by using xbindkeys and it works perfectly.
This is experimental to show that it will work, the code should not be used in production systems.

huawei_cytrinox_v1.zip

[aymanbagabas]

Micmute key needs remapping to F20. I don't know why F20 but it works, take a look at 99-Huawei-MBXP.hwdb
Before using the module, does the keyboard light toggle work? What about the rest?
Also I'm just curious, can you test the following GUID if it reports anything. Change MBX_EVENT_GUID to 39142400-C6A3-40fa-BADB-8A2652834100

[cytrinox]

The keyboard light toogle has worked out of the box, I think it is hardware controlled. So it should be safe to ignore this key.
The other GUID 391.... reports nothing (in dmesg) and hotkeys not working anymore.