Description of problem: Since the last update of the kernel, the brightness is stuck at the maximum. It can't be changed neither with keys Fn+F4/F5 nor with gnome-control-center. Version-Release number of selected component (if applicable): Dell Inspiron 15r "Special Edition - Blu-ray" $ uname -r 3.7.3-101.fc17.x86_64 $ lspci |grep VGA 00:02.0 VGA compatible controller: Intel Corporation Device 0166 (rev 09) 01:00.0 VGA compatible controller: ATI Technologies Inc Device 682f How reproducible: Just try to change the brightness of the screen on an Dell Inspiron 15r laptop with kernel 3.7.3-101.fc17.x86_64, with keybord shortcut, or with the gnone-control-center Actual results: Nothing happens, the brightness icon appear but the brightness does not change. Expected results: The brightness should decrease or increase... Additional info: - It worked with kernel versions 3.6.x. - It also works during boot until grub - I am not able to make my ATI card works, so only the Intel card is used. $ lsmod Module Size Used by fuse 78033 3 ebtable_nat 12808 0 ebtables 30758 1 ebtable_nat ipt_MASQUERADE 12881 3 iptable_nat 13012 1 nf_nat_ipv4 13200 1 iptable_nat nf_nat 25642 3 ipt_MASQUERADE,nf_nat_ipv4,iptable_nat xt_CHECKSUM 12550 1 iptable_mangle 12696 1 bridge 91098 0 stp 12869 1 bridge llc 14046 2 stp,bridge be2iscsi 93412 0 iscsi_boot_sysfs 15642 1 be2iscsi bnx2i 54715 0 lockd 93438 0 sunrpc 255581 1 lockd cnic 66882 1 bnx2i uio 19045 1 cnic cxgb4i 32880 0 cxgb4 113494 1 cxgb4i cxgb3i 32951 0 cxgb3 155602 1 cxgb3i mdio 13436 1 cxgb3 libcxgbi 56493 2 cxgb3i,cxgb4i ib_iser 37806 0 rdma_cm 42167 1 ib_iser ib_addr 13786 1 rdma_cm iw_cm 18222 1 rdma_cm ib_cm 41726 1 rdma_cm ib_sa 32956 2 rdma_cm,ib_cm ib_mad 46341 2 ib_cm,ib_sa ib_core 74065 6 rdma_cm,ib_cm,ib_sa,iw_cm,ib_mad,ib_iser iscsi_tcp 18334 0 libiscsi_tcp 24177 4 cxgb3i,cxgb4i,iscsi_tcp,libcxgbi libiscsi 50543 8 libiscsi_tcp,bnx2i,cxgb3i,cxgb4i,be2iscsi,iscsi_tcp,ib_iser,libcxgbi scsi_transport_iscsi 57491 8 bnx2i,be2iscsi,iscsi_tcp,ib_iser,libcxgbi,libiscsi rfcomm 68965 4 bnep 19702 2 nf_conntrack_ipv4 14809 9 nf_defrag_ipv4 12674 1 nf_conntrack_ipv4 ip6t_REJECT 12940 2 nf_conntrack_ipv6 18624 8 nf_defrag_ipv6 18206 1 nf_conntrack_ipv6 xt_state 12579 16 nf_conntrack 84207 7 ipt_MASQUERADE,nf_nat,xt_state,nf_nat_ipv4,iptable_nat,nf_conntrack_ipv4,nf_conntrack_ipv6 ip6table_filter 12816 1 ip6_tables 26943 1 ip6table_filter snd_hda_codec_hdmi 36749 1 snd_hda_codec_conexant 66455 1 snd_hda_intel 37938 4 snd_hda_codec 131731 3 snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_hda_intel arc4 12616 2 snd_hwdep 17651 1 snd_hda_codec iwldvm 241608 0 snd_seq 64878 0 snd_seq_device 14137 1 snd_seq snd_pcm 98005 4 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel uvcvideo 80925 0 videobuf2_vmalloc 12968 1 uvcvideo videobuf2_memops 13391 1 videobuf2_vmalloc videobuf2_core 34281 1 uvcvideo videodev 120901 2 uvcvideo,videobuf2_core media 20445 2 uvcvideo,videodev snd_page_alloc 18269 2 snd_pcm,snd_hda_intel mac80211 540054 1 iwldvm snd_timer 28691 2 snd_pcm,snd_seq btusb 23871 0 bluetooth 319586 24 bnep,btusb,rfcomm snd 79380 16 snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_pcm,snd_seq,snd_hda_codec,snd_hda_intel,snd_seq_device iwlwifi 103188 1 iwldvm cfg80211 201717 3 iwlwifi,mac80211,iwldvm iTCO_wdt 13481 0 rfkill 21737 5 cfg80211,bluetooth mei 75354 0 dell_laptop 17370 0 soundcore 14492 1 snd iTCO_vendor_support 13420 1 iTCO_wdt lpc_ich 17062 0 dell_wmi 12682 0 coretemp 13394 0 mfd_core 13183 1 lpc_ich microcode 23449 0 r8169 67601 0 mii 13528 1 r8169 i2c_i801 18135 0 sparse_keymap 13527 1 dell_wmi dcdbas 14829 1 dell_laptop vhost_net 33860 0 tun 22939 2 vhost_net macvtap 18241 1 vhost_net macvlan 18732 1 macvtap kvm_intel 132720 0 kvm 431794 1 kvm_intel uinput 17615 0 binfmt_misc 17464 1 crc32c_intel 12902 0 ghash_clmulni_intel 13260 0 wmi 18698 1 dell_wmi i915 567858 3 video 18992 1 i915 radeon 907002 0 i2c_algo_bit 13258 2 i915,radeon drm_kms_helper 44759 2 i915,radeon ttm 79761 1 radeon drm 264190 6 ttm,i915,drm_kms_helper,radeon i2c_core 38354 7 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,radeon,videodev
Still does not work with 3.7.6-102.fc17.x86_64
doesn't works on 3.8.1.201 either
Could this be the same issue as https://bugzilla.redhat.com/show_bug.cgi?id=891148 ?
(In reply to comment #3) > Could this be the same issue as > https://bugzilla.redhat.com/show_bug.cgi?id=891148 ? Difficult to say. Different hardware, different GPU in use. Probably not. Is this still happening with 3.8.2-105.fc17 in updates-testing?
As said in bug id 891148, Fedora 17 up to kernel 3.6 worked without issue. I have asked a colleague, he confirms brightness is working with 3.8.2-105.fc17 (nouveau and nvidia driver). So the problem (at least for me) seems to be in Fedora 18, not 17.
You can read in https://bugzilla.kernel.org/show_bug.cgi?id=55071 about the root cause. The problem is in the Windows 8 code paths in the DSDT of this specific laptop; and _OSI=Windows 2012 was added in kernel 3.7.
OK, so if I understand correctly this will be fixed in 3.9 Ah well, I can live with it for now ...
Not sure where you got the impression that it will be fixed in 3.9 from?
I may have jumped to conclusions on second glance. In my enthusiasm all I saw was "Status: RESOLVED" and "Kernel Version: 3.9-rc2".
My colleague just informed me that when he freshly booted this morning (he updated the kernel yesterday) he can no longer change the brightness. My guess is he did not reboot into the new kernel yesterday when he reported he could still change brightness. Ergo, kernel 3.6 works, kernel 3.8 does not. Which is consistent with the remark from Danny about the addition of _OSI=Windows 2012 in kernel 3.7.
I see Danny has sent a series of patches upstream now. Hopefully those will get some review.
Josh, they're for a different problem. Basically there are a number of problems on the Inspiron 15R SE at the moment: Without _OSI=Windows 2012: - in-kernel brightness switching (via ACPI notifications, without user space processing XF86Brightness[Up|Down] doesn't work - this is what my patches fix - duplicate XF86Brightness* key events (one sent by the actual keyboard, one sent by the ACPI video driver): can be fixed by adding an xorg.conf snippet that blacklists the "Video Bus" input - if user space listens for XF86Brightness* + my patches are applied: brightness is changed multiple times (once or twice by user space through the brightness key, once by the in-kernel control): can be fixed by the module parameter video.brightness_switch_enabled=0 With _OSI=Windows 2012: - Brightness control doesn't work at all, because the _BCM method seemingly does nothing - this is what this bug report is about. I _suspect_ it's due to the missing ASLE interrupt in that case (which is only fired in the non-W8 case), but my knowledge of the ACPI spec(s) is not good enough to tell whether it's the AML or the kernel drivers (video.ko and i915.ko are involved) that are at fault. BTW, I seemingly can't enter a kernel parameter with spaces in grub2-efi. I tried to do acpi_osi="!Windows 2012", but no matter what kind of quoting I tried, grub2 converted the space to \x20, which made the kernel ignore the line. Can you guys reproduce that? If yes, I guess I'll write a separate report for that.
Any progress? Still doesn't works in 3.8.7-201.fc18.x86_64
I have the same problem on 3.8.8-202.fc18.x86_64.. xcalib works, bu the hotkeys do not.. The icon for brightness change appears when the keys are pressed, but its slider moves very little and the brightness does not change.
Same thing here. The strangest part is that this behaviour began when I upgraded the BIOS (I have a very similar machine, a Dell Inspiron 15R SE 7520, with the same video card). I see the same thing Turgut sees: when I press the Fn+F{4,5} buttons the bar moves very little and the brightness does not change (it is important to mention that I am using gnome-settings-daemon, who is the actual responsible for changing the brightness when the buttons are pressed, on top of i3 here). However, I can change the brightness by echoing to "/sys/class/backlight/intel_backlight/brightness". I've been experiencing this issue in the last hour, so I don't know who is the culprit here. Initially I thought it was gnome-settings-daemon, exactly because I managed to change the brightness via /sys. Anyway, I'll be following this bug. Please let me know if there is anything I can do to help. BTW, running 3.8.13-100.fc17.x86_64 and gnome-settings-daemon-3.4.2-4.fc17.x86_64 here.
From #839379, I ran "udevadm monitor" and found that the Fn+F{4,5} keys are actually changing what seems to be the wrong file: sergio@afrodite ~ $ udevadm monitor monitor will print the received events for: UDEV - the event which udev sends out after rule processing KERNEL - the kernel uevent KERNEL[1174.847401] change /devices/pci0000:00/0000:00:02.0/backlight/acpi_video1 (backlight) KERNEL[1174.848796] change /devices/pci0000:00/0000:00:02.0/backlight/acpi_video1 (backlight) UDEV [1174.850755] change /devices/pci0000:00/0000:00:02.0/backlight/acpi_video1 (backlight) UDEV [1174.851695] change /devices/pci0000:00/0000:00:02.0/backlight/acpi_video1 (backlight) KERNEL[1174.866853] change /devices/pci0000:00/0000:00:02.0/backlight/acpi_video1 (backlight) KERNEL[1174.867143] change /devices/pci0000:00/0000:00:02.0/backlight/acpi_video1 (backlight) According to my system, it should be changing "/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight". So yeah, maybe this is not a kernel bug (or rather not the same bug as Téo reported) after all...
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'. 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 17'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 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. 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.
This bug is in latest kernel too: 3.10.11-200.fc19.x86_64
Indeed -- likewise for my Dell Inspiron 15R "special edition" as well.. The issue remains with Fedora 19 latest updates..
*********** 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.
here with 3.11.1-200.fc19.x86_64, the issue is still present. Though I have seen some related commits in the 3.12 merge window (e.g 94fb9823 in Linus's tree), I hope that will fixe it.
I just did a daily yum update which changed xorg-server, logged out and logged back in. same result.. Hitting Fn+F4 of F5 result in the brightness icon being displayed on desktop, but no brightness change takes place.
Booting with: acpi_osi="Linux" acpi_backlight=vendor as kernel parameters solved the problem with me (at least on Gentoo)
Pacho: I tried that, but I get "Oh No, something bad happened" blurb and cannot login.
Yippee! Backlight fixed since this morning's update (kernel 3.12.5-302.fc20.x86_64) Thanks a lot guys! I have now some errors at startup, but since it works, I am putting the bug at fixed. Error details below: [root@blah ~]# systemctl status systemd-backlight systemd-backlight - Load/Save Screen Backlight Brightness of acpi_video0 Loaded: loaded (/usr/lib/systemd/system/systemd-backlight@.service; static) Active: failed (Result: start-limit) since Sat 2013-12-21 11:24:14 CET; 1min 36s ago Docs: man:systemd-backlight@.service(8) Process: 575 ExecStart=/usr/lib/systemd/systemd-backlight load %I (code=exited, status=1/FAILURE) Main PID: 575 (code=exited, status=1/FAILURE) Dec 21 11:24:14 blah systemd[1]: systemd-backlight: main process exited, code=exited, status=1/FAILURE Dec 21 11:24:14 blah systemd[1]: Failed to start Load/Save Screen Backlight Brightness of acpi_video0. Dec 21 11:24:14 blah systemd[1]: Unit systemd-backlight entered failed state. Dec 21 11:24:14 blah systemd[1]: Starting Load/Save Screen Backlight Brightness of acpi_video0... Dec 21 11:24:14 blah systemd[1]: systemd-backlight start request repeated too quickly, refusing to start. Dec 21 11:24:14 blah systemd[1]: Failed to start Load/Save Screen Backlight Brightness of acpi_video0. [root@blah ~]# systemctl status systemd-backlight systemd-backlight - Load/Save Screen Backlight Brightness of acpi_video1 Loaded: loaded (/usr/lib/systemd/system/systemd-backlight@.service; static) Active: failed (Result: start-limit) since Sat 2013-12-21 11:25:16 CET; 37s ago Docs: man:systemd-backlight@.service(8) Process: 2124 ExecStart=/usr/lib/systemd/systemd-backlight load %I (code=exited, status=1/FAILURE) Main PID: 2124 (code=exited, status=1/FAILURE) Dec 21 11:25:18 blah systemd[1]: Failed to start Load/Save Screen Backlight Brightness of acpi_video1. Dec 21 11:25:18 blah systemd[1]: Starting Load/Save Screen Backlight Brightness of acpi_video1... Dec 21 11:25:18 blah systemd[1]: systemd-backlight start request repeated too quickly, refusing to start. Dec 21 11:25:18 blah systemd[1]: Failed to start Load/Save Screen Backlight Brightness of acpi_video1. Dec 21 11:25:18 blah systemd[1]: Starting Load/Save Screen Backlight Brightness of acpi_video1... Dec 21 11:25:18 blah systemd[1]: systemd-backlight start request repeated too quickly, refusing to start. Dec 21 11:25:18 blah systemd[1]: Failed to start Load/Save Screen Backlight Brightness of acpi_video1. Dec 21 11:25:18 blah systemd[1]: Starting Load/Save Screen Backlight Brightness of acpi_video1... Dec 21 11:25:18 blah systemd[1]: systemd-backlight start request repeated too quickly, refusing to start. Dec 21 11:25:18 blah systemd[1]: Failed to start Load/Save Screen Backlight Brightness of acpi_video1.
Reopening, something is broken with Linux 3.14.2-200.fc20.x86_64 I bet that kernel's commit 0e9f81d3b7cd0649a3bc437391b6a0650f98f844 is the culprit (or at least related), though I am not able to prove it.
Please list /sys/class/backlight: $ ls /sys/class/backlight
Here: #ls /sys/class/backlight acpi_video0 acpi_video1 intel_backlight or better yet: acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0 acpi_video1 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video1 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight
(In reply to Téo M. from comment #28) > Here: > > #ls /sys/class/backlight > acpi_video0 acpi_video1 intel_backlight This is not expected, unless this is not a Win8 firmware. Please attach your acpidump: # acpidump > acpidump.txt Also, attach your dmesg. Thanks.
Created attachment 893625 [details] output of acpidump
Created attachment 893626 [details] output of dmesg
(In reply to Aaron Lu from comment #29) > (In reply to Téo M. from comment #28) > > Here: > > > > #ls /sys/class/backlight > > acpi_video0 acpi_video1 intel_backlight > > This is not expected, unless this is not a Win8 firmware. The laptop was shipped with Win7 pre-installed IIRC, not 100% sure though. I don't know if that information helps?
Does the acpi_video and/or intel_backlight work? What about the previous kernel?
(In reply to Aaron Lu from comment #33) > What about the previous kernel? With kernel 3.13.10-200.fc20.x86_64, it works like a charm. > Does the acpi_video and/or intel_backlight work? Please, how can I check that?
(In reply to Téo M. from comment #34) > > Does the acpi_video and/or intel_backlight work? > > Please, how can I check that? # cd /sys/class/backlight/acpi_videoX # cat max_brightness XXX # echo x > brightness # echo y > brightness x, y need to be smaller than max XXX. Then do the same thing for intel_backlight, see if any backlight level changes, thanks.
It only works with intel_backlight. Nothing happens with acpi_video0 nor 1.
You dmi table please: # dmidecode > dmi.txt
Created attachment 894101 [details] output or dmidecode
OK, I checked the DMI table, it is Dell Inspiron 7520, which is already in video's quirk table. And the firmware also claims win8, the i915 created the raw backlight interface, so I can't tell why the acpi_video interface is still created... Téo, I wonder if compiling kernel is OK to you? I need to add some debug prints in acpi_video_verify_backlight_support to see what's going wrong exactly.
> Téo, I wonder if compiling kernel is OK to you? I need to add some debug > prints in acpi_video_verify_backlight_support to see what's going wrong > exactly. Compiling the kernel should be OK, if I follow those instructions: https://fedoraproject.org/wiki/Building_a_custom_kernel, it will be fine right? Tell me what debug prints you need exctly
Created attachment 894218 [details] add debug prints to verify what's going wrong Apply on top of v3.14.2. I never tried fedora's srpm build so I don't know, I always use a git tree. I think the patch should aply on top of fedora's v3.14.2 kernel too.
Created attachment 894313 [details] dmesg with the patched kernel I attached the output of dmesg with the patched kernel. Relevant lines are all: acpi_video_verify_backlight_support: win8=1, use_native=0, raw=1
Ah, and I mistakenly built 3.14.3 instead of 3.14.2... I hope it's OK? I can do the same with 3.14.2 if needed.
Created attachment 894549 [details] Fix quirk tag in video's quirk table for Dell inspiron 7520 Please test this patch, apply on top of v3.14.3. BTW, I think I've found the problem, the tag used to identify 7520 is product version in video's quirk table while it should be product name.
Yay! The patch #894549 fixes the bug, please push. That's really nice, thanks a lot Aaron!
Patch sent out: https://patchwork.kernel.org/patch/4162111/
The fix landed in the main tree and will be available in the next release. Closing the bug, thanks all! commit 5ff365fb6aed4c7ee5aae7b0239ce0b514aefabc Author: Aaron Lu <aaron.lu> Date: Tue May 13 09:51:50 2014 +0800 ACPI / video: correct DMI tag for Dell Inspiron 7520 The DMI tag used to identify Dell Inspiron 7520 should be product name instead of product version. Fixes: 0e9f81d3b7cd (ACPI / video: Add systems that should favour native bac Reported-and-tested-by: Téo Mazars <teomazars> References: https://bugzilla.redhat.com/show_bug.cgi?id=909552 Cc: All applicable <stable.org> Signed-off-by: Aaron Lu <aaron.lu> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki>