Improve hotkey support

[pelrun]

Thanks to @wl2776 I've now got ACPI dumps from two different machines and I think I can properly implement Omen key detection that will work across the board.

Depending on the key and the model, a hotkey press will generate either an 0x04 (HPWMI_BEZEL_BUTTON) or 0x1D (Omen hotkey) WMI event, or (in my case) just raise a notification with no event data at all. In all cases, HPWMI_HOTKEY_QUERY needs to be called (as is already done for HPWMI_BEZEL_BUTTON) to get the ID of the key pressed.

The Omen key is 0x21A5, although wl2776's machine also appears to generate a 0x21A7 for some other key.

[wl2776]

wl2776's machine also appears to generate a 0x21A7 for some other key.

How did you know that?

[pelrun]

Because there's both Notify (0x1D, 0x21A5) and Notify (0x1D, 0x21A7) commands in the acpi dump you sent me, obviously :)

[wl2776]

I've pulled your commits, there are still issues.

If I run sudo showkey -k and press Omen key, I see

keycode 240 press
keycode 240 release

However, dmesg shows the following

[14285.411928] hp_wmi: Unknown key code - 0x21a5
[14285.980825] hp_wmi: Unknown key code - 0x21a5
[14286.363530] hp_wmi: Unknown key code - 0x21a5
[14439.292467] keyboard: can't emulate rawmode for keycode 240
[14439.292489] keyboard: can't emulate rawmode for keycode 240
[14439.292493] hp_wmi: Unknown key code - 0x21a5
[14439.989045] keyboard: can't emulate rawmode for keycode 240
[14439.989071] keyboard: can't emulate rawmode for keycode 240
[14439.989076] hp_wmi: Unknown key code - 0x21a5
[14440.381164] keyboard: can't emulate rawmode for keycode 240
[14440.381188] keyboard: can't emulate rawmode for keycode 240
[14440.381192] hp_wmi: Unknown key code - 0x21a5
[14440.604816] keyboard: can't emulate rawmode for keycode 240
[14440.604840] keyboard: can't emulate rawmode for keycode 240
[14440.604844] hp_wmi: Unknown key code - 0x21a5
[14440.832498] keyboard: can't emulate rawmode for keycode 240
[14440.832520] keyboard: can't emulate rawmode for keycode 240
[14440.832524] hp_wmi: Unknown key code - 0x21a5
[14444.577270] keyboard: can't emulate rawmode for keycode 240
[14444.577294] keyboard: can't emulate rawmode for keycode 240
[14444.577297] hp_wmi: Unknown key code - 0x21a5
[14444.968475] keyboard: can't emulate rawmode for keycode 240
[14444.968499] keyboard: can't emulate rawmode for keycode 240
[14444.968503] hp_wmi: Unknown key code - 0x21a5
[14445.127734] keyboard: can't emulate rawmode for keycode 240
[14445.127756] keyboard: can't emulate rawmode for keycode 240
[14445.127760] hp_wmi: Unknown key code - 0x21a5
[14485.377110] hp_wmi: Unknown key code - 0x21a5
[14486.752135] hp_wmi: Unknown key code - 0x21a5
[14487.352757] hp_wmi: Unknown key code - 0x21a5
[14487.791967] hp_wmi: Unknown key code - 0x21a5
[14488.217371] hp_wmi: Unknown key code - 0x21a5
[14610.840081] hp_wmi: Unknown key code - 0x21a5

If I try to assign XF86Calculator to this key, I get an error

sudo setkeycodes 21a5 140
setkeycodes: failed to set scancode 21a5 to keycode 140: ioctl KDSETKEYCODE: Invalid argument

[pelrun]

Well, that's probably because the key mappings in that new commit are still commented out...

[wl2776]

Have tried to uncomment line 176 (https://github.com/pelrun/hp-omen-linux-module/blob/master/module/hp-wmi.c#L176) Have got touchpad disabled, and could not enable it back with Fn-F11

[pelrun]

Ok, so somewhere 8 is getting added to the keycode set in the table, and that changes KEY_F23 to send 201 instead of 193. And xmodmap -pke shows keycode 201 is configured as XF86TouchpadOff. :1st_place_medal:

I've figured out that we don't want setkeycodes at all, instead you use xmodmap to set what X11 keysym is triggered by a particular keycode (for instance KEY_CALC is mapped to XF86Calculator, which is actually what launches the thing.) I just need to get the driver correctly sending keycodes that are normally empty in the table.

[pelrun]

Answers to my own questions: the first 8 (well, MIN_KEYCODE) X11 keycodes are reserved, so linux input subsystem keycodes have 8 added when they get into X. F23/F24 literally are set as touchpad off/on in the default mapping, it's not a bug.

I've mapped the hotkeys to F14-F17 now, which by default are XF86Launch5 to XF86Launch8. Just map them to applications using whatever desktop hotkey configuration tool your distro provides (for instance it's under Desktop->Keyboard in the ubuntu settings app.) No need to remap via xmodmap for most cases.

