This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 519105

Summary: Can no longer set laptop panel lcd brightness with 2.6.3x.x kernels
Product: [Fedora] Fedora Reporter: Eric Donkersloot <eric.donkersloot>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: aks.abhishek, andre.viegas, andy.shevchenko, bugzilla, chema, chris, chrisv, collura, debesh.bhatta, domenictux, dymaxion, itamar, jacques.goldberg, jensk.maps, jfeeney, jonbakke, j.zhong, kernel-maint, kmcmartin, lists, maxim, pkst, proliant, rbinkhor, rnichols42, sgruszka, srinivasa, zilrro, zmanji
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 593764 (view as bug list) Environment:
Last Closed: 2011-06-27 10:21:28 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
_BQC on some laptops returns an uninitialized value when it's invoked for the first time. none

Description Eric Donkersloot 2009-08-25 03:57:26 EDT
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
Comment 1 Eric Donkersloot 2009-08-27 07:57:40 EDT
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.
Comment 2 Chuck Ebbert 2009-08-27 21:04:02 EDT
I don't even know what information to ask for here.
Comment 3 Eric Donkersloot 2009-08-28 08:43:18 EDT
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 ?
Comment 4 Matthew Garrett 2009-08-28 12:36:46 EDT
The backported code is present in 2.6.30. Does hitting the brightness keys cause any messages to appear in dmesg?
Comment 5 Eric Donkersloot 2009-08-30 10:28:02 EDT
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"
Comment 6 Eric Donkersloot 2009-09-07 03:23:03 EDT
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"
Comment 7 Matthew Garrett 2009-09-07 09:37:01 EDT
The ACPI video driver is refusing to bind - there's a patch submitted upstream that I'll integrate.
Comment 8 Eric Donkersloot 2009-09-14 04:52:56 EDT
Is there a kernel on Koji yet that I can use to test ?
Comment 9 Eric Donkersloot 2009-09-16 06:48:45 EDT
Can you be more specific on which patch needs to be applied ? Thank you
Comment 10 Eric Donkersloot 2009-09-28 03:22:24 EDT
Any update on this bug report please ?
Comment 11 Eric Donkersloot 2009-10-05 06:49:59 EDT
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
Comment 12 Eric Donkersloot 2009-10-22 08:38:43 EDT
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
Comment 13 Eric Donkersloot 2009-11-05 07:19:21 EST
http://bugzilla.kernel.org/attachment.cgi?id=22675
Comment 14 Eric Donkersloot 2009-11-05 07:26:53 EST
Created attachment 367604 [details]
_BQC on some laptops returns an uninitialized value when it's invoked for the first time.
Comment 15 Maxim Burgerhout 2009-11-08 05:01:50 EST
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?
Comment 16 Eric Donkersloot 2009-11-10 10:11:22 EST
@Maxim:

