Description of problem: The fn keys on my Vaio laptop work fine using the stable 2.6.29.x kernels, but they no longer work using 2.6.30.x kernels from updates-testing. Also, it is no longer possible to set the brightness through the gnome brightness applet with 2.6.30.x kernels. Version-Release number of selected component (if applicable): kernel-2.6.30.5-32.fc11 How reproducible: Steps to Reproduce: 1. Install 2.6.30.x kernel from updates-testing 2. Reboot 3. Try to set brightness, using the fn keys and/or the gnome brightness applet Actual results: It is no longer possible to set the lcd brightness with 2.6.30.x kernels Expected results: Ability to adjust panel brightness Additional info: Sony Vaio VGN-BZ12XN
Let me clarify this report further: On 2.6.29.x kernels, I am able to set the panel brightness either using the Fn keys and/or the brightness panel app in Gnome. Using 2.6.30.x kernels, I am no longer able to set the brightness at all. It defaults to 100% which is far too bright for normal use.
I don't even know what information to ask for here.
Fedora 11 is currently the only distribution where I can set the lcd brightness levels using the Fn keys on this laptop. With most up-to-date distro's I can only use the gnome brightness applet to do this. I suspect a new version of the sony_laptop module was backported to the default F11 kernel(s) but omitted in the new 2.6.30.x kernels. Can somebody confirm this ?
The backported code is present in 2.6.30. Does hitting the brightness keys cause any messages to appear in dmesg?
Using: 2.6.30.5-32.fc11.x86_64 - no messages appear in /var/log/messages when pressing the brightness keys - the brightness applet no longer works: "cannot get laptop panel brightness"
Using: kernel-2.6.30.5-43.fc11.x86_64 - When removing the sony_laptop module and reloading it: "sony-laptop: brightness ignored, must be controlled by ACPI video driver"
The ACPI video driver is refusing to bind - there's a patch submitted upstream that I'll integrate.
Is there a kernel on Koji yet that I can use to test ?
Can you be more specific on which patch needs to be applied ? Thank you
Any update on this bug report please ?
Kernel 2.6.31-11.38 has solved this issue for Ubuntu users: http://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_2.6.31-11.38/changelog
Can somebody confirm these upstream patches are not in integrated yet: [ Upstream Kernel Changes ] * ACPI video: ignore buggy _BQC * ACPI video: work-around BIOS AML bug in _BQC - LP: #428910
http://bugzilla.kernel.org/attachment.cgi?id=22675
Created attachment 367604 [details] _BQC on some laptops returns an uninitialized value when it's invoked for the first time.
Not sure whether this was already mentioned, but on Rawhide, running 2.6.31.5-122 with mesa-dri-drivers-experimental on a Sony Vaio VGN-FW21E w/ Radeon HD3470: $ find /proc/acpi/video/ /proc/acpi/video/ Brightness keys do not work, brightness applet does not work and on battery, every time I bring my laptop back up from suspend, the screen is a bit darker. On Karmic, running 2.6.31-14 w/ Radeon Catalyst driver from Karmic repo: $ find /proc/acpi/video/ /proc/acpi/video/ /proc/acpi/video/VGA /proc/acpi/video/VGA/DFP1 /proc/acpi/video/VGA/DFP1/EDID /proc/acpi/video/VGA/DFP1/brightness /proc/acpi/video/VGA/DFP1/state /proc/acpi/video/VGA/DFP1/info /proc/acpi/video/VGA/TV /proc/acpi/video/VGA/TV/EDID /proc/acpi/video/VGA/TV/brightness /proc/acpi/video/VGA/TV/state /proc/acpi/video/VGA/TV/info /proc/acpi/video/VGA/CRT /proc/acpi/video/VGA/CRT/EDID /proc/acpi/video/VGA/CRT/brightness /proc/acpi/video/VGA/CRT/state /proc/acpi/video/VGA/CRT/info /proc/acpi/video/VGA/LCD /proc/acpi/video/VGA/LCD/EDID /proc/acpi/video/VGA/LCD/brightness /proc/acpi/video/VGA/LCD/state /proc/acpi/video/VGA/LCD/info /proc/acpi/video/VGA/DOS /proc/acpi/video/VGA/POST /proc/acpi/video/VGA/POST_info /proc/acpi/video/VGA/ROM /proc/acpi/video/VGA/info Brightness keys and applet work fine on Karmic. Have not tried suspend. Does the video driver installed have any influence on populating /proc/acpi/video? Is there any word on how to get this fixed?
@Maxim: Can you please remove the sony_laptop module and insert it again ? Do you see any related messages in /var/log/messages ?
(In reply to comment #16) > @Maxim: > > Can you please remove the sony_laptop module and insert it again ? Do you see > any related messages in /var/log/messages ? There's a few messages, but no errors: Nov 10 16:24:40 zen kernel: sony-laptop: Sony Notebook Control Driver v0.6. Nov 10 16:24:40 zen kernel: input: Sony Vaio Keys as /devices/LNXSYSTM:00/device:00/PNP0A08:00/device:04/SNY5001:00/input/input12 Nov 10 16:24:40 zen kernel: input: Sony Vaio Jogdial as /devices/virtual/input/input13
I saw this message on my laptop, but I can't remember if I saw it in /var/log/messages or when executing dmesg: "sony-laptop: brightness ignored, must be controlled by ACPI video driver"
Only thing I have extra after waking from suspend is: Nov 10 19:23:06 zen kernel: ACPI: Waking up from system sleep state S3 Nov 10 19:23:07 zen kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out Nov 10 19:23:07 zen kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
Any chance of this patch being applied any time soon in F12 ? This is a show stopper for me, looking at 100% brightness all the time hurts my eyes and drains the battery quickly.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I've tested again using the F12 RC4 live cd. After removing the sony-laptop module and inserting the module again I see the following dmesg output: sony-laptop: Sony Notebook Control Driver v0.6. input: Sony Vaio Keys as /devices/LNXSYSTM:00/device:00/PNP0A08:00/device:0a/SNY5001:00/input/input14 input: Sony Vaio Jogdial as /devices/virtual/input/input15 sony-laptop: brightness ignored, must be controlled by ACPI video driver
Has anyone specifically been assigned this fix? It's been outstanding since 2.6.30.x kernel and at the moment it makes my Fedora useless... my batteries drain in no time at 100% brightness and turns my laptop into a power cable bound desktop in all practicality. Thanks.
I've also searched far and wide for a solution but don't have enough experience to report my findings properly or to correct the problem. I'm using a Sony VGN-Z710DD laptop I had the same issue when I updated my kernal (exactly as described above) and still have the issue in a fresh install of fedora 12. Is there a way to watch this thread as more comment/solutions are added?
It's kinda frustrating to see no one is taking action, while the patch for this bug is attached to this report, together with external links to Ubuntu launchpad and the kernel bug tracker. The Ubuntu kernel was patched almost two months ago which solves this issue.
I'm sure I'm being melodramatic but I put all my votes on this fix which is hopefully the best way to influence it's priority. :) Thanks!
Same problem for Sony Vaio VGN-TT92JS :(
Same problem for Sony Vaio VGN-CS360A :(
I don't think this bug is related to the Intel 4500MHD or Sony hardware mentioned in the title of this bugreport, by the way. The Launchpad bug mentioned a somewhere above doesn't mention it: it has lspci output attached from a Asus machine with a Geforce. I personally have an ATi card in my laptop and I suffer the same issue. I don't have problems with Karmic either, so the patch in the bug clearly fixes this (or some other patch, of course). Can we make the title a bit more hardware agnostic? The problem is about laptop BIOS'es, not graphics chips.
(In reply to comment #29) > Can we make the title a bit more hardware agnostic? The problem is about laptop > BIOS'es, not graphics chips. Good point, done.
(In reply to comment #7) > The ACPI video driver is refusing to bind - there's a patch submitted upstream > that I'll integrate. Matthew, when would you be able to do this ? Please give us an update on this bug report.
This seems to be a workaround: after adding 'nomodeset' to the kernel boot parameters the brightness control keys function again. I tested this using the Desktop Edition live cd. Obviously, kms no longer works when activating this option. Can somebody else confirm this ?
Model: Sony Vaio VGN-TT92JS The brightness control works again after 'nomodeset' is added to the kernel boot parameters. But the Gnome desktop becomes a little bit unresponsive. DVD eject button no longer works.
Adding 'nomodeset' to kernel boot parameters does not fix for me. Sony Vaio VGN-FW190, kernel 2.6.31.5-127. Laptop unusable until this gets patched.
Hi, i use F12 and when i put "nomodeset acpi_backlight=vendor" into grug.conf the FN KEY WORK !!! BUT : im not able to use compiz video acceleration anymore, COMPIZ CRASH !!! any idea or workaround ? my laptop is a acer aspire 7735z ps : some fedora forum user said that re-installing gnome fix compiz side effect... anyone has tried ? thanks Domenic
*** Bug 540022 has been marked as a duplicate of this bug. ***
I'm seeing this problem on my Lenovo laptop (Intel 965GM chipset), and the "nomodeset acpi_backlight=vendor" suggestion does NOT work. Adding "nomodeset" does bring back the brightness slider in the Power Management dialog, but that slider is totally non-functional. The panel brightness applet also has no effect, and upon mouseover displays, "Cannot get laptop brightness." Looks like I've got to go back to F-11 till I see a fix for this.
(In reply to comment #37) > Looks like I've got to go back to F-11 till I see a fix for this. F11 worked fine for me too, until the 2.6.3x kernels came along. Ubuntu works fine, so that's the distribution I'm using until this gets fixed. But since I filed this bug back in August, I'm not really hopeful they will patch the kernel any time soon. Although the patch is publicly available and all relevant links are attached to this bug report.
(In reply to comment #37) OK, looks like I've got something weird going on that might be different from what others are seeing. If I boot from the F-12 Live CD (kernel-2.6.31.5-127), then Power Management and the Brightness applet control the backlight just fine. If I boot from the installed F-12 and choose that kernel the brightness controls do not work. So, I restored my system from an incremental backup taken just before the Dec 3 updates and found that the brightness controls worked fine with both the 2.6.31.5-127 and 2.6.31.6-145 kernels. I then re-applied all of the subsequent updates, and the brightness controls still work. Right now I'm guessing there might have been some anomaly related to prelink. In the broken system image, "rpm -Va" generates a lot of "dependency changed since last prelink" reports. Since my latest updates and a forced full prelink, those reports are gone and my brightness controls are working.
(In reply to comment #39) Fixing the prelink errors from "rpm -Va" with "prelink -ua" (undoing all prelink changes) doesn't make brightness controls on my computer work. My computer might be experiencing something different, though, as it is a PPC. (PowerBook6,4. Fedora 12. 2.6.31.6-162. NV34 graphics.) I've never had working backlight control in Fedora, but then F12 is my only successful install on this machine. If I can provide useful information, or test-run any fixes, please let me know.
(In reply to comment #39) > (In reply to comment #37) > OK, looks like I've got something weird going on that might be different from > what others are seeing. If I boot from the F-12 Live CD (kernel-2.6.31.5-127), > then Power Management and the Brightness applet control the backlight just > fine. If I boot from the installed F-12 and choose that kernel the brightness > controls do not work. I notice this as well on my laptop as well. Which has a Intel 965GM chipset graphics card. If I use the F12 LiveCD then my Fn keys for brightness work but after installing it they do not work.
Sigh...4 months later and still no response to this bug report whatsoever. Come on guys, the patch is attached to this bug report: http://bugzilla.kernel.org/attachment.cgi?id=22675 Anyway, happy New Year everybody !
Fedora 12 will be switching to 2.6.32, which have both * ACPI video: ignore buggy _BQC * ACPI video: work-around BIOS AML bug in _BQC patches applied. You can try it using one of current koji kernel build: http://koji.fedoraproject.org/koji/packageinfo?packageID=8
Thanks, I found another workaround which was mentioned as a comment of another bug report: Adding acpi_backlight=vendor to menu.list and rebooting fixed the issue for me. Running kernel 2.6.31.9-174.fc12.x86_64. No need to use the 'nomodeset' option.
Model: Sony Vaio VGN-TT92JS Appending acpi_backlight=vendor to kernel boot parameter works! Eric, thank you for your finding!! : )
Nice to see similar story during last few years... (I mean bug #363261). Have x60s which works not fine with F12 instead of previously installed F10. Ok, now will going to test 2.6.32.7-40.fc12...
Andy, Have you tested the 2.6.32.7-40 kernel ? What are the results ?
Thanks for reminder. Yeah, I rebooted laptop with that kernel. Still the same bug. Actually if I remember correctly it occurs after last update with DeviceKit-power, selinux-*, xorg-x11-evdev-whatever... I tried to revert DeviceKit power, and evdev, update kernel with no success. So, I suspect the selinux-* packages. I also tried to do echo <NUMBER> > /proc/.../brightness, it works fine. so, the problem in my opinion is in delivery of evens from keyboard to stuff responsible to do job.
Same problem here on Acer Aspire 5515.. Brightness keys do not do anything.. boot options suggested in this bug report do not help and dmesg reports: ACPI Error: Current brightness invalid 20090521 video-538 In addition, when closing/re-opening the lid, or sometimes on boot, the LCD is set so dim I can barely read it.
*** Bug 541257 has been marked as a duplicate of this bug. ***
*** Bug 558345 has been marked as a duplicate of this bug. ***
same problem with 2.6.33 kernels (ati radeon 3450) in an MSI-x310 laptop. Fn keys for brightness and and brightness applet no longer work. ( echo -n xx > /proc/acpi/video/VGA/LCD/brightness works fine). 2.6.31 kernels in F12 used to work fine
Hi, Just to comment a "seems to be related bug". Since last March 6th Fedora 12 update (which included kernel-PAE-devel-2.6.32.9-67.fc12.i686 update). I am not able to use my laptop brightness keys (a Samsung X-20). I have not had any problems with previous kernel-PAE-2.6.31.12-174.2.22.fc12.i686. If I boot with kernel-PAE-2.6.32.9-67.fc12.i686 or the new kernel-PAE-2.6.32.9-70.fc12.i686 and in the gdm screen I try to correct brightness with laptop functional keys I get a blue full screen, without any possibility to return to "normal" GDM screen. Even I am unable to switch to the console (same full blue screen). FYI: Booting with 'nomodeset' is a workaround to the problem on my laptop.
16/03/2010 fedora 13 updates solved the brightness problem for me. (although not sure which update solves the problem - but definitely not a kernel update)
Hi, Kostas, could you please tell which updates you indroduced to the system when the brightness problem got solved? Perhaps I can match your "solution" updates with mines from the day the updates made the problem start for me.
(In reply to comment #55) > Hi, > > Kostas, could you please tell which updates you indroduced to the system when > the brightness problem got solved? > > Perhaps I can match your "solution" updates with mines from the day the updates > made the problem start for me. Hmmmm.. these are the updates from last 2 days. My suspicion are on the selinux but I am not really sure Updated 15/03 cyrus-sasl-2.1.23.9.fc13.i686 cyrus-sasl-gssapi-2.1.23.9.fc13.i686 cyrus-sasl-lib-2.1.23.9.fc13.i686 cyrus-sasl-md5-2.1.23.9.fc13.i686 cyrus-sasl-plain-2.1.23.9.fc13.i686 dhclient-12:4.1.1.7.fc13.i686 gnome-media-2.29.91.1.fc13.i686 gnome-media-libs-2.29.91.1.fc13.i686 ibus-anthy-1.2.0.20100312.1.1.fc13.i686 initscripts-9.07.1.fc13.i686 libssh2-1.2.2.5.fc13.i686 phonon-4.3.80.5.fc13.i686 phonon-backend-xine-4.3.80.5.fc13.i686 selinux-policy-3.7.11.1.fc13.noarch selinux-policy-targeted-3.7.11.1.fc13.noarch shotwell-0.4.3.1.fc13.i686 gnome-vfs2-2.24.2.3.fc13.i686 abrt-1.0.8.3.fc13.i686 abrt-addon-ccpp-1.0.8.3.fc13.i686 abrt-addon-kerneloops-1.0.8.3.fc13.i686 abrt-addon-python-1.0.8.3.fc13.i686 abrt-desktop-1.0.8.3.fc13.i686 abrt-gui-1.0.8.3.fc13.i686 abrt-libs-1.0.8.3.fc13.i686 abrt-plugin-bugzilla-1.0.8.3.fc13.i686 abrt-plugin-logger-1.0.8.3.fc13.i686 abrt-plugin-runapp-1.0.8.3.fc13.i686 at-3.1.12.4.fc13.i686 gnome-power-manager-2.29.91.3.fc13.i686 java-1.6.0-openjdk-1:1.6.0.0.35.b17.fc13.i686 java-1.6.0-openjdk-plugin-1:1.6.0.0.35.b17.fc13.i686 nspr-4.8.4.2.fc13.i686 obexd-0.22.1.fc13.i686 postgresql-libs-8.4.3.1.fc13.i686 qt-1:4.6.2.7.fc13.i686 qt-sqlite-1:4.6.2.7.fc13.i686 qt-x11-1:4.6.2.7.fc13.i686 Updated 16/03 abrt-1.0.8.1.fc13.i686 abrt-addon-ccpp-1.0.8.1.fc13.i686 abrt-addon-kerneloops-1.0.8.1.fc13.i686 abrt-addon-python-1.0.8.1.fc13.i686 abrt-desktop-1.0.8.1.fc13.i686 abrt-gui-1.0.8.1.fc13.i686 abrt-libs-1.0.8.1.fc13.i686 abrt-plugin-bugzilla-1.0.8.1.fc13.i686 abrt-plugin-logger-1.0.8.1.fc13.i686 abrt-plugin-runapp-1.0.8.1.fc13.i686 at-3.1.12.3.fc13.i686 gnome-power-manager-2.29.91.2.fc13.i686 java-1.6.0-openjdk-1:1.6.0.0.34.b17.fc13.i686 java-1.6.0-openjdk-plugin-1:1.6.0.0.34.b17.fc13.i686 nspr-4.8.4.1.1.fc13.i686 obexd-0.21.2.fc13.i686 postgresql-libs-8.4.2.6.fc13.i686 qt-1:4.6.2.3.fc13.i686 qt-sqlite-1:4.6.2.3.fc13.i686 qt-x11-1:4.6.2.3.fc13.i686
Hi Kostas, I think the bug I'm suffering is unrelated to yours, since I am completely sure all my problems began with the March 6th updates (listed below), which don't match with yours. And I think it may be related with the 2.6.32 kernels and the new "ACPI video" patches. ---------- Updates March 6th, 2010 ------------------ bodhi-client-0.7.0-2.fc12.noarch fetchmail-6.3.11-4.fc12.i686 file-5.03-13.fc12.i686 file-libs-5.03-13.fc12.i686 foomatic-4.0.4-1.fc12.i686 GConf2-2.28.0-4.fc12.1.i686 GConf2-devel-2.28.0-4.fc12.1.i686 GConf2-gtk-2.28.0-4.fc12.1.i686 info-4.13a-9.fc12.i686 kernel-firmware-2.6.32.9-67.fc12.noarch kernel-headers-2.6.32.9-67.fc12.i686 kernel-PAE-2.6.32.9-67.fc12.i686 kernel-PAE-devel-2.6.32.9-67.fc12.i686 mercurial-1.4.3-2.fc12.i686 mlocate-0.22.2-2.fc12.i686 mock-1.0.5-1.fc12.noarch pulseaudio-0.9.21-5.fc12.i686 pulseaudio-esound-compat-0.9.21-5.fc12.i686 pulseaudio-gdm-hooks-0.9.21-5.fc12.i686 pulseaudio-libs-0.9.21-5.fc12.i686 pulseaudio-libs-devel-0.9.21-5.fc12.i686 pulseaudio-libs-glib2-0.9.21-5.fc12.i686 pulseaudio-libs-zeroconf-0.9.21-5.fc12.i686 pulseaudio-module-bluetooth-0.9.21-5.fc12.i686 pulseaudio-module-gconf-0.9.21-5.fc12.i686 pulseaudio-module-jack-0.9.21-5.fc12.i686 pulseaudio-module-lirc-0.9.21-5.fc12.i686 pulseaudio-module-x11-0.9.21-5.fc12.i686 pulseaudio-module-zeroconf-0.9.21-5.fc12.i686 pulseaudio-utils-0.9.21-5.fc12.i686 python-magic-5.03-13.fc12.i686 sos-1.9-1.fc12.noarch sudo-1.7.2p5-1.fc12.i686 texinfo-4.13a-9.fc12.i686 texinfo-tex-4.13a-9.fc12.i686 usermode-1.104-1.fc12.i686 usermode-gtk-1.104-1.fc12.i686 xorg-x11-drv-ati-6.13.0-0.21.20100219gite68d3a389.fc12.i686 xorg-x11-server-devel-1.7.5-5.fc12.i686 xorg-x11-server-Xdmx-1.7.5-5.fc12.i686 xorg-x11-server-Xnest-1.7.5-5.fc12.i686 xorg-x11-server-Xorg-1.7.5-5.fc12.i686 xorg-x11-server-Xvfb-1.7.5-5.fc12.i686
Hi, I've just updated to the latest kernel and my brightness buttons are now operational. :o) M.
That's .. 2.6.32.9-70.fc12.x86_64 #1 SMP Wed Mar 3 04:40:41 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux M.
(In reply to comment #59) > 2.6.32.9-70.fc12.x86_64 #1 SMP Wed Mar 3 04:40:41 UTC 2010 thinkpad x60s still doesn't work with it (i686).
Hi, Yesterday I reverted the changes made in 2.6.32 to drivers/acpi/video.c regarding ACPI brightness to check If they where the responsible for the weird brightness behaviour I have. The result is no luck. Those changes are not (directly) related to the bug I'm suffering. I have also discovered another symptom. The thing is that when I push the button that disables the touchpad on my laptop I get the same behaviour as when I press the brightness buttons (full blue screen). The common factor of both buttons is an overlay window that the bios of my laptop shows on the upper left corner. Since with nomodeset everything goes perfectly I suppose that my problem has to do with a "misunderstanding" between KMS and i915 display driver. Searching a little I have found this announcement: http://intellinuxgraphics.org/2009Q4.html All user-modesetting code has now been removed (in 2.6.32) from xf86-video-intel 2.10.0 and in the announcement it is said that: "Video overlay support with KMS. This currently requires Linux 2.6.33, but a backport to 2.6.32 is available". This seems to be my problem. When I have time (next week I suppose) I will apply the changes to 2.6.32 and check If it fix the problem in my laptop. At this point I'm not sure if the root cause of my laptop's bug is the same as the one of this bugzilla ticket. Should I stay here or open a new ticket for this problem?
I'm using a full updated Fedora 12 on Lenovo B450 laptop. When I try to use either the "nomodset" or "acpi_backlight=vendor" kernel parameter, the brightness control function key simply does not work. On a normal bootup, the brightness key does create an acpi event and the slider moves up or down, but there is no change in the actual screen brightness. Dmesg reports: atkbd.c: Unknown key released (translated set 2, code 0x88 on isa0060/serio0). atkbd.c: Use 'setkeycodes e008 <keycode>' to make it known. I tried the beta release of Fedora 13 as well, but to no hope. Also the recent version of Ubuntu (Lucid Lynx) has the same problem.
I'm using a full updated Fedora 12 on Lenovo B450 laptop. When I try to use either the "nomodset" or "acpi_backlight=vendor" kernel parameter, the brightness control function key simply does not work. On a normal bootup, the brightness key does create an acpi event and the slider moves up or down, but there is no change in the actual screen brightness. Dmesg reports: atkbd.c: Unknown key released (translated set 2, code 0x88 on isa0060/serio0). atkbd.c: Use 'setkeycodes e008 <keycode>' to make it known. The change in brightness values is reflected well in /sys/class/backlight/acpi_video0/brightness, but no change in seen in the physical screen on the laptop lcd. I tried the beta release of Fedora 13 as well, but to no hope. Also the recent version of Ubuntu (Lucid Lynx) has the same problem.
Fresh install 64-bit Fedora 13 on Asus UL20A, same problem on me. keep up-to-date but still the same problem.
Solution has been found by the Ubuntu people (Mustafa Kamal) Could it please be implemented in Fedora? Please read https://bugs.launchpad.net/ubuntu/+source/linux/+bug/568611 and http://kernel.ubuntu.com/~kamal/i915bri~3e/
Could anyone check first if Kamal's fixes made it upstream?
They didn't. Matthew Garrett is working on more palatable fixes, which we will then pull into Fedora when they start heading upstream. regards, Kyle
I have the same problem in F13. I hope the solution will be available soon.
A few observations which may help locating the bug. Computer Dell N3010 BIOS level A02 , Fedora 13 2.6.33.8-149.fc13.x86_64 gnome-power-manager-2.30.1-1.fc13.x86_64 , almost all the rest of gnome 2.30.0-1 Brightness control buttons are Fn+F4 (-) and F5 (+) 1-While in BIOS menu, buttons work and brightness follows. Setting remains until boot starts after GRUB menu. 2-While in GRUB the setting can also be changed with the buttons. 3-As soon as the Fedora splash screen appears, brightness jumps to maximum, before login, and remains so at all times except when controlled by screensaver NONE OF THE TESTS BELOW DOES ANYTHING TO THE ILLUMINATION OF THE SCREEN 4-Files used in this report: root@localhost]/sys/class/backlight/dell_backlight>ls actual_brightness brightness max_brightness subsystem bl_power device power uevent max_brightness 15 at all times actual_brightness identical to brightness echo -n X | tee brightness sets it to X (in 0-15) as should be except NO EFFECT 5-Operate Fn+F4: starting from brightness 6 shows bar at right place, brightness read from file in item 4- becomes 5. Repeating moves bar close to max and brightness reports 14. Thus, a hit takes it down by 1 unit as should be. 6-Operate Fn=F5: starting from 6, increases by 1 reflected in file, next hit fills the bar, not reflected in the file on first attempt, file jumps to 15 on next attempt. 7-System->Preferences->Power Management: I slide to 24%. File backlight shows 3 Repeat with 50% reads 7, as expected. No effect. 8-Power Manager Brightness Applet shows as file backlight, sometimes says cannot read brightness. 9-When screensaver times out, automatic dimming works perfectly, step by step, and light comes back, always to max, when the mouse/pad or a key are hit. Tentative bottom line: the power manager, its applet, and the buttons write the value of the desired setting in file /sys/class/backlight/dell_backlight/backlight but the value does not make its way to the hardware. By comparison with screensaver control, the bug may possibly be located. Does somebody know if screensaver disables gnome? I have seen a success report with other hardware by entering the value of the brightness into the PCI VGA controller device. In my case lspci says: 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 12) lspci -n :00:02.0 0300: 8086:0046 (rev 12) That report says the PCI register is F4.B. Form me this should work if F4.B is correct for my controller: setpci -s 00:2.0 F4.B=7 to set to 7 . NO EFFECT OBSERVED. Can somebody tell me where to find the registers for chip 8086:0086 ? Jacques
Typo in preceding line: registers wanted for chip 8086;0046 Jacques
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 WONTFIX if it remains open with a Fedora 'version' of '12'. 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 prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I can set my laptop brightness perfectly using Fedora 14.
(In reply to comment #71) Please change version from 12 to 13. This bug is identically observed in Fedora 13 ! So the end of life of Fedora 12 is NOT a valid reason to drop this bug. There is a new report that it has disappeared in Fedora 14. What about qualifying what has been done in F14 to fix the bug? It may be trivial to correspondingly correct Fedora 13 installations ! > This message is a reminder that Fedora 12 is nearing its end of life. > Approximately 30 (thirty) days from now Fedora will stop maintaining > and issuing updates for Fedora 12. 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 WONTFIX if it remains open with a Fedora > 'version' of '12'. > > 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 prior to Fedora 12's end of life. > > Bug Reporter: Thank you for reporting this issue and we are sorry that > we may not be able to fix it before Fedora 12 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 please change the 'version' of this > bug to the applicable version. If you are unable to change the version, > please add a comment here and someone will do it for you. > > 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. > > The process we are following is described here: > http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I concur with Jacques Goldberg, this bug is still to be fixed. I have installed F14 onto my sony Vaio FW51ZH laptop and the brightness can not be altered. I had this problem with F12 and it went away when I installed F13.
(In reply to comment #72) > I can set my laptop brightness perfectly using Fedora 14. Eric this is interesting. I am under F13 fully updated and the problem is there. Before upgrading to F14 to try to benefit of the fix but possibly run into a very big job of upgrading several heavy packages, I gave F14 a try with the Live-usb. Result: The FN buttons (F4 and F5 on my Dell N3010 Inspiron) now work in the sense that the displayed cursor follows what I am doing while it would not under F13. A definite progress. But the actual brightness does not change. The brightness does change with these buttons at the BIOS level and while still under grub, but sets back to maximum when the Fedora splash screen starts while booting, both under F13 and under F14 Live. Finally both under F13 and F14 live, I get this: [goldberg@localhost]/etc/openafs>xbacklight -get No outputs have backlight property So with F14 Live the only change is that the FN buttons display behaves as it should but that's all. No control of brightness. Even more puzzling is comment 74 which reports BAD with F12, OK with F13, BAD back with F14 . Jacques
I have an H.P. Envy 14 with an up to date F14. The display is always at 100% and I am unable to dim it. This problem does seem to be fixed in Ubuntu.
I'm unsure of the process going on, but it seems like there is a solution in the Ubuntu distro, does anyone know what the hold-up is in moving that patch into the Fedora kernel?
Chris The saga under Ubuntu is here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/568611 1-It applies only to the Intel i915 driver graphics chips 2-Please see the story of the fix at items 11, 13, 53 and then all along until the end.
Thanks Jacques, I do have the i915 driver graphics chip, and see this issue. I would like to see the fix built into Fedora. I've been following that story, I appreciate your link.. I did not actually see the ubuntu sources. I was hoping someone had blazed this path ahead of me... Is there anyone out there who has already converted this patch to an F13/F14 kernel?
I can confirm that running F14 on my Lenovo T61 with an Intel Mobile GM965/GL960 I can reduce the brightness but not increase it again. This is the same behaviour I had on F12.
Is https://bugzilla.redhat.com/show_bug.cgi?id=628731 a dupe of this bug? Also, can we look for a more upstream friendly solution?
Zameer, id=628731 is not a dupe of the bug but it is definitely related. The bug with id=519105 (the present thread) applies to many hardware configurations in particular graphics subsystems. Id=628731 points to a KLUDGE, not a solution, not trivial to propagate upstream, which applies ONLY to chips supported by the Intel 915 driver. An Ubuntu user has found and reported how to patch the driver and some higher layer so that a workaround lets adjust the brightness. Bottom line: at this stage, since the kludge has reached the audience of 519105, thread 628731 can safely be closed although *THE* bug discussed in 519105 has by NO MEANS be solved under F12, F13, F14, even not for the specific Intel 915 driver. Jacques
The issue still persists in the fully updated Fedora 14 on a Lenovo B40 laptop.
http://koji.fedoraproject.org/koji/buildinfo?buildID=211304 Please try the rawhide kernel here and let me know if you have any luck there. regards, Kyle
The rawhide kernel (kernel-2.6.37-0.rc7.git0.2.fc15) didn't fix the problem on my Lenovo B40 machine.
The rawhide and latest vanilla kernel does not fix the problem on my lenovo G550.
The rawhide kernel (kernel-2.6.37-0.rc7.git0.2.fc15) did not change the backlight issue on my HP Envy 14. Still no dimming. I'm also not able to get to the Hybrid Graphics card, so none of the external slots will work, I'm not sure if that is related or not.
Did your brightness control work with older kernels? If not, please open a separate bug - this bug is purely to track regressions in brightness control through the 2.6.3x timescale.
The machine was new in Sept. (2010), Several pieces of hardware were not really supported in the older Fedora released (prior to 13). So, I have not even installed anything other than (F13, and F14). I can confirm, the brightness does not work in 13, and does not work in 14. I think my issues are all connected with the i915 issues, I thought this issue was related to the i915 chipset support? I do know if I install ubuntu 10.10, and apply a couple of (special) patches the brightness and Hybrid graphics will work. Neither of which work in Fedora.
This bug covers a kernel regression (hence "no longer works"). If it's never worked for you then please open a separate bug.
I do not understand your reasoning (I do know what regression is, but just because it "no longer works" does not disclude it because it never worked, If I tried this on F12, the screen dimming might well work, likely it would, but I would loose my mouse, and other pieces of functionality)... I do know that https://bugs.launchpad.net/ubuntu/+source/linux/+bug/568611 will fix my issue, so does 568611 have anything to do with this bug, or should that be moved into the new ticket created? I am also getting the same codes returned as described in this ticket. When looking at the comments, it looks like 568611 is not a 'fix' but is a 'kludge' and a fix is being worked? I just want the dimming to work on my laptop, and 568611's 'kludge' will do it. That ticket is what pulled me to this ticket.
"just because it "no longer works" does not disclude it because it never worked" Actually, it does. Please open a separate bug - it's unhelpful for one bug to end up with a large number of separate issues. Unless you know that your brightness control worked with 2.6.29, this is not the appropriate bug.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 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 WONTFIX if it remains open with a Fedora 'version' of '13'. 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 prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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. Thank you for reporting this bug and we are sorry it could not be fixed.