[wl2776]

I've pulled your recent commits, and they didn't work. Omen and Calculator keys now do nothing, and I cannot assign shortcuts in KDE settings.

dmesg doesn't show any error or warning messages about unknown events or keycodes.

Tried sudo showkey -k and sudo showkey -s. Omen doesn't produce any keycodes or scancodes. Calculator produces scancodes 0xe0 0x21 and keycode 140 press.

[wl2776]

I've added some debug messages in hp_wmi_notify. See head commit in my fork (https://github.com/wl2776/hp-omen-linux-module/commit/f61dd85ce59ab917f7e191ace88080b858a056d8). When I press Omen key, I see the following in dmesg:

[63520.563675] input: HP WMI hotkeys as /devices/virtual/input/input55
[63524.359403] hp_wmi: status = 0 value = 128 response = 32 000000008a5a1949
[63524.359409] hp_wmi: event_id = 29
[63524.362640] hp_wmi: key_code = 0x21a5
[63524.362646] hp_wmi: break

And no Omen key message.

So, it looks like sparse_keymap_report_event is not called, because HOTKEY_RELEASE_FLAG is always set for Omen on my machine. It looks like my machine doesn't generate Omen press events, only releases.

[pelrun]

It's just a very silly bug in the last commit - i used && in the release flag check instead of &.

[wl2776]

https://github.com/wl2776/hp-omen-linux-module/commit/45b694b6c2a69a778267cdf964c94e6503c780f3 - Omen works good.

The rest is Calculator When I press it, nothing appears in dmesg.

It produces following with sudo showkey -k

keycode 140 press
keycode 140 press
keycode 140 press
keycode 140 press
keycode 140 press

and following with sudo showkey -s

0xe0 0x21
0xe0 0x21
0xe0 0x21

However, I cannot assign it as a shortcut for calculator launch in KDE. I bring a shortcut assignment dialog, press that key, but nothing happens, KDE doesn't see any keypresses. Although now it sees Omen.

Have also tried to reboot and run xev. When I've pressed Calculator I've got the following output:

...
KeyRelease event, serial 42, synthetic NO, window 0x3e00001,
root 0x29e, subw 0x0, time 52918, (151,-96), root:(151,806),
state 0x14, keycode 148 (keysym 0x1008ff1d, XF86Calculator), same_screen YES,
XLookupString gives 0 bytes: 
XFilterEvent returns: False

KeyPress event, serial 42, synthetic NO, window 0x3e00001,
root 0x29e, subw 0x0, time 52918, (151,-96), root:(151,806),
state 0x14, keycode 148 (keysym 0x1008ff1d, XF86Calculator), same_screen YES,
XLookupString gives 0 bytes: 
XmbLookupString gives 0 bytes: 
XFilterEvent returns: False

KeyRelease event, serial 42, synthetic NO, window 0x3e00001,
root 0x29e, subw 0x0, time 52958, (151,-96), root:(151,806),
state 0x14, keycode 148 (keysym 0x1008ff1d, XF86Calculator), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

KeyPress event, serial 42, synthetic NO, window 0x3e00001,
root 0x29e, subw 0x0, time 52958, (151,-96), root:(151,806),
state 0x14, keycode 148 (keysym 0x1008ff1d, XF86Calculator), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 42, synthetic NO, window 0x3e00001,
root 0x29e, subw 0x0, time 52999, (151,-96), root:(151,806),
state 0x14, keycode 148 (keysym 0x1008ff1d, XF86Calculator), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
...

I pressed Ctrl-C to stop it. There were no reaction on this hotkey on second run of xev.

[pelrun]

That calculator key is a normal media key, and is clearly being correctly mapped to XF86Calculator. That puts the issue squarely in KDE's court. A quick google brought up https://askubuntu.com/q/1199160 which might help (I have neither KDE or a kb with a calculator button which makes it hard for me to check...)

[I-dont-need-name]

So the calculator button will not be fixed? It's not a KDE problem, this happens in every DE i tried.

[pelrun]

That key doesn't get processed by this module at all - it uses the same mechanism as the ordinary keys. So there's nothing I can do here to fix it.

[I-dont-need-name]

