Bug 588590

Boot parameters:
kernel /vmlinuz-2.6.33.3-72.fc13.i686.PAE ro root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet radeon.modeset=0

Could you install the pmtools package and provide the output of the acpidump command? Also, please attach the output of ls -R /sys/class/backlight .

(In reply to comment #2)
> Could you install the pmtools package and provide the output of the acpidump
> command? Also, please attach the output of ls -R /sys/class/backlight .    

Yes. I'll do that this evening. Thanks for looking at this!

Created attachment 411421 [details]
acpidump output, as requested

(In reply to comment #2)
> Could you install the pmtools package and provide the output of the acpidump
> command? Also, please attach the output of ls -R /sys/class/backlight .    

[root@localhost ~]# ls -R /sys/class/backlight/
/sys/class/backlight/:
acpi_video0  thinkpad_screen
[root@localhost ~]# cd /sys/class/backlight/
[root@localhost backlight]# ll
total 0
lrwxrwxrwx 1 root root 0 May  4 18:15 acpi_video0 -> ../../devices/virtual/backlight/acpi_video0
lrwxrwxrwx 1 root root 0 May  4 18:15 thinkpad_screen -> ../../devices/virtual/backlight/thinkpad_screen

Hm. Interesting. If you write numeric valies into /sys/class/backlight/acpi_video0/brightness, does the brightness change?

(In reply to comment #6)
> Hm. Interesting. If you write numeric valies into
> /sys/class/backlight/acpi_video0/brightness, does the brightness change?    

I'll try this evening. I don't have physical access to the machine during the day, so I could change the value, but I can't see the result from here!

BTW, here are the current values:

[jim@localhost acpi_video0]$ pwd
/sys/class/backlight/acpi_video0
[jim@localhost acpi_video0]$ ls -l
total 0
-r--r--r-- 1 root root 4096 May  5 09:15 actual_brightness
-rw-r--r-- 1 root root 4096 May  5 09:15 bl_power
-rw-r--r-- 1 root root 4096 May  5 09:15 brightness
lrwxrwxrwx 1 root root    0 May  5 07:15 device -> ../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/LNXVIDEO:00/device:20
-r--r--r-- 1 root root 4096 May  5 07:15 max_brightness
drwxr-xr-x 2 root root    0 May  5 09:15 power
lrwxrwxrwx 1 root root    0 May  5 07:15 subsystem -> ../../../../class/backlight
-rw-r--r-- 1 root root 4096 May  5 07:15 uevent
[jim@localhost acpi_video0]$ cat actual_brightness 
15
[jim@localhost acpi_video0]$ cat bl_power 
0
[jim@localhost acpi_video0]$ cat brightness 
0
[jim@localhost acpi_video0]$ cat max_brightness 
15

BTW, FWIW I am able to use the Gnome Power Manager Brightness Applet to change the brightness. The UI is a bit busted, but can be used (another bug report!)
I had turned the brightness down, with the applet, which might explain the 'brightness' value of zero, but the fact that the 'actual_brightness' is 15 isn't what I would have expected!

I think I see the problem. I'm doing a test kernel build now, can you test it when you get access to the machine again?

Cool. Sure, let me know where I can get it (koji?) and I'll try it tonight.

http://koji.fedoraproject.org/koji/taskinfo?taskID=2164764 once it's finished.

Hi Matthew,

I've installed the kernel but key brightness keys still don't work.

[jim@localhost ~]$ uname -a
Linux localhost.localdomain 2.6.33.3-83.fc13.i686.PAE #1 SMP Wed May 5 14:45:48 UTC 2010 i686 i686 i386 GNU/Linux

I wrote some values to /sys/class/backlight/acpi_video0/brightness and the brightness levels did change as expected (back using the 2.6.33.3-72.fc13.i686.PAE kernel). I also noted that the /sys/class/backlight/acpi_video0/actual_brightness file was automagically updated to match.

How many entries did you have in /sys/class/backlight when using the test kernel?

That I didn't think to check. I'll do so tonight.

Also, please confirm that this is the kernel I should be testing with:
http://koji.fedoraproject.org/koji/getfile?taskID=2164767&name=kernel-PAE-2.6.33.3-83.fc13.i686.rpm

and not this one on the main koji page.
http://kojipkgs.fedoraproject.org/packages/kernel/2.6.33.3/83.fc13/i686/kernel-PAE-2.6.33.3-83.fc13.i686.rpm

They both have the same version number.

(In reply to comment #13)
> How many entries did you have in /sys/class/backlight when using the test
> kernel?    

Looks the same.

[root@localhost backlight]# ls -l
total 0
lrwxrwxrwx 1 root root 0 May  6 18:19 acpi_video0 -> ../../devices/virtual/backlight/acpi_video0
lrwxrwxrwx 1 root root 0 May  6 18:19 thinkpad_screen -> ../../devices/virtual/backlight/thinkpad_screen
[root@localhost backlight]#

Ok, that indicates that there was something wrong with my patch. The problem is that thinkpad-acpi is providing a backlight control when it shouldn't be and the wrong backlight control is being used.

My understanding is that thinkpad-acpi only recently added the X100e to its list of recognized machines, so perhaps that's were the conflict arose. The previously released kernel did not recognize the X100e but the back light controls did actually work!

Anyway, whenever you want me to try another patch, let me know.

I also have a Thinkpad X100e and I am also bitten by this bug. It still persists with kernel-2.6.33.4-95.fc13.x86_64. I found out that blacklisting thinkpad_acpi actually restores the functionality of the brightness controls, the keys are also correctly recognized by KDE. The Mute and Volume keys also work fine. I havent checked the Switch output keys yet.

Does this still happen with the current kernels? I'm afraid I don't have access to an X100e to check.

This problem went away somewhere in the 2.6.34 kernels and did not resurface on Fedora 14. I am currently using the latetest updates-testing kernel in F14.From my point of view this bug is fixed.

Thanks for your work

Ok, thanks - I did some work on this in August but forgot to update the bug. Glad this is fixed, and thanks for the update!