Can you please remove the sony_laptop module and insert it again ? Do you see any related messages in /var/log/messages ?
Comment 17 Maxim Burgerhout 2009-11-10 10:26:14 EST
(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
Comment 18 Eric Donkersloot 2009-11-10 11:08:11 EST
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"
Comment 19 Maxim Burgerhout 2009-11-10 13:33:16 EST
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
Comment 20 Eric Donkersloot 2009-11-16 06:32:06 EST
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.
Comment 21 Bug Zapper 2009-11-16 06:39:47 EST
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
Comment 22 Eric Donkersloot 2009-11-16 17:23:55 EST
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
Comment 23 Spencer Goh 2009-11-16 22:30:57 EST
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.
Comment 24 Chris Vickerson 2009-11-20 21:20:09 EST
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?
Comment 25 Eric Donkersloot 2009-11-21 14:26:39 EST
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.
Comment 26 Chris Vickerson 2009-11-21 15:23:38 EST
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!
Comment 27 proliant 2009-11-22 09:45:40 EST
Same problem for Sony Vaio VGN-TT92JS :(
Comment 28 Verdna 2009-11-23 09:05:35 EST
Same problem for Sony Vaio VGN-CS360A :(
Comment 29 Maxim Burgerhout 2009-11-23 09:31:48 EST
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.
Comment 30 Eric Donkersloot 2009-11-23 09:58:55 EST
(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.
Comment 31 Eric Donkersloot 2009-11-25 10:37:19 EST
(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.
Comment 32 Eric Donkersloot 2009-11-28 09:36:23 EST
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 ?
Comment 33 proliant 2009-11-28 20:40:05 EST
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.
Comment 34 Ian M 2009-12-02 04:22:17 EST
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.
Comment 35 domenictux 2009-12-03 19:02:48 EST
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
Comment 36 debesh 2009-12-04 14:41:59 EST
*** Bug 540022 has been marked as a duplicate of this bug. ***
Comment 37 Robert Nichols 2009-12-05 20:19:36 EST
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.
Comment 38 Eric Donkersloot 2009-12-06 06:51:31 EST
(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.
Comment 39 Robert Nichols 2009-12-06 12:33:24 EST
(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.
Comment 40 jonbakke 2009-12-10 15:31:09 EST
(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.
Comment 41 Zameer Manji 2009-12-30 00:57:01 EST
(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.
Comment 42 Eric Donkersloot 2009-12-31 04:19:08 EST
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 !
Comment 43 Stanislaw Gruszka 2010-01-15 06:53:59 EST
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
Comment 44 Eric Donkersloot 2010-01-15 12:39:55 EST
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.
Comment 45 proliant 2010-01-15 21:19:23 EST
Model: Sony Vaio VGN-TT92JS

Appending acpi_backlight=vendor to kernel boot parameter works!
Eric, thank you for your finding!! : )
Comment 46 Andy Shevchenko 2010-02-03 13:27:32 EST
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...
Comment 47 Eric Donkersloot 2010-02-04 06:27:58 EST
Andy,

Have you tested the 2.6.32.7-40 kernel ? What are the results ?
Comment 48 Andy Shevchenko 2010-02-04 06:45:53 EST
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.
Comment 49 Matt Castelein 2010-02-08 19:53:32 EST
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.
Comment 50 Jiri Skala 2010-02-22 04:17:48 EST
*** Bug 541257 has been marked as a duplicate of this bug. ***
Comment 51 Jiri Skala 2010-02-22 04:20:52 EST
*** Bug 558345 has been marked as a duplicate of this bug. ***
Comment 52 Kostas 2010-03-09 05:41:29 EST
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
Comment 53 Chema 2010-03-15 14:54:26 EDT
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.
Comment 54 Kostas 2010-03-16 06:39:05 EDT
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)
Comment 55 Chema 2010-03-16 14:11:41 EDT
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.
Comment 56 Kostas 2010-03-16 15:20:36 EDT
(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
Comment 57 Chema 2010-03-16 15:49:06 EDT
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
Comment 58 Mark Lees 2010-03-17 13:48:32 EDT
Hi,

I've just updated to the latest kernel and my brightness buttons are now operational.

:o)

M.
Comment 59 Mark Lees 2010-03-17 13:49:40 EDT
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.
Comment 60 Andy Shevchenko 2010-03-17 13:56:36 EDT
(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).
Comment 61 Chema 2010-03-19 03:34:05 EDT
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?
Comment 62 Abhishek Singh 2010-05-18 06:32:04 EDT
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.
Comment 63 Abhishek Singh 2010-05-18 06:34:01 EDT
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.
Comment 64 James 2010-06-14 19:57:13 EDT
Fresh install 64-bit Fedora 13 on Asus UL20A, same problem on me. keep up-to-date but still the same problem.
Comment 65 Jacques Goldberg 2010-09-07 14:52:52 EDT
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/
Comment 66 Zameer Manji 2010-09-08 16:21:12 EDT
Could anyone check first if Kamal's fixes made it upstream?
Comment 67 Kyle McMartin 2010-09-08 20:45:25 EDT
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
Comment 68 Srinivasa Sha S R 2010-09-15 10:45:19 EDT
I have the same problem in F13. I hope the solution will be available soon.
Comment 69 Jacques Goldberg 2010-09-15 13:21:57 EDT
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
Comment 70 Jacques Goldberg 2010-09-15 13:29:08 EDT
Typo in preceding line: registers wanted for chip 8086;0046
Jacques
Comment 71 Bug Zapper 2010-11-04 06:23:28 EDT
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
Comment 72 Eric Donkersloot 2010-11-04 06:27:54 EDT
I can set my laptop brightness perfectly using Fedora 14.
Comment 73 Jacques Goldberg 2010-11-04 09:53:48 EDT
(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
Comment 74 Mark Lees 2010-11-09 03:19:41 EST
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.
Comment 75 Jacques Goldberg 2010-11-09 03:51:40 EST
(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
Comment 76 chris 2010-11-10 01:07:16 EST
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.
Comment 77 chris 2010-11-10 12:32:49 EST
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?
Comment 78 Jacques Goldberg 2010-11-13 11:56:39 EST
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.
Comment 79 chris 2010-11-17 12:41:35 EST
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?
Comment 80 Robert Binkhorst 2010-11-18 02:50:07 EST
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.
Comment 81 Zameer Manji 2010-11-25 12:28:35 EST
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?
Comment 82 Jacques Goldberg 2010-11-25 14:45:45 EST
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
Comment 83 Abhishek Singh 2010-12-22 05:13:23 EST
The issue still persists in the fully updated Fedora 14 on a Lenovo B40 laptop.
Comment 84 Kyle McMartin 2010-12-22 12:30:28 EST
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
Comment 85 Abhishek Singh 2010-12-22 23:16:08 EST
The rawhide kernel (kernel-2.6.37-0.rc7.git0.2.fc15) didn't fix the problem on my Lenovo B40 machine.
Comment 86 Zameer Manji 2010-12-22 23:35:53 EST
The rawhide and latest vanilla kernel does not fix the problem on my lenovo G550.
Comment 87 chris 2010-12-23 01:40:27 EST
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.
Comment 88 Matthew Garrett 2010-12-23 09:00:02 EST
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.
Comment 89 chris 2010-12-23 12:48:31 EST
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.
Comment 90 Matthew Garrett 2010-12-23 13:04:32 EST
This bug covers a kernel regression (hence "no longer works"). If it's never worked for you then please open a separate bug.
Comment 91 chris 2010-12-23 23:21:41 EST
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.
Comment 92 Matthew Garrett 2010-12-24 01:01:07 EST
"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.
Comment 93 Bug Zapper 2011-06-02 13:48:44 EDT
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
Comment 94 Bug Zapper 2011-06-27 10:21:28 EDT
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.