That key doesn't get processed by this module at all - it uses the same mechanism as the ordinary keys. So there's nothing I can do here to fix it.

Thank you for your reply. Indeed, it looks like the key is being processed along with all other keys on the keyboard. Could you please tell where I should report this bug then?

[wl2776]

That key doesn't get processed by this module at all - it uses the same mechanism as the ordinary keys. So there's nothing I can do here to fix it.

Thank you for your reply. Indeed, it looks like the key is being processed along with all other keys on the keyboard. Could you please tell where I should report this bug then?

I've filed the bug report: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1929345

[I-dont-need-name]

I've filed the bug report: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1929345

to fix this you need to add this to /usr/lib/udev/hwdb.d/60-keyboard.hwdb

# HP Omen 15
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP:pnOMENLaptop15*:pvr*
 KEYBOARD_KEY_a1=!calc

I submitted the fix to systemd already so it should be working ootb soon.

[wl2776]

to fix this you need to add this to /usr/lib/udev/hwdb.d/60-keyboard-hwdb

# HP Omen 15
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP:pnOMENLaptop15*:pvr*
 KEYBOARD_KEY_a1=!calc

I submitted the fix to systemd already so it should be working ootb soon.

Could you give me a link with description of these lines? man udev and man systemd-hwdb don't say much.

[I-dont-need-name]

Could you give me a link with description of these lines? man udev and man systemd-hwdb don't say much.

https://github.com/systemd/systemd/blob/main/hwdb.d/60-keyboard.hwdb

An '!' as the first character of the key identifier string will add the scan code to the AT keyboard's list of scan codes where the driver will synthesize a release event and not expect it to be generated by the hardware.

[wl2776]

Could you give me a link with description of these lines? man udev and man systemd-hwdb don't say much.

https://github.com/systemd/systemd/blob/main/hwdb.d/60-keyboard.hwdb

Ah, yes, I see. Everything seems to be written in the beginning of that file.

One more question. The keyboard of this notebook has a small LED on F5/Mute key, that is lit on Windows, when the sound is muted with Fn+F5.

Is it possible to illuminate it on Linux?

[I-dont-need-name]

One more question. The keyboard of this notebook has a small LED on F5/Mute key, that is lit on Windows, when the sound is muted with Fn+F5.

Lol, I didn't even notice it was there. It seems like this led should be controlled by sound card (or its driver). I have found a similar problem being solved here but it doesn't work for our laptop. There is a link to kernel documentation page which mentions fixes for other HP mute leds, so maybe it is possible to create something similar for Omen 15. I have no idea how, though, might investigate later.

[I-dont-need-name]

Is it possible to illuminate it on Linux?

Well... technically, it is... I found this article and with the help of it I could find out which codec widgets are responsible for lightning this LED up. You can light it up with this command: sudo hda-verb /dev/snd/hwC1D0 0x20 0x500 0x0B && sudo hda-verb /dev/snd/hwC1D0 0x20 0x400 0x7778 and turn it off with sudo hda-verb /dev/snd/hwC1D0 0x20 0x500 0x0B && sudo hda-verb /dev/snd/hwC1D0 0x20 0x400 0x7774 Now, the problem is that I couldn't find any way to do this automatically when mute button is pressed. It looks like there needs to be an hdaudio driver patch written to do this (I submitted a kernel bug report already but nobody seems to care). The file with similar patches is this. Unfortunately, I don't have any experince with C or kernel hacking and I can't do much here. Perhaps, @pelrun could help, but he seems to have an older model without such a problem.

[I-dont-need-name]

Is it possible to illuminate it on Linux?

Good news, my bug report was noticed and a patch was made. Right now to make it work you can build a kernel with a patch from here. Or just wait until the patch gets to mainline and your distro ships it (that might take a long time).

[wl2776]

Is it possible to illuminate it on Linux?

Good news, my bug report was noticed and a patch was made. Right now to make it work you can build a kernel with a patch from here. Or just wait until the patch gets to mainline and your distro ships it (that might take a long time).

Yes, I've seen these messages. I'm watchin that. I'll try it when I'll have spare time.

[xddxdd]

Just a note that the hwdb fix from @I-dont-need-name also applies to HP Omen 17 laptops, but with a different matching entry:

evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP:pnOMENbyHPLaptop17*:pvr*
 KEYBOARD_KEY_a1=!calc

[wl2776]

Then, it might be possible to make it shorter and more universal

evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP:pnOMEN*:pvr*
 KEYBOARD_KEY_a1=!calc

[xddxdd]

Yeah, I guess it's the common behavior for HP OMEN laptops. Just sent a PR to systemd, will see how that goes.