johnfanv2
[BUG] Snipping Tool (`XF86SelectiveScreenshot`) and Legion (`XF86Favorites`) Fn-keys cease to function
Problem Description
After installing the Legion kernel module and rebooting, the "snipping tool" Fn-key shortcut (on the same key as PrtSc) ceases to function. Previously, it would be picked up (by Hyprland) as XF86SelectiveScreenshot.
This was observed in several places:
- Hyprland binds to
XF86SelectiveScreenshotceased to function wevdid not register any events upon pressing the keywshowkeys, which uses a setuid component to intercept keypresses at a low level, did not register the keypress- Uninstalling the kernel module package (
lenovolegionlinux-dkms-git) and rebooting restored normal operation
The underlying PrtSc key still functions; only its Fn-layer behavior is broken. Also, the broken behavior appears only after reboot, not after simply loading the kernel module.
Model and Debug Info
Installation type: DKMS (via AUR package) Distribution: Arch Linux (fully up-to-date) Model name: Legion 5 15IMH05H CPU model: Intel Core i7-10750H Keyboard backlight: single color with off/medium/bright Light in lid or logo: no Light at IO-Ports at back: no
Output of sudo dmidecode -t system:
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 3.2.0 present.
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: LENOVO
Product Name: 81Y6
Version: Lenovo Legion 5 15IMH05H
Serial Number: [TRIMMED]
UUID: [TRIMMED]
Wake-up Type: Power Switch
SKU Number: LENOVO_MT_81Y6_BU_idea_FM_Legion 5 15IMH05H
Family: Legion 5 15IMH05H
Handle 0x001F, DMI type 12, 5 bytes
System Configuration Options
Option 1: ConfigOptions1
Option 2: ConfigOptions2
Option 3: ConfigOptions3
Handle 0x0023, DMI type 15, 29 bytes
System Event Log
Area Length: 0 bytes
Header Start Offset: 0x0000
Header Length: 8192 bytes
Data Start Offset: 0x2000
Access Method: General-purpose non-volatile data functions
Access Address: 0x0000
Status: Valid, Not Full
Change Token: 0x12345678
Header Format: OEM-specific
Supported Log Type Descriptors: 3
Descriptor 1: POST memory resize
Data Format 1: None
Descriptor 2: POST error
Data Format 2: POST results bitmap
Descriptor 3: Log area reset/cleared
Data Format 3: None
Handle 0x0030, DMI type 32, 11 bytes
System Boot Information
Status: No errors detected
Output of sudo dmidecode -t bios:
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 3.2.0 present.
Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
Vendor: LENOVO
Version: EFCN51WW
Release Date: 05/19/2021
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 11 MB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)
Japanese floppy for Toshiba 1.2 MB is supported (int 13h)
5.25"/360 kB floppy services are supported (int 13h)
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
8042 keyboard services are supported (int 9h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 1.51
Firmware Revision: 1.51
Handle 0x0020, DMI type 13, 22 bytes
BIOS Language Information
Language Description Format: Long
Installable Languages: 8
en|US|iso8859-1,0
fr|FR|iso8859-1,0
zh|TW|unicode,0
ja|JP|unicode,0
it|IT|iso8859-1,0
es|ES|iso8859-1,0
de|DE|iso8859-1,0
pt|PT|iso8859-1,0
Currently Installed Language: en|US|iso8859-1,0
Output of sudo cat /sys/kernel/debug/legion/fancurve:
[Omitted since this isn't a fan-related issue; let me know if you actually need it]
Using evtest, I've traced this to a slightly lower level than just Hyprland. There isn't much new information here, except for the fact that the "Ideapad extra buttons" device is the one affected.
In both cases, `evtest` reports:
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
Input device name: "Ideapad extra buttons"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 1 (KEY_ESC)
Event code 138 (KEY_HELP)
Event code 148 (KEY_PROG1)
Event code 149 (KEY_PROG2)
Event code 186 (KEY_F16)
Event code 190 (KEY_F20)
Event code 192 (KEY_F22)
Event code 193 (KEY_F23)
Event code 202 (KEY_PROG3)
Event code 203 (KEY_PROG4)
Event code 212 (KEY_CAMERA)
Event code 227 (KEY_SWITCHVIDEOMODE)
Event code 240 (KEY_UNKNOWN)
Event code 247 (KEY_RFKILL)
Event code 248 (KEY_MICMUTE)
Event code 364 (KEY_FAVORITES)
Event code 445 (?)
Event code 446 (?)
Event code 562 (?)
Event code 634 (?)
Event type 4 (EV_MSC)
Event code 4 (MSC_SCAN)
Of these keys, four are easily testable:
- Mic mute (actually sends
KEY_F20, notKEY_MICMUTE, but does translate toXF86AudioMicMuteby the time it reaches Hyprland in userspace) - Legion key (the little star-with-inscribed-S icon; sends
KEY_FAVORITES) - Touchpad disable (sends
KEY_F23, but does disable the touchpad) - Snipping tool (sends unknown keycode 634, which translates to
XF86SelectiveScreenshotby the time it reaches Hyprland in userspace)
The mic mute (KEY_F20) and touchpad disable (KEY_F23) events make it through whether the Legion driver is loaded or not.
However, the Legion key (KEY_FAVORITES) and snipping tool (keycode 634) fail to appear if the Legion driver was loaded at boot time.
Hopefully this helps at least a little; please ping me if more testing is needed!
Random observation: the keys that stop working both have keycodes above 256. Is there any chance this driver is using a char or u8 when handling keypresses?
Very interesting! I am currently not at my PC, but you can try it yourself:
Can you give me more details? I guess I might subscribe to too many wmi events that then are not consumed any more by other layers.
You can also compile it from source and temporarily load it without installing (very easy; see README). Then press the keys and look at the output of dmesg. Do you see some logs when you press the special keys?
If you are familiar with, then you could out-comment only these lines and compile and load again:
{ LEGION_WMI_GAMEZONE_GUID, &legion_wmi_context_gamezone },
{ LEGION_WMI_GUID_FAN_EVENT, &legion_wmi_context_a },
{ LEGION_WMI_GUID_FAN2_EVENT, &legion_wmi_context_b },
{ LEGION_WMI_GUID_GAMEZONE_KEY_EVENT, &legion_wmi_context_c },
{ LEGION_WMI_GUID_GAMEZONE_GPU_EVENT, &legion_wmi_context_d },
{ LEGION_WMI_GUID_GAMEZONE_OC_EVENT, &legion_wmi_context_e },
{ LEGION_WMI_GUID_GAMEZONE_TEMP_EVENT, &legion_wmi_context_f },
{ "8FC0DE0C-B4E4-43FD-B0F3-8871711C1294",
&legion_wmi_context_gamezone }, /* Legion 5 */
Then there should be no output in the dmesg log when presssing keys and the keys should work.
Sure, I can test that! Just a quick note, though, the bug doesn't manifest if the module is simply loaded at runtime — it only appears after rebooting with the module configured to load during boot.
Hm, this is interesting. Comparing dmesg logs between loading at boot time versus when the system's already been running for a while, I see exactly one difference. The following line appears during boot-time loading, but not during runtime loading:
[Fri Jan 3 14:56:26 2025] legion_wmi 8FC0DE0C-B4E4-43FD-B0F3-8871711C1294: Register after probing for WMI.
I haven't tested with the WMI device IDs commented out yet, so I'll try commenting just that 8FC0DE0C-… one first.
Yep, that did it. I'm not familiar enough with WMI infrastructure to comment on this, but removing the 8FC0DE0C-B4E4-43FD-B0F3-8871711C1294 GUID fixes the issue.
Very interesting! I am currently not at my PC, but you can try it yourself:
I try on my laptop with the module load and unloaded that keys dosent function, but seems that because ideapad-laptop dosen't support that keys on your model (they are not binded correctly as we can see by evtest output):
Select the device event number [0-19]: 10
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
Input device name: "Ideapad extra buttons"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 1 (KEY_ESC)
Event code 138 (KEY_HELP)
Event code 148 (KEY_PROG1)
Event code 149 (KEY_PROG2)
Event code 186 (KEY_F16)
Event code 190 (KEY_F20)
Event code 192 (KEY_F22)
Event code 193 (KEY_F23)
Event code 202 (KEY_PROG3)
Event code 203 (KEY_PROG4)
Event code 212 (KEY_CAMERA)
Event code 227 (KEY_SWITCHVIDEOMODE)
Event code 240 (KEY_UNKNOWN)
Event code 247 (KEY_RFKILL)
Event code 248 (KEY_MICMUTE)
Event code 364 (KEY_FAVORITES)
Event code 445 (?)
Event code 446 (?)
Event code 562 (?)
Event code 634 (?)
Event type 4 (EV_MSC)
Event code 4 (MSC_SCAN)
Properties:
Testing ... (interrupt to exit)
The last for keys are XF86SelectiveScreenshot, XF86Favorites, KEY_SWITCHVIDEOMODE (Fn+R) and maybe KEY_CAMERA, but the last is only good to notify the system that the camera is off.
If you are familiar with, then you could out-comment only these lines and compile and load again:
{ LEGION_WMI_GAMEZONE_GUID, &legion_wmi_context_gamezone }, { LEGION_WMI_GUID_FAN_EVENT, &legion_wmi_context_a }, { LEGION_WMI_GUID_FAN2_EVENT, &legion_wmi_context_b }, { LEGION_WMI_GUID_GAMEZONE_KEY_EVENT, &legion_wmi_context_c }, { LEGION_WMI_GUID_GAMEZONE_GPU_EVENT, &legion_wmi_context_d }, { LEGION_WMI_GUID_GAMEZONE_OC_EVENT, &legion_wmi_context_e }, { LEGION_WMI_GUID_GAMEZONE_TEMP_EVENT, &legion_wmi_context_f }, { "8FC0DE0C-B4E4-43FD-B0F3-8871711C1294", &legion_wmi_context_gamezone }, /* Legion 5 */Then there should be no output in the dmesg log when presssing keys and the keys should work.
Well on your model dmesg maps the keys this is the dmesg after pressing the key I said above, but all have the same event:
[200082.414212] [T1206382] legion_laptop: Event: legion type: 1; acpi type: 1 (1=integer)
[200088.127112] [T1406707] legion_laptop: Event: legion type: 1; acpi type: 1 (1=integer)
[200093.102772] [T1406707] legion_laptop: Event: legion type: 1; acpi type: 1 (1=integer)
Maybe we can add support for the key in the driver?