Out of the box the mic-mute key does nothing on the Nitro V16 AI (ANV16-42). It does emit a distinct scancode, it just isn't mapped to anything useful:
- plain F8 -> scancode
70041 -> KEY_F8
- Fn+F8 -> scancode
7006a -> KEY_F15
I fixed it with a hwdb rule:
# /etc/udev/hwdb.d/61-keyboard-acer-nitro.hwdb
evdev:input:b0018v1025p1825*
KEYBOARD_KEY_7006a=f20
Note it has to be f20, not micmute. KEY_MICMUTE is 248, which maps to XKB keycode 256 and exceeds the 255 limit inherited from X11, so KWin drops it before it reaches the shortcut system. The kernel hit the same problem and remapped mic-mute to KEY_F20 for the ThinkPad 10 Ultrabook Keyboard — see 617103246cfd, which explains the keycode overflow directly.
After that, binding Fn+F8 to "Mute Microphone" in Plasma works, OSD included.
Suggestion: DAMX could offer to set this up during setup — prompt the user, ask them to press the key, read the scancode from evdev, and write the rule. Something similiar to the Nitro/Predator sense button handeling. Reading the scancode at runtime avoids needing a per-model table, since both the scancode and the VID/PID differ between models.
If anyone else with a Nitro/Predator can confirm the same behaviour, it would be useful to know how widespread it is. Was I the only one facing this issue, or no?
Out of the box the mic-mute key does nothing on the Nitro V16 AI (ANV16-42). It does emit a distinct scancode, it just isn't mapped to anything useful:
70041-> KEY_F87006a-> KEY_F15I fixed it with a hwdb rule:
Note it has to be
f20, notmicmute. KEY_MICMUTE is 248, which maps to XKB keycode 256 and exceeds the 255 limit inherited from X11, so KWin drops it before it reaches the shortcut system. The kernel hit the same problem and remapped mic-mute to KEY_F20 for the ThinkPad 10 Ultrabook Keyboard — see 617103246cfd, which explains the keycode overflow directly.After that, binding Fn+F8 to "Mute Microphone" in Plasma works, OSD included.
Suggestion: DAMX could offer to set this up during setup — prompt the user, ask them to press the key, read the scancode from evdev, and write the rule. Something similiar to the Nitro/Predator sense button handeling. Reading the scancode at runtime avoids needing a per-model table, since both the scancode and the VID/PID differ between models.
If anyone else with a Nitro/Predator can confirm the same behaviour, it would be useful to know how widespread it is. Was I the only one facing this issue, or no?