To sum up, my fn lock led doesn't change once the laptop have been started. If you have the fn lock enabled from the last boot the key have the led ON the rest of the "use time", if you have the fn lock disabled the led is OFF, but it is from the boot, if you change once it's booted the led won't change until you restart or poweroff-power on( the led NOT change but the locked function changes actually) I mean that the lock status change but the LED not. The problem happens for me in Linux only since I have windows and the problem is not present since I installed the needed drivers from lenovo vantage. BTW I am running linux 5.6( But I runned 5.4 and 5.5) but I can " test" the 5.7 ones to see if that kernel version fix the problem. All the other leds works well out of the box In linux. ( microphone, mute, numlock...) but the fn lock.. it's not a big deal but.. it's a bug actually. have Someone this laptop and can confirm that bug?
I can confirm this bug. I am also using Lenovo ThinkPad E595 (Ryzen 7, Vega 10 GPU) and running Linux 5.6.0 on Debian Testing. I updated the BIOS to R11ET36W (1.16, the current version as of writing this) but it doesn't help – just in case that matters.
https://forums.lenovo.com/t5/ThinkPad-11e-Windows-13-E-and-Edge-series-Laptops/led-fn-lock-thinkpad-e595/m-p/5016826?page=1#5057230 In the forum of lenovo
Also in Ubuntu Launchpad and AskUbuntu: * https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1881015 * https://askubuntu.com/questions/1243284/how-do-i-get-the-lenovo-fn-lock-light-to-work-under-ubuntu
Fedora 32, linux 5.7.8, E495. Same issue. LEDs also become unresponsive after hibernation (except Caps).
I've figured out how to fix this on my A485 by probing the ACPI interface. I've found the following two relevant calls: \_SB_.PCI0.LPC0.EC0_.HKEY.GMKS: Get media key status, returns 0x603 if the FnLock mode is enabled, and 0x602 if it's disabled. \_SB_.PCI0.LPC0.EC0_.HKEY.SMKS: Set media key status, sending a 1 will enable FnLock mode, and a 0 will disable it. I'm not sure what the effects of the BIOS are on this, as you can invert the FnLock behavior, but an interesting side-effect of calling GMKS is that it'll update the LED to the current status for you!
Created attachment 295061 [details] Simple Fn Lock LED update patch I've attached a patch that abuses this GMKS behavior to update the LED. I wonder, what would it take to upstream this? Is it fine as-is, or do I somehow need to check for support for this feature, or expose the "media key state" to sysfs like other LEDs are?
(In reply to Esteve Varela Colominas from comment #6) > Created attachment 295061 [details] > Simple Fn Lock LED update patch > > I've attached a patch that abuses this GMKS behavior to update the LED. > I wonder, what would it take to upstream this? Is it fine as-is, or do I > somehow need to check for support for this feature, or expose the "media key > state" to sysfs like other LEDs are? I tested this patch on my Lenovo E595 laptop, and confirm that it fixes the Fn Lock LED issue on this model too. I am using Ubuntu 20.04 with HWE kernel (currently v5.8). I followed the Ubuntu wiki docs on building my own kernel[1], and applied Esteve's patch to the current tip of Ubuntu's Focal Fossa hwe-5.8 git tree (commit d1be521c0ac8877c5cbfbc8d304e0fc90593b7b7). I too, am interested in what happens next. 1: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
I can confirm that I have the same issue on my Lenovo T14 AMD (20UD0010RT model). Arch Linux: 5.10.13-arch1-2
@Rusian can you test the patch above? The more laptops I know are compatible the better. As for submitting upstream, I'll try to propose it on the mailing list soon-ish™
(In reply to Esteve Varela Colominas from comment #9) > As for submitting upstream, I'll try to propose it on the mailing list > soon-ish™ Do you know already which mailing list that would be? (I'm interested in watching how this goes.)
Hello Esteve, I tested your patch in my Thinkpad E495, and it works like a charm. It's great to see this feature working with linux. I also tested toggling from the BIOS the Led dominant behavior, meaning: being ON when the F1-F12 state is enabled, or, being OFF, as well, when the F1-F12 state is enabled. Both work correctly with your patch, regardless one's preference. I tested this by creating a new partition with Xubuntu 20.04, applying the patch to Ubuntu's generic kernel. currently 5.8.0-43.49. I wanted to try this with other partiton I already had with Debian sid, but I'm a total ignorant in these matters and couldn't succeed at compiling without errors. Hopefully it's not to late for kernel 5.10 LTS to get this fix/patch. (I want to thank Paul, for sharing the way he patched his kernel, it was very helpful to me, since I know nothing about compiling or patching anything. The only thing I use my command-line is to upgrade my system, run cmus, dd, etc, heh. Last and only time I compiled something was kernel 3.0, now a long time ago. So thanks again for sharing).
I can confirm this patch also works on my Thinkpad E15 Gen 2 (Intel) on Fedora 34. I really hope this will get upstreamed quickly so I don't have to build a custom kernel all the time.
Unfortunately, I cannot make the patch to work in my laptop. My model is legion 5 15ARH05 and I am using kernel 5.11.2-arch1-1. How can check if I'm applying patch correctly or is this because of different model?
poudelpravin: I'm not sure if this will work with non-thinkpad laptops. What is the problem you're having? Can you check if `lsmod | grep -i thinkpad_acpi` returns anything? This patch is for the thinkpad_acpi module. If it's not loaded, it won't do anything. If the thinkpad_acpi module isn't compatible with your laptop, out of curiosity I'd like you to try the following: - Install https://github.com/nix-community/acpi_call, by running `make && sudo make load` - Try to turn on the LED by running `echo '\_SB_.PCI0.LPC0.EC0_.HKEY.SMKS 1' | sudo tee /proc/acpi/call`. Replace the 1 with a 0 to turn it off. If this is compatible with your laptop, but the thinkpad_acpi module isn't, it might have to be solved in a different module.
Created attachment 295839 [details] attachment-11012-0.html Hi Esteve , lsmod | grep -i thinkpad_acpi does not return anything, so it may be the case as you mentioned. Unfortunately, acpi_call was also unsuccessful to switch the esc key lights. On Wed, Mar 10, 2021 at 6:09 PM <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=207841 > > --- Comment #14 from Esteve Varela Colominas (esteve.varela@gmail.com) --- > poudelpravin: I'm not sure if this will work with non-thinkpad laptops. > What is > the problem you're having? > Can you check if `lsmod | grep -i thinkpad_acpi` returns anything? This > patch > is for the thinkpad_acpi module. If it's not loaded, it won't do anything. > > If the thinkpad_acpi module isn't compatible with your laptop, out of > curiosity > I'd like you to try the following: > - Install https://github.com/nix-community/acpi_call, by running `make && > sudo > make load` > - Try to turn on the LED by running `echo '\_SB_.PCI0.LPC0.EC0_.HKEY.SMKS > 1' | > sudo tee /proc/acpi/call`. Replace the 1 with a 0 to turn it off. > > If this is compatible with your laptop, but the thinkpad_acpi module > isn't, it > might have to be solved in a different module. > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug.
Created attachment 295979 [details] Python script to control whether the keys perform their media function or not I forgot to update this issue thread, but the patch has been accepted: https://www.spinics.net/lists/platform-driver-x86/msg25088.html The patch should land in linux 5.12 if everything goes right. I also wanted to add minor additional info about the acpi calls, since I don't know where else to document them. GMKS fails gracefully with "Error: AE_NOT_FOUND" if it doesn't exist, meaning there's no issue with calling it on older devices. The 2nd bit (mask 0x2) in the GMKS response indicates whether the media key behavior has been inverted in the BIOS, while the 1st bit (mask 0x1) indicates whether FnLock is active. This means that the LED is on if bit2 XOR bit1 is nonzero. So writing a script that leverages acpi_call to control whether the keys perform their media key action or not is simple enough, and is attached to this post.
Seems like it landed in 5.12-rc5 : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/platform/x86/thinkpad_acpi.c?id=v5.12-rc5&id2=v5.12-rc4
Yep! And I'm happy to say it will land in every LTS down to 4.14, as well as 5.11, in a point release. Thank the stable maintainers.
Wait, sorry, I misinterpreted the emails. It's been (auto-)selected for review. Still, it might land there.
Hi Esteve I'm currently using kernel 5.11.11-200.fc33.x86_64 and I am sure your patch landed :) Great work!! this is great, I can't thank you enough for your incredible work.
for me it's fixed now