Description of problem: The screen brightness is defined at its maximum value and can not be changed using the hardware buttons (Fn keys). It's not a key issue as acpi_listen gets it correctly and the OSD brightness applet appears on keypress (but the brightness bar does not move, nor does the actual brightness). It's neither related to Gnome as it happens also in KDE (see links at the end of this report) Changing the brightness works by "echo-ing" a value to these files: /sys/class/backlight/intel_backlight/brightness -or- /sys/class/backlight/acpi_video0/brightness I have test xbacklight which works fine. On Gnome the brightness cursor in System Settings works as well to change screen brightness. This is a regression. It happened after upgrading to kernel version 3.7.2. Worked fine on 3.6 and before. The computer is a Lenovo Thinkpad X230 () but this seems to affect any hardware using an Intel i915 driver. More info in attachment. Version-Release number of selected component (if applicable): kernel-3.7.2-201.fc18.x86_64 kernel-3.7.2-204.fc18.x86_64 How reproducible: Steps to Reproduce: 1. Boot the computer on kernel 3.7.x with default kernel options 2. Log in 3. Press hardware keys to change screen brightness (Fn+F8/F9 in my case) Actual results: The OSD applet appears but the brightness bar stays fixed and the brightness does not change. The brightness value in these files is not modified: /sys/class/backlight/intel_backlight/brightness /sys/class/backlight/acpi_video0/brightness Expected results: The OSD brightness applet bar should move up/down The screen brightness should increase/decrease The brightness value in the files mentioned above should change Additional info: Possibly related: https://bugzilla.redhat.com/show_bug.cgi?id=901375 https://bugs.archlinux.org/task/33177 https://bbs.archlinux.org/viewtopic.php?id=156605
Created attachment 685785 [details] grep -r . /proc/acpi
Created attachment 685787 [details] ls /sys/class/backlight
Created attachment 685788 [details] cat /proc/version
Created attachment 685789 [details] lspci -v -s 00:02.0
I am seeing similar issue. When I first installed F18 i.e. kernel 3.6 the brighness control worked fine. I used F2 and F3 to increase and decrease the brighness in linear steps (10 steps maybe?). After upgrading to F18 to 3.7 I noticed that my keyboard F2 and F3 shortcuts don't work as expected: i.e. I can just do a) no brightness b) mid-brighness, and c) full brighness. There is no scale. It is just three steps. $ grep -r . /proc/acpi /proc/acpi/button/lid/LID0/state:state: open /proc/acpi/wakeup:Device S-state Status Sysfs node /proc/acpi/wakeup:P0P1 S4 *disabled /proc/acpi/wakeup:KBD0 S3 *enabled pnp:00:08 /proc/acpi/wakeup:PS2M S3 *disabled pnp:00:09 /proc/acpi/wakeup:EHC1 S3 *enabled pci:0000:00:1d.0 /proc/acpi/wakeup:EHC2 S3 *enabled pci:0000:00:1a.0 /proc/acpi/wakeup:XHC S3 *enabled pci:0000:00:14.0 /proc/acpi/wakeup:HDEF S0 *disabled pci:0000:00:1b.0 /proc/acpi/wakeup:RP01 S4 *disabled pci:0000:00:1c.0 /proc/acpi/wakeup:PXSX S4 *disabled /proc/acpi/wakeup:RP02 S4 *disabled pci:0000:00:1c.1 /proc/acpi/wakeup:PXSX S4 *disabled pci:0000:08:00.0 /proc/acpi/wakeup:RP03 S4 *disabled /proc/acpi/wakeup:PXSX S4 *disabled /proc/acpi/wakeup:RP04 S4 *disabled pci:0000:00:1c.3 /proc/acpi/wakeup:PXSX S4 *disabled pci:0000:0a:00.0 /proc/acpi/wakeup:RP05 S4 *disabled /proc/acpi/wakeup:PXSX S4 *disabled /proc/acpi/wakeup:RP06 S5 *disabled pci:0000:00:1c.5 /proc/acpi/wakeup:PXSX S5 *enabled pci:0000:0b:00.0 /proc/acpi/wakeup:RP07 S4 *disabled /proc/acpi/wakeup:PXSX S4 *disabled /proc/acpi/wakeup:RP08 S4 *disabled /proc/acpi/wakeup:PXSX S4 *disabled /proc/acpi/wakeup:PEG0 S4 *disabled pci:0000:00:01.0 /proc/acpi/wakeup:PEGP S4 *disabled pci:0000:01:00.0 /proc/acpi/wakeup:PEG1 S4 *disabled /proc/acpi/wakeup:PEG2 S4 *disabled /proc/acpi/wakeup:PEG3 S4 *disabled /proc/acpi/wakeup:LID0 S3 *disabled $ ls /sys/class/backlight acpi_video0 acpi_video1 intel_backlight $ cat /proc/version Linux version 3.7.2-204.fc18.x86_64 (mockbuild.fedoraproject.org) (gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #1 SMP Wed Jan 16 16:22:52 UTC 2013 $ lspci -v -s 00:02.0 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device 181d Flags: bus master, fast devsel, latency 0, IRQ 46 Memory at 73000000 (64-bit, non-prefetchable) [size=4M] Memory at 60000000 (64-bit, prefetchable) [size=256M] I/O ports at 5000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: i915 This is a new HP envy dv7 quad core.
Bug still present in kernel 3.7.4-204 (3.7.4-204.fc18.x86_64) Using the kernel option "acpi_backlight=vendor" works as a temporary solution.
I vote for raising the urgency of this; battery life is terrible with the screen brightness at full blast. I have the same problem under kernel 3.6.10 (x86_64) on an Asus G75VW, which has both integrated Intel and Nvidia G660M graphics. (It's new; quite frankly, I don't even know which it's using yet.) All packages are from F18 "Core"/Everything; i.e., no updates yet. But acpi_backlight=vendor doesn't work for me, nor does echoing into /sys/.../brightness, nor the GNOME Brightness & Lock GUI, nor xbacklight (xbacklight -get is also a no-op). And the keys (fn+f5, fn+f6) don't do anything, not even the popup shows (whereas the audio volume popup does show and work). When I echo into /sys/.../brightness, the numbers do change (when cat'ed back), and the slider in GNOME B & L does change. But the screen brightness stays full. If it means anything, complete screen blanking does work (fn+f7). PS. I don't know how 3.7.4-204 works; when I boot it, nothing shows after a few kernel messages. But that's another story.
Bruce, this bug concerns Intel Graphics cards and only these. You should open another bug if you have a different issue with a different card.
I have the same issue with my Lenovo X1 carbon with Intel HD 4000 graphics running Fedora 18 with kernel 3.8.2-206. When the brightness is set at maximum, the function keys do not change the brightness at all. However, I can change the brightness in the settings, and if the brightness is set to anything less than maximum power, then the function keys will change the brightness slightly, but only a 10 - 15% percent in each direction. If the brightness is set at lowest, then the function keys will turn the brightness up to about 80% and then stop. $ cat /proc/version Linux version 3.8.2-206.fc18.x86_64 (mockbuild@bkernel02) (gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #1 SMP Fri Mar 8 15:03:34 UTC 2013 $ grep -r . /proc/acpi [sudo] password for anthony: /proc/acpi/ibm/fan:status: enabled /proc/acpi/ibm/fan:speed: 0 /proc/acpi/ibm/fan:level: auto /proc/acpi/ibm/volume:level: unsupported /proc/acpi/ibm/volume:mute: off /proc/acpi/ibm/beep:status: supported /proc/acpi/ibm/beep:commands: <cmd> (<cmd> is 0-17) /proc/acpi/ibm/led:status: supported /proc/acpi/ibm/led:commands: <led> on, <led> off, <led> blink (<led> is 0-15) /proc/acpi/ibm/cmos:status: supported /proc/acpi/ibm/cmos:commands: <cmd> (<cmd> is 0-21) /proc/acpi/ibm/light:status: off /proc/acpi/ibm/light:commands: on, off /proc/acpi/ibm/video:status: supported /proc/acpi/ibm/video:lcd: disabled /proc/acpi/ibm/video:crt: disabled /proc/acpi/ibm/video:dvi: disabled /proc/acpi/ibm/video:auto: disabled /proc/acpi/ibm/video:commands: lcd_enable, lcd_disable /proc/acpi/ibm/video:commands: crt_enable, crt_disable /proc/acpi/ibm/video:commands: dvi_enable, dvi_disable /proc/acpi/ibm/video:commands: auto_enable, auto_disable /proc/acpi/ibm/video:commands: video_switch, expand_toggle /proc/acpi/ibm/wan:status: enabled /proc/acpi/ibm/wan:commands: enable, disable /proc/acpi/ibm/hotkey:status: enabled /proc/acpi/ibm/hotkey:mask: 0x078c7ffb /proc/acpi/ibm/hotkey:commands: enable, disable, reset, <mask> /proc/acpi/ibm/driver:driver: ThinkPad ACPI Extras /proc/acpi/ibm/driver:version: 0.24 /proc/acpi/button/lid/LID/state:state: open /proc/acpi/wakeup:Device S-state Status Sysfs node /proc/acpi/wakeup:LID S4 *disabled /proc/acpi/wakeup:SLPB S3 *disabled /proc/acpi/wakeup:IGBE S4 *disabled /proc/acpi/wakeup:EXP2 S4 *disabled pci:0000:00:1c.1 /proc/acpi/wakeup:XHCI S3 *enabled pci:0000:00:14.0 /proc/acpi/wakeup:EHC1 S3 *enabled pci:0000:00:1d.0 /proc/acpi/wakeup:EHC2 S3 *enabled pci:0000:00:1a.0 /proc/acpi/wakeup:HDEF S4 *disabled pci:0000:00:1b.0 $ ls /sys/class/backlight/ acpi_video0 intel_backlight $ lspci -v -s 00:02.0 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 21f9 Flags: bus master, fast devsel, latency 0, IRQ 44 Memory at f0000000 (64-bit, non-prefetchable) [size=4M] Memory at e0000000 (64-bit, prefetchable) [size=256M] I/O ports at 4000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: i915
This bug appears to be very related to these bugs filed on Ubuntu's launchpad at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1121951 and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1098216
You are right Anthony, it seems to be exactly the same bug. Btw, this is the changelog of the latest kernel version I installed on my machine this morning (3.8.6-203.fc18.x86_64): --- * Tue Apr 09 2013 Josh Boyer <jwboyer> - 3.8.6-203 - Temporarily work around pci device assignment issues (rhbz 908888) - CVE-2013-1929 tg3: len overflow in VPD firmware parsing (rhbz 949932 949946) - Backport intel brightness quirk for emachines (rhbz 871932) --- I had some hope but unfortunately the brightness issue still exists on the ThinkPad (different graphic chip I guess)
(In reply to comment #11) > You are right Anthony, it seems to be exactly the same bug. > > Btw, this is the changelog of the latest kernel version I installed on my > machine this morning (3.8.6-203.fc18.x86_64): > > --- > * Tue Apr 09 2013 Josh Boyer <jwboyer> - 3.8.6-203 > - Temporarily work around pci device assignment issues (rhbz 908888) > - CVE-2013-1929 tg3: len overflow in VPD firmware parsing (rhbz 949932 > 949946) > - Backport intel brightness quirk for emachines (rhbz 871932) > --- > > I had some hope but unfortunately the brightness issue still exists on the > ThinkPad (different graphic chip I guess) Quirks are done based on PCI IDs. If you want to try the equivalent manually, you can add i915.invert_brightness=1 to your kernel cmdline. If that works, we can add a quirk for your specific machine. I didn't think it would work though, as your problem sounds different from "the screen is really dark all the time."
It's even the contrary, the screen backlight is at 100% all the time. Sounds completely unrelated to the mentioned bug fix for emachines anyway, plus it affects all Linux distros. You will find the exact reason of the Lenovo Thinkpad series bug here: Linux kernel bug: https://bugzilla.kernel.org/show_bug.cgi?id=51231 Ubuntu Launchpad bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1098216 (thanks anthony.christe)
*** Bug 909737 has been marked as a duplicate of this bug. ***
*** Bug 947437 has been marked as a duplicate of this bug. ***
*** Bug 906467 has been marked as a duplicate of this bug. ***
Proposed as a Blocker for 19-final by Fedora user ignatenkobrain using the blocker tracking app because: Regulation backlight very important on laptops. This bug affected ALL ThinkPads of 2012!
It happens in Lenovo ideapad y580 as well since 3.7 kernel. I have been surviving all linux distros only with this kernel command line with acpi_backlight=vendor and acpi_osi=Linux since 3.7 kernel. Initially I didn't know which package was responsible for the bug and filed a bug in xorg I was told to file it under acpi in the linux kernel, which I was lazy and didn't do, but found the workaround with the kernel command line as suggested above. Details: https://bugs.freedesktop.org/show_bug.cgi?id=59726
*** Bug 957016 has been marked as a duplicate of this bug. ***
*** Bug 922192 has been marked as a duplicate of this bug. ***
acpi_osi="!Windows 2012" would probably fix this problem as well, if there wasn't https://bugzilla.redhat.com/show_bug.cgi?id=923374 ...
(In reply to comment #21) > acpi_osi="!Windows 2012" would probably fix this problem as well, if there > wasn't https://bugzilla.redhat.com/show_bug.cgi?id=923374 ... really... I use UEFI...
I have the same issue. Lenovo Ideapad s206 Fedora 18 Kernel: 3.9.3-201.fc18.i686 OSD with current brightness is showing, bar changing, but brightness not changing. Any changes in grub has no affect. Also, I found that independent from method of changin brightness, changes are apply only after Xorg restart.
It works just fine on two computers with Fedora 19, kernel-3.9.4-300.fc19.x86_64, on two machines: Lenovo IdeaPad G470 - Intel i5-2430M (SandyBridge) Lenovo ThinkPad T420s - Intel i5-2540M (SandyBridge)
Discussed at 2013-05-29 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-29/f19final-blocker-review-1.2013-05-29-16.02.log.txt . We couldn't see any reason to accept this as a release blocker; it's an annoying bug, sure, but it doesn't violate any criteria and we don't see any advantage to delaying the release until this bug is fixed; those affected can get the fix as a post-release kernel update, and delaying the release would inconvenience all the people who aren't affected by the bug.
I'm also hitting this bug with Thinkpad X230 $ cat /proc/version Linux version 3.9.4-300.fc19.x86_64 (mockbuild@bkernel02) (gcc version 4.8.0 20130412 (Red Hat 4.8.0-2) (GCC) ) #1 SMP Fri May 24 22:17:06 UTC 2013 $ sudo grep -r . /proc/acpi /proc/acpi/ibm/fan:status: enabled /proc/acpi/ibm/fan:speed: 2979 /proc/acpi/ibm/fan:level: auto /proc/acpi/ibm/volume:level: unsupported /proc/acpi/ibm/volume:mute: on /proc/acpi/ibm/beep:status: supported /proc/acpi/ibm/beep:commands: <cmd> (<cmd> is 0-17) /proc/acpi/ibm/led:status: supported /proc/acpi/ibm/led:commands: <led> on, <led> off, <led> blink (<led> is 0-15) /proc/acpi/ibm/cmos:status: supported /proc/acpi/ibm/cmos:commands: <cmd> (<cmd> is 0-21) /proc/acpi/ibm/light:status: off /proc/acpi/ibm/light:commands: on, off /proc/acpi/ibm/video:status: supported /proc/acpi/ibm/video:lcd: disabled /proc/acpi/ibm/video:crt: disabled /proc/acpi/ibm/video:dvi: disabled /proc/acpi/ibm/video:auto: disabled /proc/acpi/ibm/video:commands: lcd_enable, lcd_disable /proc/acpi/ibm/video:commands: crt_enable, crt_disable /proc/acpi/ibm/video:commands: dvi_enable, dvi_disable /proc/acpi/ibm/video:commands: auto_enable, auto_disable /proc/acpi/ibm/video:commands: video_switch, expand_toggle /proc/acpi/ibm/bluetooth:status: enabled /proc/acpi/ibm/bluetooth:commands: enable, disable /proc/acpi/ibm/hotkey:status: enabled /proc/acpi/ibm/hotkey:mask: 0x078c7ffb /proc/acpi/ibm/hotkey:commands: enable, disable, reset, <mask> /proc/acpi/ibm/driver:driver: ThinkPad ACPI Extras /proc/acpi/ibm/driver:version: 0.24 /proc/acpi/button/lid/LID/state:state: open /proc/acpi/wakeup:Device S-state Status Sysfs node /proc/acpi/wakeup:LID S4 *enabled /proc/acpi/wakeup:SLPB S3 *enabled /proc/acpi/wakeup:IGBE S4 *enabled pci:0000:00:19.0 /proc/acpi/wakeup:EXP3 S4 *disabled pci:0000:00:1c.2 /proc/acpi/wakeup:XHCI S3 *enabled pci:0000:00:14.0 /proc/acpi/wakeup:EHC1 S3 *enabled pci:0000:00:1d.0 /proc/acpi/wakeup:EHC2 S3 *enabled pci:0000:00:1a.0 /proc/acpi/wakeup:HDEF S4 *disabled pci:0000:00:1b.0 $ ls /sys/class/backlight/ acpi_video0 intel_backlight $ lspci -v -s 00:02.0 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 21fa Flags: bus master, fast devsel, latency 0, IRQ 42 Memory at f0000000 (64-bit, non-prefetchable) [size=4M] Memory at e0000000 (64-bit, prefetchable) [size=256M] I/O ports at 5000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: i915
Antoine Cotten, change some info in bug: -- Version: 18 ++ Version: 19 -- See Also: ++ See Also: https://lkml.org/lkml/2013/6/9/161
I can't add this link in the See Also field because it's not a valid link to a bug. Should I upload it here as a proposed patch with a reference to the mentioned page?
Created attachment 760501 [details] acpi-video-add-function-to-support-unregister-backlight-interface
Created attachment 760502 [details] ACPICA-Add-interface-for-getting-latest-OS-version-requested-via-_OSI
Created attachment 760503 [details] i915-Don-t-provide-ACPI-backlight-interface-if-firmware-expects-Windows-8
Added patches, but need kernel 3.10. Can you test my packages with this patches ? If yes - I can provide src.rpm and rpm's with it.
Did anyone test this patch? https://patchwork.kernel.org/patch/2697681/
(In reply to Piruthiviraj Natarajan from comment #33) > Did anyone test this patch? > https://patchwork.kernel.org/patch/2697681/ I don't have amd videocard. I can patch test kernel. If you have this bug in amd videocard.
Did anyone test patched kernel? git: https://github.com/ignatenkobrain/kernel/tree/f19 patches: https://github.com/ignatenkobrain/kernel/blob/f19/0001-acpi-video-add-function-to-support-unregister-backlight-interface.patch https://github.com/ignatenkobrain/kernel/blob/f19/0002-ACPICA-Add-interface-for-getting-latest-OS-version-requested-via-_OSI.patch https://github.com/ignatenkobrain/kernel/blob/f19/0003-i915-Don-t-provide-ACPI-backlight-interface-if-firmware-expects-Windows-8.patch RPMs: http://ignatenkobrain.asuscomm.com:8080/build/13.06.2013-12:15:50-kernel-f19/
No I don't have an amd card. I have an optimus nvidia card with ivybridge intel 4000 graphics. I was suggested that patch by chris wilson here https://bugs.freedesktop.org/show_bug.cgi?id=59726#c20. I have already linked at comment 18. I tried your binary packages in your last post. But it doesn't make any difference for me. I 'm still booting into a black screen. [root@localhost ~]# ls /sys/class/backlight/ intel_backlight [root@localhost ~]# grep -r . /proc/acpi /proc/acpi/button/lid/LID0/state:state: open /proc/acpi/wakeup:Device S-state Status Sysfs node /proc/acpi/wakeup:P0P1 S0 *disabled /proc/acpi/wakeup:EHC1 S3 *enabled pci:0000:00:1d.0 /proc/acpi/wakeup:EHC2 S3 *enabled pci:0000:00:1a.0 /proc/acpi/wakeup:XHC S3 *enabled pci:0000:00:14.0 /proc/acpi/wakeup:HDEF S0 *disabled pci:0000:00:1b.0 /proc/acpi/wakeup:PXSX S3 *disabled pci:0000:02:00.0 /proc/acpi/wakeup:PXSX S3 *disabled pci:0000:03:00.0 /proc/acpi/wakeup:PXSX S3 *disabled /proc/acpi/wakeup:PXSX S5 *disabled pci:0000:04:00.0 /proc/acpi/wakeup:RP05 S0 *disabled /proc/acpi/wakeup:PXSX S3 *disabled /proc/acpi/wakeup:RP06 S0 *disabled /proc/acpi/wakeup:PXSX S3 *disabled /proc/acpi/wakeup:RP07 S0 *disabled /proc/acpi/wakeup:PXSX S3 *disabled /proc/acpi/wakeup:RP08 S0 *disabled /proc/acpi/wakeup:PXSX S3 *disabled /proc/acpi/wakeup:PEG0 S4 *disabled pci:0000:00:01.0 /proc/acpi/wakeup:PEGP S4 *disabled pci:0000:01:00.0 /proc/acpi/wakeup:PEG1 S4 *disabled /proc/acpi/wakeup:PEG2 S4 *disabled /proc/acpi/wakeup:PEG3 S4 *disabled /proc/acpi/wakeup:LID0 S3 *enabled [root@localhost ~]
(In reply to Piruthiviraj Natarajan from comment #36) > No I don't have an amd card. I have an optimus nvidia card with ivybridge > intel 4000 graphics. I was suggested that patch by chris wilson here > https://bugs.freedesktop.org/show_bug.cgi?id=59726#c20. I have already > linked at comment 18. > > I tried your binary packages in your last post. But it doesn't make any > difference for me. I 'm still booting into a black screen. > [root@localhost ~]# ls /sys/class/backlight/ > intel_backlight > [root@localhost ~]# grep -r . /proc/acpi > /proc/acpi/button/lid/LID0/state:state: open > /proc/acpi/wakeup:Device S-state Status Sysfs node > /proc/acpi/wakeup:P0P1 S0 *disabled > /proc/acpi/wakeup:EHC1 S3 *enabled pci:0000:00:1d.0 > /proc/acpi/wakeup:EHC2 S3 *enabled pci:0000:00:1a.0 > /proc/acpi/wakeup:XHC S3 *enabled pci:0000:00:14.0 > /proc/acpi/wakeup:HDEF S0 *disabled pci:0000:00:1b.0 > /proc/acpi/wakeup:PXSX S3 *disabled pci:0000:02:00.0 > /proc/acpi/wakeup:PXSX S3 *disabled pci:0000:03:00.0 > /proc/acpi/wakeup:PXSX S3 *disabled > /proc/acpi/wakeup:PXSX S5 *disabled pci:0000:04:00.0 > /proc/acpi/wakeup:RP05 S0 *disabled > /proc/acpi/wakeup:PXSX S3 *disabled > /proc/acpi/wakeup:RP06 S0 *disabled > /proc/acpi/wakeup:PXSX S3 *disabled > /proc/acpi/wakeup:RP07 S0 *disabled > /proc/acpi/wakeup:PXSX S3 *disabled > /proc/acpi/wakeup:RP08 S0 *disabled > /proc/acpi/wakeup:PXSX S3 *disabled > /proc/acpi/wakeup:PEG0 S4 *disabled pci:0000:00:01.0 > /proc/acpi/wakeup:PEGP S4 *disabled pci:0000:01:00.0 > /proc/acpi/wakeup:PEG1 S4 *disabled > /proc/acpi/wakeup:PEG2 S4 *disabled > /proc/acpi/wakeup:PEG3 S4 *disabled > /proc/acpi/wakeup:LID0 S3 *enabled > [root@localhost ~] Install xbacklight. Try to regulate brightness from keyboard. also see xbacklight -get
I am able to adjust screen brightness using my keyboard without xbacklight too. I was expecting that the patch would fix the LVDS black screen issue. Maybe I am wrong.
(In reply to Piruthiviraj Natarajan from comment #38) > I am able to adjust screen brightness using my keyboard without xbacklight > too. I was expecting that the patch would fix the LVDS black screen issue. > Maybe I am wrong. No. This patch unregister in sysfs node acpi_video interface. Regulate backlight without acpi. Direct videodriver. Without patch: $ ls -alF /sys/class/backlight/ total 0 drwxr-xr-x. 2 root root 0 Jun 12 11:47 ./ drwxr-xr-x. 49 root root 0 Jun 12 11:47 ../ lrwxrwxrwx. 1 root root 0 Jun 12 11:47 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0/ lrwxrwxrwx. 1 root root 0 Jun 12 11:47 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight/ With patch: $ ls -alF /sys/class/backlight/ total 0 drwxr-xr-x. 2 root root 0 Jun 12 11:47 ./ drwxr-xr-x. 49 root root 0 Jun 12 11:47 ../ lrwxrwxrwx. 1 root root 0 Jun 12 11:47 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight/
xbacklight worked for me. Hoping to see fn+F8 and fn+F9 keys also to work.
is there any update on this bug?
Patches: https://lkml.org/lkml/2013/7/17/718 https://lkml.org/lkml/2013/7/17/719 https://lkml.org/lkml/2013/7/17/715 https://lkml.org/lkml/2013/7/17/720 And for new kernels need this patches (for UEFI) ( bug 983841 ): https://lkml.org/lkml/2013/7/11/162
Created attachment 775627 [details] backlight-rhbz903136.patch 3 patches are in one for current kernel in fedora git kernel (master branch)
encountered the original issue on previous releases (thinkpad t430s, f17 all kernels, and f19 3.9.5-301), but fn+f8/f9 are working for me in latest f19 update to 3.10.3-300 - thanks Igor!
(In reply to tthrockm from comment #44) > encountered the original issue on previous releases (thinkpad t430s, f17 all > kernels, and f19 3.9.5-301), but fn+f8/f9 are working for me in latest f19 > update to 3.10.3-300 - thanks Igor! No. In 3.10.3 we have acpi backlight interface and it works not correctly.In 3.11-rc2 all fixed, but Rafael J. Wysocki reverted patch because it causes regressions in backlight on some machines. I will keep you up-to-date.
Since I installed the newest stable kernel version this morning (3.10.4-300.fc19.x86_64) everything works properly again! Thanks a lot Igor
I can also confirm with my current kernel package kernel-3.10.3-300.fc19.x86_64 that screen brightness has started working fine. Thanks Igor.
I've confirmed that kernel-3.10.4-300.fc19.x86_64 fixes the backlight control for Lenovo T530 laptops with intel graphics. The /sys/class/backlight/acpi_video0/actual_brightness file now reports the full range of 101 discrete levels instead of clamping to just 16 values.
Using kernel-3.10.10-200.fc19.x86_64 freshly installed from a Fedora 19 netinstaller on a Thinkpad X200 using Intel graphics, this bug is present and Fn+Home/End does not change brightness. The brightness does not lock at max value, it uses whatever brightness value was present before the BIOS handed control to GRUB. Echoing values of 1-15 to /sys/class/backlight/acpi_video0/brightness works and yields backlight changes.
3.10.10-100.fc18.x86_64 on x230/intel-graphics works just fine. Thanks!
Hope this is an appropriate place to mention it; Same or similar issue on Dell XPS-12 with Intel HD4000 graphics, issue still exists with F19 with testing updates and kernel 3.11.0-3.fc20.x86_64 -- boots into black screen unless acpi_backlight=vendor is put in boot parameters. Also never successfully boots all the way without nomodeset in boot parameters (acpi_osi=Linux and i915.modeset=1 don't help). http://forums.fedoraforum.org/showthread.php?t=293792
Take this bug. After fix in upstream - will make patches for our kernel (temporary) https://lkml.org/lkml/2013/9/9/74 Try this build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5918516 You need to specify i915.take_over_backlight=1 in kernel cmdline, that module option is set to false by default for now. Also doesn't work indicator in GUI (Thinkpads, maybe other). We work at this. After boot test backlight and provide: $ tree /sys/class/backlight/ (In reply to Dan Taylor from comment #51) > Hope this is an appropriate place to mention it; Same or similar issue on > Dell XPS-12 with Intel HD4000 graphics, issue still exists with F19 with > testing updates and kernel 3.11.0-3.fc20.x86_64 -- boots into black screen > unless acpi_backlight=vendor is put in boot parameters. Also never > successfully boots all the way without nomodeset in boot parameters > (acpi_osi=Linux and i915.modeset=1 don't help). > > http://forums.fedoraforum.org/showthread.php?t=293792 I think you should create new bugreport. This bug about regulate backlight. But please test my build too.
ah. I'm wrong. That build failed. NEW build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5918644
Similar issue with a fresh install of F19 and KDE. I can change backlight by echoing /sys/class/backlight/intel_backlight/brightness or using xbacklight. The hardware buttons doesn't work and kde doesn't show the brightness control. It worked in previous F17. The kernel parameter acpi_backlight=vendor doesn't work for me. # ls -l /sys/class/backlight totale 0 lrwxrwxrwx. 1 root root 0 17 set 21.19 acer-wmi -> ../../devices/platform/acer-wmi/backlight/acer-wmi lrwxrwxrwx. 1 root root 0 17 set 21.19 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight # rpm -q kernel kernel-3.10.11-200.fc19.x86_64 # lspci -v -s 00:02.0 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] Device 036d Flags: bus master, fast devsel, latency 0, IRQ 41 Memory at b0000000 (64-bit, non-prefetchable) [size=4M] Memory at a0000000 (64-bit, prefetchable) [size=256M] I/O ports at 3050 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 I've tryed kernel-3.11.0-999.rhbz903136.fc19.x86_64.rpm with i915.take_over_backlight=1 but is very slow to boot and causes high cpu usage and black screen for me. Possibly related: https://bugs.kde.org/show_bug.cgi?id=296403
Please test new kernel w/ new patchset: https://bugzilla.redhat.com/show_bug.cgi?id=903136
The link above point to this bug. Probably there is another patched kernel, other than the one of comment #53...
ah. I'm sorry. Looking one, sending two. http://koji.fedoraproject.org/koji/taskinfo?taskID=5949544
*********** MASS BUG UPDATE ************** 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 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update 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.
yes. It is still an issue and applicable for both f19, f20.
(In reply to Igor Gnatenko from comment #57) > http://koji.fedoraproject.org/koji/taskinfo?taskID=5949544 After minutes spent to see my jobs failed to start, I can't boot my system again. These builds seem to be very unstable for my PC. The new kernel 3.11.1-200.fc19.x86_64 doesn't solves my problem.
Created attachment 801151 [details] 0001-backlight-introduce-backlight_device_registered.patch
Created attachment 801152 [details] 0002-ACPI-video-seperate-backlight-control-and-event-inte.patch
Created attachment 801153 [details] 0003-ACPI-video-Do-not-register-backlight-if-win8-and-nat.patch
Created attachment 801154 [details] 0004-thinkpad-acpi-fix-handle-locate-for-video-and-query-.patch
Please test: http://koji.fedoraproject.org/koji/taskinfo?taskID=5966804
(In reply to Igor Gnatenko from comment #65) > Please test: http://koji.fedoraproject.org/koji/taskinfo?taskID=5966804 This kernel can boot for me. But the behavior doesn't change: I can still change backlight by echoing /sys/class/backlight/intel_backlight/brightness or using xbacklight, but not with Fn keys. I've tryed both with and without acpi_backlight=vendor. # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.12.0-0.rc1.git0.1.backlight.fc19.x86_64 root=UUID=18722dca-190a-4852-a9e0-6a44fad1b98c ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet acpi_backlight=vendor i915.take_over_backlight=1
oh. so you need to fill a new bug.
Ok, but why not this one?
(In reply to Massimiliano from comment #68) > Ok, but why not this one? thats for regression w/ Win8 issue..
Sorry, I didn't realize that is not my case. However: https://bugzilla.redhat.com/show_bug.cgi?id=1012674
I have this kernel and it looks like its been fixed. uname -a Linux localhost.localdomain 3.12.0-0.rc2.git2.2.fc21.x86_64 #1 SMP Thu Sep 26 14:55:50 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Can anyone else confirm?
where did you get the rpm?
This bug is filed against F19 but the kernel that apparently has the fix in comment 71 is for F21. What is the gameplan for F19? Will the patch be backported or will 3.12 with the fix be released for F19 as well and if so when?
(In reply to Dennis Jacobfeuerborn from comment #73) > This bug is filed against F19 but the kernel that apparently has the fix in > comment 71 is for F21. Nobody else confirmed that. If you'd like to try it, grab this build: http://koji.fedoraproject.org/koji/buildinfo?buildID=476094 it should work on f19 without and conflicts that I'm aware of. > What is the gameplan for F19? Will the patch be backported or will 3.12 with > the fix be released for F19 as well and if so when? F19 will get 3.12 likely a couple of weeks after 3.12.1 is released. I do know there are additional win8 fixes queued for 3.13. We might have to look at bringing those back as well if they don't land in 3.12.y stable.
I just booted this kernel and it does *not* fix the issue. The screen is still extremely dark and the keys to control brightness don't work.
Dell XPS 13 L322X/0PJHXN. F20 with 3.12.0-1.fc21.x86_64 solve the flickering (#995782) but the display is still very dark and the problem discussed here is not solved. If I keep EFI but disable secure boot and enable "legacy option ROM" then everything works - also with 3.11.7-300.fc20.x86_64 .
@mads, how you boot a UEFI installed system in legacy mode? In other hand, sabayon kernel looks to works in UEFI & legacy mode: https://github.com/Sabayon/kernel
(In reply to JAlberto from comment #77) > @mads, how you boot a UEFI installed system in legacy mode? What is legacy mode to you? The old non-efi "BIOS" mode? That is by definition not UEFI. XPS13 has a checkmark for "legacy option ROM" in its firmware. I guess it do something BIOS-ish but it is still UEFI, not BIOS, and not really "legacy".
yes, legacy == not UEFI (legacy is how it's called in my FW setup. In comment #76 you say: "If I keep EFI but disable secure boot and enable "legacy option ROM" then everything works" How you boot a linux systme installed in UEFI mode as legacy? if I try to boot as legacy mode it just cannot find the boot partitions
(In reply to JAlberto from comment #79) > yes, legacy == not UEFI (legacy is how it's called in my FW setup. and that is not how it is in my firmware. It has a "legacy option ROM" while in UEFI. If your machine is different then your machine is different.
Mine is XPS13 fhd too
jalberto: I don't think "legacy option ROM" is the same thing as "legacy mode". An "option ROM" is a 'subsidiary' firmware to the system firmware - like, say, the firmware for a drive controller, or something like that: https://en.wikipedia.org/wiki/Option_ROM . I've no idea why toggling that option seems to be changing the behaviour for Mads, but I don't believe that by toggling that option he's actually switching between booting native UEFI and booting BIOS compat.
This bug almost fixed. Waiting for blacklist [0]. [0] http://thread.gmane.org/gmane.linux.acpi.devel/64401/focus=29889
Now I understand, thanks for the link Adam
Created attachment 828142 [details] 0001-ACPI-video-Add-systems-that-should-favor-native-back.patch So. For new kernels you need one patch, which enabling for some laptops use.native_backlight=1 by default.
Josh, I couldn't see applied previous 4 patches to 3.11.9.. If so, you have choice: * Apply 0001-ACPI-video-Add-systems-that-should-favor-native-back.patch as downstream * Wait some time This patch submitted by Aaron Lu to mail lists.
So what's the deal here? I just installed the latest available kernel vom koji (3.12.5) and apparently the problem still exists. My plan was to upgrade to F20 but I cannot do that if recent kernels are broken like this. "native_backlight=1" doesn't do anything either.
I just wanted to add my comments about a slightly different bug, although it's similar because it too involves the "Intel (Haswell) based Video" system: https://bugzilla.redhat.com/show_bug.cgi?id=1031335 Basically, on my ACER Aspire-S7 laptop (which uses Intel Haswell Video), Resume after a Suspend or Hibernate doesn't work. Just a blank screen appears on resumption. Full details are at the URL above. In that thread, someone referred me to this bug as being somewhat similar, so I figured I'd post it here. Unfortunately I'm not getting any traction there. One more note: While that bug mentions Fedora 19 and an older kernel, I've since upgraded to Fedora 20 and the latest kernel to see if that would fix the issue. Sadly, it didn't. Thanks in advance for your help.
Created attachment 842222 [details] 0001-ACPI-video-Add-systems-that-should-favor-native-back.patch Well. Some news here ;) Apply this patch for Linus git tree and laptops (from this patch) will use intel_backlight instead of acpi_video0. Kernel build: http://ignatenkobrain.asuscomm.com:8080/pub/kernel-backlight/ please test ;) If you laptop has this bug and use.native_backlight=1 fixes this problem - feel free to ping me. Will add you model to list. Merry xmas, folks!
http://lists.freedesktop.org/archives/dri-devel/2013-December/051007.html
I've tried the kernel build with use_native_backlight=1 and see no change. The backlight still doesn't work.
Well. It will merged to the 3.14. So closing. https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=1811fcb029fa3eca5bd1d25eab386b0c4b80fb93 People, if you will have this problem - open NEW bug
Hi All, For those still having backlight problems, please try booting with "video.use_native_backlight=1" on the kernel cmdline, note the video. in front of it, otherwise it won't work. If that works please file a new bug against the kernel, with your laptop model in the summary, *put me in the CC* and include the output of: grep '.*' /sys/class/dmi/id/*_* 2> /dev/null In the description of the bug. Regards, Hans
So - I've been hit by this (or a close malfunction) on a Lenovo ideapad with fedora 20. What worked for me was to set the "video.use_native_backlight" option to "0" (not to "1" as on comment 93). (I am noting it here, because it is where searching for "ideapad fedora backlight broke" and similar keywords lead)