You are not logged in.
Great.
On a limb, is a bogus wmi loaded?
lsmod
Also
2. What does your /etc/systemd/logind.conf and what happens if you set it to ignore Power, Reboot Suspend and Hibernate Keys and the LidSwitch?
Offline
lsmod grep wmi
wmi_bmof 12288 0
nvidia_wmi_ec_backlight 12288 0
video 73728 4 nvidia_wmi_ec_backlight,amdgpu,ideapad_laptop,nvidia_modeset
wmi 36864 4 video,nvidia_wmi_ec_backlight,wmi_bmof,ideapad_laptop
backlight 28672 7 video,nvidia_wmi_ec_backlight,drm_display_helper,amdgpu,ideapad_laptop,drm,nvidia_modeset
/etc/systemd/logind.conf
HandlePowerKey=ignore
HandlePowerKeyLongPress=ignore
HandleRebootKey=ignore
HandleRebootKeyLongPress=ignore
HandleSuspendKey=ignore
HandleSuspendKeyLongPress=ignore
HandleHibernateKey=hibernate
HandleHibernateKeyLongPress=ignore
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore
Still, even with these changes when fn + f5/12 is pressed, system crashes. The only way to stop crashes is to set acpi=off in kernel parameters.
Last edited by mishach (2023-12-04 14:20:36)
Offline
Please don't grep, the modules don't all have "wmi" in their name.
Offline
Do I paste all output from lsmod?
https://pastebin.com/fnBDHSqh
Last edited by mishach (2023-12-04 14:52:29)
Offline
Add this to the https://wiki.archlinux.org/title/Kernel_parameters at the bootloader (you'll lose some functionality for pretty much sure, we for now just want to know whether it prevents the powercuts, but this might inhibit your keyboard entirely, so you want this to be transient)
module_blacklist=button,tiny_power_button,ideapad_laptop,nvidia_wmi_ec_backlight
If this works, allow one by one again, start w/ ideapad_laptop and then"button" - "tiny_power_button" makes me nervous…
Offline
It worked! Looks like the problem was with "ideapad_laptop" module. After blacklisting it, fn keys now work without crashing the system.
Many many thanks for your help!
Last edited by mishach (2023-12-04 16:20:16)
Offline
You edited the part where the backlight (still) doesn't work.
Was and in case "how" this sorted out?
Do the keys still produce the expectable input w/o the ideapad_laptop module?
(There're more users on this thread who might benefit from this)
Offline
Yeah, I edited the part about the backlight because I was not sure if it is relevant to this specific problem and I did not want to add to confusion.
In my case, all fn keys produced expected result, except brightness, brightness icon lights (it picks up a fn + f5/6 press signal) but brightness does not change. I suspect that it has to do with something else.
All other functions work.
In an hour or so I will try to boot from live usb with blacklisted module and report results.
Last edited by mishach (2023-12-04 20:18:12)
Offline
The main question is whether and what events those keys generate in "sudo libinput debug-events" (or "sudo evtest"), maybe "xev -event keyboard"
Offline
sudo libinput debug-events
fn + f1
event19 KEYBOARD_KEY +0.000s KEY_MUTE (113) pressed
event19 KEYBOARD_KEY +0.078s KEY_MUTE (113) released
fn + f2
event19 KEYBOARD_KEY +0.398s KEY_VOLUMEDOWN (114) pressed
event19 KEYBOARD_KEY +0.496s KEY_VOLUMEDOWN (114) released
fn + f3
event19 KEYBOARD_KEY +0.710s KEY_VOLUMEUP (115) pressed
event19 KEYBOARD_KEY +0.820s KEY_VOLUMEUP (115) released
fn + f4 microphone mute
fn + f5 brightness icon shows up but brightness does not change
event3 KEYBOARD_KEY +4.300s KEY_BRIGHTNESSDOWN (224) pressed
event3 KEYBOARD_KEY +4.300s KEY_BRIGHTNESSDOWN (224) release
fn + f6 brightness icon shows up but brightness does not change
event3 KEYBOARD_KEY +4.883s KEY_BRIGHTNESSUP (225) pressed
event3 KEYBOARD_KEY +4.883s KEY_BRIGHTNESSUP (225) released
fn + f7
event19 KEYBOARD_KEY +0.000s KEY_LEFTMETA (125) pressed
event19 KEYBOARD_KEY +0.002s *** (-1) pressed
event19 KEYBOARD_KEY +0.065s *** (-1) released
event19 KEYBOARD_KEY +0.067s KEY_LEFTMETA (125) released
fn + f8 airplane safe mode, no event
fn + f9 touch pad, No event but touch pad is turned off/on
fn + f12
event19 KEYBOARD_KEY +14.354s KEY_CALC (140) pressed
event19 KEYBOARD_KEY +14.498s KEY_CALC (140) released
fn + printscr
event19 KEYBOARD_KEY +2.492s KEY_LEFTMETA (125) pressed
event19 KEYBOARD_KEY +2.494s *** (-1) pressed
event19 KEYBOARD_KEY +2.496s *** (-1) pressed
event19 KEYBOARD_KEY +2.578s *** (-1) released
event19 KEYBOARD_KEY +2.580s *** (-1) released
event19 KEYBOARD_KEY +2.582s KEY_LEFTMETA (125) released
fn + home
event19 KEYBOARD_KEY +19.232s KEY_PLAYPAUSE (164) pressed
event19 KEYBOARD_KEY +19.328s KEY_PLAYPAUSE (164) released
fn + end
event19 KEYBOARD_KEY +19.886s KEY_STOPCD (166) pressed
event19 KEYBOARD_KEY +19.992s KEY_STOPCD (166) released
fn + PgUp
event19 KEYBOARD_KEY +22.176s KEY_PREVIOUSSONG (165) pressed
event19 KEYBOARD_KEY +22.242s KEY_PREVIOUSSONG (165) released
fn + PgDn
event19 KEYBOARD_KEY +22.566s KEY_NEXTSONG (163) pressed
event19 KEYBOARD_KEY +22.634s KEY_NEXTSONG (163) released
Last edited by mishach (2023-12-04 21:26:13)
Offline
For fn+f8 check the impact on rfkill, otherwise you'll just have to bind the keys to some action w/ your shortcut daemon.
Resp "fn + f5 brightness icon shows up but brightness does not change" they probably are (your DE displays some icon), but the attempted backllight function is bogus
https://wiki.archlinux.org/title/Backlight
The very good aspect is that the keys still work, because then all that needs to be done is to get rid of the ideapad wmi for legion notebooks.
If more users can confirm that, this probably should be in https://wiki.archlinux.org/title/Laptop … ion_series - eventually a kernel bug (though this likely ends up in blacklisting the module for your product ID/s will break other notebooks… )
Offline
I have a LOQ 16APH8 running Tumbleweed kernel 6.6.3.1 KDE.
A workaround to the brightness being unchangeable is to use the dedicated GPU. I did this by enabling dynamic graphics from the bios and running sudo prime-select offload.
Both the brightness keys and changing the brightness through the GUI work after doing that
Edit: It may not be necessary to keep using the dGPU. I've switch back to the UMA graphics and everything seems to still work.
Disabling ideapad_laptop may prevent TLP from capping battery levels. What I did was boot with ideapad_laptop enabled, let TLP do its thing and then disable both TLP and ideapad_laptop. The battery cap seems to be holding even after multiple reboots.
My laptop would also shut down if it was sleeping and the lid was closed and sometimes if I unplugged the charger. These issues may be specific to this model or my setup.
In any case they were also solved by disabling ideapad_laptop.
Thank you very much seth for figuring this out.
Last edited by fluxion (2023-12-08 16:35:33)
Offline