+++ This bug was initially created as a clone of Bug #1498161 +++ Description of problem: Sony Vaio SVE17137CXB keyboard LED backlight not working. Version-Release number of selected component (if applicable): Fedora 26 How reproducible: Always. Steps to Reproduce: 1. Install Fedora 26 or run live from usb pen drive. 2. No keyboard backlight. 3. No kbd_backlight device parameter at kernel sys directory tree. Actual results: No keyboard lights. Expected results: Keyboard lights light up on key press and turn off 20 secs after the last key press. Additional info: Initial thread: https://ask.fedoraproject.org/en/question/111566/sony-vaio-sve17137cxb-keyboard-leds-not-working I was using RHEL 7 a month ago and the keyboard lights worked perfectly. sys directory listing: # ll /sys/devices/platform/sony-laptop/ total 0 -r--r--r--. 1 root root 4096 Sep 25 21:07 battery_care_health -rw-r--r--. 1 root root 4096 Sep 25 21:07 battery_care_limiter lrwxrwxrwx. 1 root root 0 Sep 25 20:57 driver -> ../../../bus/platform/drivers/sony-laptop -rw-r--r--. 1 root root 4096 Sep 25 21:07 driver_override -rw-r--r--. 1 root root 4096 Sep 25 21:07 fan_forced -r--r--r--. 1 root root 4096 Sep 25 21:07 fanspeed -rw-r--r--. 1 root root 4096 Sep 25 21:07 lid_resume_S5 -r--r--r--. 1 root root 4096 Sep 25 21:07 modalias -r--r--r--. 1 root root 4096 Sep 25 21:07 panel_id drwxr-xr-x. 2 root root 0 Sep 25 21:07 power lrwxrwxrwx. 1 root root 0 Sep 25 20:57 subsystem -> ../../../bus/platform -rw-r--r--. 1 root root 4096 Sep 25 21:07 thermal_control -r--r--r--. 1 root root 4096 Sep 25 21:07 thermal_profiles -rw-r--r--. 1 root root 4096 Sep 25 21:07 touchpad -rw-r--r--. 1 root root 4096 Sep 25 21:07 uevent -rw-r--r--. 1 root root 4096 Sep 25 21:07 usb_charge **I will gladly provide any information needed** --- Additional comment from Fernando Farias on 2017-12-11 19:13:34 EST --- Additional information: - I am using UEFI boot and THE KEYBOARD LIGHTS WORK FINE ON GRUB !!! however once booting out of grub, the light goes out 20 sec and never light up. - I upgraded to Fedora kernel 4.13.13-300 using dnf, still not working. - I have tried out the sony-laptop kernel module params "compat" "kbd_backlight" "kbd_backlight_timeout" with several different values and still not working. --- Additional comment from Hans de Goede on 2017-12-12 02:38:14 EST --- Can you try creating a: /etc/modprobe.d/local.conf file with the following there: blacklist sony-laptop And see if that at least keeps the backlight on ? --- Additional comment from Fernando Farias on 2017-12-12 20:22:57 EST --- Thanks Hans, indeed it works, the keyboard backlight stays on for 20 secs after the last keypress and goes off, then back on at the first keypress. However, there is no linux device to control the keyboard backlight: # ls /sys/class/backlight/ radeon_bl0 Aside from that everything looks like it is working fine, except for the keyboard. The numpad is chaotic, every numpad number key causes undefined behaviors on the KDE, even the scroll-lock led goes on and off at random. Not sure if this is an improvement, for now I will keep the sony-laptop module available, just in case. But at least we have more information. Thanks again Hans. --- Additional comment from Hans de Goede on 2017-12-13 03:42:11 EST --- (In reply to Fernando Farias from comment #3) > Thanks Hans, indeed it works, the keyboard backlight stays on for 20 secs > after the last keypress and goes off, then back on at the first keypress.> > However, there is no linux device to control the keyboard backlight: > > # ls /sys/class/backlight/ > radeon_bl0 Ok, re-reading your original post, you said things do work in RHEL-7, does that include getting a /sys/class/backlight entry for the keyboard? (note I would expect a /sys/class/leds entry as that the standard kbd backlight userspace ABI) > Aside from that everything looks like it is working fine, except for the > keyboard. > The numpad is chaotic, every numpad number key causes undefined behaviors on > the KDE, even the scroll-lock led goes on and off at random. Does this chaotic numpad thing only happen when blacklisting sony-laptop, or is this an independent problem? If this happens because of the blacklisting of sony-laptop then the best fix is probably to modify the sony-laptop driver to not touch the keyboard-backlight stuff on your model, although if sonay-laptop does work in RHEL-7, we should probably figure out what changed. --- Additional comment from Fernando Farias on 2017-12-13 19:27:13 EST --- > Does this chaotic numpad thing only happen when blacklisting sony-laptop, or is this an independent problem? Only happens when blacklisting sony-laptop. > if sonay-laptop does work in RHEL-7, we should probably figure out what changed. I downloaded RHEL 7.4 and put it in a USB stick. Then tried to shrink Fedora27 and install RHEL 7.4 in a new partition. The stick was broken and left me half way into the installation... Some things I manage to test: - RHEL 7.4: keyboard backlight works fine. it has the normal 20secs delay. - RHEL 7.4: numpad works fine. - RHEL 7.4: Scroll lock actually works. (the hotkey is fn+numlk and never saw it working on Fedora) I will get a working usb stick and full install RHEL 7.4 so I can test the /sys/class things, and then report back my findings. --- Additional comment from Zed on 2018-02-12 10:47:01 EST --- #!/bin/sh echo 1 > /sys/class/leds/input14::scrolllock/brightness check for the correct inputXX number ;) --- Additional comment from Zed on 2018-02-12 10:52:48 EST --- backlight.sh #### #!/bin/sh echo 1 > /sys/class/leds/input14::scrolllock/brightness check for the correct inputXX number ;) --- Additional comment from Zed on 2018-02-12 14:47:35 EST --- #!/bin/sh foo=$(find /sys/class/leds "$(cd ..; pwd)" -name "*scrolllock") bar="$foo/brightness" echo 1 > $bar more tricky script automated ;) enjoy //linux never fail// --- Additional comment from Fernando Farias on 2018-02-13 14:58:12 EST --- (In reply to Zed from comment #8) > #!/bin/sh > foo=$(find /sys/class/leds "$(cd ..; pwd)" -name "*scrolllock") > bar="$foo/brightness" > echo 1 > $bar > > > > more tricky script automated ;) enjoy //linux never fail// Hi Zed, as stated in the description, the problem is with the keyboard BACKLIGHT LEDS, which are NOT being DETECTED BY KERNEL. The capslock, numlock, and scrolllock leds works just fine. Here is the listing just as an added info: [root@evaio leds]# ll total 0 lrwxrwxrwx 1 root root 0 Feb 13 16:46 ath9k-phy0 -> ../../devices/pci0000:00/0000:00:1c.0/0000:02:00.0/leds/ath9k-phy0 lrwxrwxrwx 1 root root 0 Feb 13 16:46 input2::capslock -> ../../devices/platform/i8042/serio0/input/input2/input2::capslock lrwxrwxrwx 1 root root 0 Feb 13 16:46 input2::numlock -> ../../devices/platform/i8042/serio0/input/input2/input2::numlock lrwxrwxrwx 1 root root 0 Feb 13 16:46 input2::scrolllock -> ../../devices/platform/i8042/serio0/input/input2/input2::scrolllock Thanks anyways. --- Additional comment from Fedora End Of Life on 2018-05-03 04:28:45 EDT --- This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. --- Additional comment from Fedora End Of Life on 2018-05-29 08:44:49 EDT --- Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs. Fedora 28 has now been rebased to 4.17.7-200.fc28. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
Bug still exists in 4.17.7-200.fc28.x86 . Nothing has changed, keyboard backlights still not working on Fedora. They do work fine while in GRUB menu (same behavior since Fedora 26). I can provide any needed information if requested.
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs. Fedora 28 has now been rebased to 4.18.10-300.fc28. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29. If you experience different issues, please open a new bug report for those.
Bug still exists in 4.18.10-200.fc28.x86_64. I will update to Fedora 29 once the final release is out, but have little hope for this bug to ever be fixed without a specific patch. Can anyone point me out in the right direction ( Sony related kernel diff between RHEL and Fedora ) ? I can try to fix it myself.
Upgraded to 4.18.11-200.fc28.x86_64. Still not working, BUT !!! After suspending to RAM, it works perfectly, the keyboard backlight leds light up on key press and stays there for 20 seconds after the last key press ( normal expected behavior ). Status: still not working. Workaroud: suspend to ram, resume, be happy.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs. Fedora 28 has now been rebased to 4.20.5-100.fc28. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs. Fedora 29 has now been rebased to 5.2.9-100.fc29. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 30, and are still experiencing this issue, please change the version to Fedora 30. If you experience different issues, please open a new bug report for those.
Upgraded to Fedora 30 latest. Status: still not working. Workaround: suspend to ram, resume, be happy.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs. Fedora 30 has now been rebased to 5.5.7-100.fc30. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31. If you experience different issues, please open a new bug report for those.
Upgraded to Fedora 31, the problem is still there, exactly the same way, no change at all after 5 Fedoras and 2 years. As always I'll be happy to provide any an all information required to fix this issue. Please respond.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Tested on Fedora 33 kernel: 5.8.17-300.fc33.x86_64 The issue is still there. The problem hasn't change in any way, not worse, not better. The workaround is still functional.
Fernando, if I remember correctly (and from reading back) the workaround is to blacklist the sony-laptop module, correct ? And the downside of the workaround is that it makes the numpad keys misbehave, correct ? And things did work properly with the 7.4 kernel, right ? ### Anyways I wrote a long comment (below the next ### divider) for you to run some tests to help narrow down the cause of the breakage, but while writing that I ended up looking at possible culprits and I have a better idea for debugging this, so for now please ignore the large comment below the next ###, I'm leaving it there so that I don't need to type it again when it turns out to be necessary after all. I'm going to prepare a F33 test kernel with some debugging added (and a possible fix) and I will add another comment when that kernel is ready for testing. ### ignore everything below this line for now ### So assuming I got all 3 of those right, then the question is how much time are you willing to invest in getting this fixed ? Koji, the Fedora build-system offers all the kernels ever build for Fedora going a long way back: https://koji.fedoraproject.org/koji/packageinfo?packageID=8 So you could try installing old kernels (maybe starting with the Fedora equivalent of the base kernel version for RHEL-7) and then install a newer version (you could try jumping say 5 versions at the time in the beginning) and then narrow the breakage down to say works in 4.0.0 is broken in 4.1.0 note, please ignore the z part of the version number, so do not try say 4.0.1 4.0.2, etc. only x.y.0 versions otherwise there are way too much kernels to test and I don't need that level of detail for now. Note the really old kernels will likely not work with a recent Fedora, so you will need to install an old Fedora (or RHEL/centos 7) for testing this. An older Fedora / CentOS should work fine with newer kernels. Although in this case the kernel version range spanned is somewhat big (3.10 for RHEL7 going up to 4.13 in Fedora 26 where you first noticed the breakage), still everything up to the 4.13 kernel should work fine in a Fedora which works with the 3.10 kernel. FWIW: here are some generic instructions for installing kernels directly from koji: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt The goal of this exercise is to try and narrow down what kernel change broke the kbd-backlight. So lets say you pin it down to breaking between 3.14 and 3.15, then I will go to: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/platform/x86/sony-laptop.c?h=v3.14 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/platform/x86/sony-laptop.c?h=v3.15 And look at the changes there and that will give me a place to start debugging this.
Ok I've started a build of a test kernel with kbd-backlight probing disabled in the sony-laptop driver and replaced with some debugging prints: https://koji.fedoraproject.org/koji/taskinfo?taskID=55045408 Note this is still building atm, this takes a couple of hours (*). Once it is done building please follow these instructions for installing it: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt And then boot into the new kernel and: 1. Let me know if it fixed things 2. Please run: "dmesg | grep "sony-laptop" and copy and paste the output here. *) Recently I have seen some kernel test builds hang, so if it takes say more then 4 hours to finish please let me know
And the build just completed successfully (quicker then I expected), please test.
Hey Hans, thanks for taking a look at this. I'll test it as soon as I understand the instructions. To clarify the status on Fedora 33 is: - booting up I see the keyboard backlights working, I can navigate GRUB and the lights go out in 30 seconds inactivity, and then come back when I press a key. - after GRUB, when the kernel takes control, the backlights go out in 30 seconds and never come back. - if I suspend to ram, and wake up the system, then the lights work normally, lighting up with a key press and going out in 30 seconds. So the infamous workaround is: boot up, login, suspend to ram, wake up, use the system. Let me know what commands can be useful to see what is it that comes alive after the suspend to ram, if that helps.
It WORKS !!! ._.)/\(._. Here is the output of dmesg: # dmesg | grep sony-laptop [ 7.753363] sony_laptop: sony-laptop found kbd backlight handle 0x0153, ignoring I tried the numpad and it's working, and also tried whatever came to mind :D and it works perfect. *** Note the timeout was never 30s, it's always 15s, which is very comfy for me, so no need to change it. THANK YOU VERY MUCH HANS !!!
(In reply to Fernando Farias from comment #17) > It WORKS !!! ._.)/\(._. > THANK YOU VERY MUCH HANS !!! I'm happy to hear that it works. But don't celebrate too early. As I sorta suspected already while looking at the history of sony-laptop.c this means that the problem is caused by this commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/sony-laptop.c?id=800f20170dcf1dd7d89ce45cb9be930b359936d1 My test kernels just complete disables any and all kbd-backlight handling in the sony-laptop code which is a much to big hammer, so this cannot be merged as a fix in the official kernels. But together with the debug dmesg info you provided I'm pretty sure that the commit which I pointed out above is the culprit. I'm not sure how to fix this yet though... Can you please do the following: 1. Run as *normal* user: grep . /sys/class/dmi/id/* 2> /dev/null And copy and paste the out here. 2. Run: sudo dnf install acpica-tools sudo acpidump -o acpidump.sony-SVE17137CXB And attach the generated acpidump.sony-SVE17137CXB file here. Once I have that info I will try to come up with a proper fix for this.
Created attachment 1728226 [details] acpi dump
sorry for the delay, here is the grep out: $ grep . /sys/class/dmi/id/* 2> /dev/null /sys/class/dmi/id/bios_date:11/13/2012 /sys/class/dmi/id/bios_release:1.60 /sys/class/dmi/id/bios_vendor:Insyde Corp. /sys/class/dmi/id/bios_version:R0160D6 /sys/class/dmi/id/board_asset_tag:N/A /sys/class/dmi/id/board_name:VAIO /sys/class/dmi/id/board_vendor:Sony Corporation /sys/class/dmi/id/board_version:N/A /sys/class/dmi/id/chassis_asset_tag:N/A /sys/class/dmi/id/chassis_type:10 /sys/class/dmi/id/chassis_vendor:Sony Corporation /sys/class/dmi/id/chassis_version:N/A /sys/class/dmi/id/ec_firmware_release:1.60 /sys/class/dmi/id/modalias:dmi:bvnInsydeCorp.:bvrR0160D6:bd11/13/2012:br1.60:efr1.60:svnSonyCorporation:pnSVE17137CXB:pvrC904ZPKJ:rvnSonyCorporation:rnVAIO:rvrN/A:cvnSonyCorporation:ct10:cvrN/A: /sys/class/dmi/id/product_family:VAIO /sys/class/dmi/id/product_name:SVE17137CXB /sys/class/dmi/id/product_sku:54528226 /sys/class/dmi/id/product_version:C904ZPKJ /sys/class/dmi/id/sys_vendor:Sony Corporation /sys/class/dmi/id/uevent:MODALIAS=dmi:bvnInsydeCorp.:bvrR0160D6:bd11/13/2012:br1.60:efr1.60:svnSonyCorporation:pnSVE17137CXB:pvrC904ZPKJ:rvnSonyCorporation:rnVAIO:rvrN/A:cvnSonyCorporation:ct10:cvrN/A: and the acpi dump is attached. the beast is in range, let's finish it :D
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Updating issue, it keeps happening in 35.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Hi Fernando, I see that I completely dropped the ball on this and that I have never looked at the issue after you provided the requested ACPI dump, my apologies. Since you just changed the version field from 35 to 37, I assume that you still have the laptop and are still running Fedora on it? I've just added this near the top of my work TODO list and I plan to take a look at this coming Monday or Tuesday. Regards, Hans
Created attachment 1931135 [details] [PATCH] platform/x86: sony-laptop: Don't turn off 0x153 keyboard backlight during probe Once again sorry for completely dropping the ball in this many many moons ago. I have taken a detailed look now and I believe I know what is going on. The support for keyboard-backlight handle 0x0153 which your laptop has and which was added between the working and non working kernels, re-uses existing code to "probe" if the backlight is actually there. But on the 0x0153 kbd backlight case this probe actually comes down to writing 0 to the backlight control setting, which turns the backlight off... This patch should fix things by skipping the probe for the 0x0153 kbd backlight case.
I have started a test Fedora kernel build with the patch which should fix this added: https://koji.fedoraproject.org/koji/taskinfo?taskID=95099058 Note this is still building atm. It should be finished in a couple of hours. Once this is finished, please install this kernel and see if it fixes things. Here are some generic instructions for installing a kernel directly from koji (Fedora's buildsystem): https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt After booting this kernel your kbd backlight should function normally, without needing the suspend/resume workaround. Extra test: ----------- You should now also have a: /sys/bus/platform/devices/sony-laptop/kbd_backlight File, as root you can echo "0", "1" or "2" to this file, e.g.: echo 0 > /sys/bus/platform/devices/sony-laptop/kbd_backlight 0 should turn off the backlight, 1 should put it in auto mode (the 15 second timeout) and 2 should permanently turn it on. It would be great if you can also test echo-ing to this file.
Note the kernel build is done now. If you don't have time to test right away please at least download the rpms from: https://koji.fedoraproject.org/koji/taskinfo?taskID=95099058 koji will remove the rpms for test builds after about a week to replace the diskspace.
Hey Hans, thanks for taking care of it ! I've downloaded the files, but I'm traveling during Christmas, so I'll test this around February. I'll let you know as soon as I get back to my laptop. Kind Regards !
(In reply to Fernando Farias from comment #28) > Hey Hans, thanks for taking care of it ! > I've downloaded the files, but I'm traveling during Christmas, so I'll test > this around February. Ok, enjoy your holidays!
Fernando, did you get a chance to test the test kernel build which I did ? Note recent kernel versions >= 6.1.7 also contain the fix, so you can also just do a "sudo dnf update 'kernel*'" and then reboot to test this.
YESSSS !!! IT'S WORKING !!! I updated the kernel using dnf, it went up to 6.1.18 and I can confirm the bug is fixed. THANK YOU SO MUCH HANS !!!
You are welcome, lets close this then.