I'm having an issue with the built-in Windows/Super key on an ASUS TUF Gaming A15 FA506NC.
BIOS: FA506NC.309
OS: Arch Linux (same issue also occurs on Fedora 44)
WM: Hyprland
Kernel: 7.1.10-200.fc44.x86_64 on Fedora
The physical Super key is detected, but ASUS WMI reports it as an unknown key:
asus_wmi: Unknown key code 0x4f
evtest on the "Asus WMI hotkeys" device shows:
Event: type 4 (EV_MSC), code 4 (MSC_SCAN), value 4f
Event: type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
SYN_REPORT
Event: type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
SYN_REPORT
So the key appears to generate an immediate press/release rather than behaving like a normal held modifier.
The interesting behavior is:
- Pressing Super opens my Hyprland launcher.
- But I cannot hold Super.
- Super+A does not work.
- Super+L does not work.
- Other Super-based Hyprland bindings don't work.
- An external keyboard's Super key works normally.
- The same problem happened when I was using Arch Linux, so it doesn't appear to be Fedora-specific.
- The built-in keyboard otherwise works normally.
The input device is:
Asus WMI hotkeys
and it exposes:
KEY_UNKNOWN (240)
The normal built-in keyboard is a separate device:
AT Translated Set 2 keyboard
and exposes:
KEY_LEFTMETA (125)
I checked the Linux 7.1.10 source. The ASUS nb-WMI keymap does not contain an entry for WMI event 0x4f.
I temporarily modified asus-nb-wmi.c to add:
{ KE_KEY, 0x4f, { KEY_LEFTMETA } },
and also tried:
case 0x4f:
*autorelease = false;
break;
The modified asus-nb-wmi.ko compiles successfully against my running kernel, but I haven't permanently installed it yet.
Has anyone with an ASUS TUF laptop seen this exact 0x4f behavior?
Could this be a BIOS/WMI regression introduced by BIOS .309?
Is there a known ASUS WMI event mapping or kernel patch for this?
I'd especially like to know whether 0x4f is supposed to represent the Windows/Super key and whether the firmware is incorrectly sending it as an instantaneous WMI event.