Bug 909552
| Summary: | Brightness/Backlight adjustement does not work anymore on Dell Inspiron 15r | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Téo M. <teomazars> | ||||||||||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||||||||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||
| Severity: | medium | Docs Contact: | |||||||||||||||
| Priority: | unspecified | ||||||||||||||||
| Version: | 20 | CC: | aaron.lwe, chetan_khilosiya, collura, dannybaumann, freddy, gansalmon, itamar, ja, jonathan, kernel-maint, madhu.chinakonda, pachoramos1, sergiodj, turgut | ||||||||||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||||||||||
| Target Release: | --- | ||||||||||||||||
| Hardware: | x86_64 | ||||||||||||||||
| OS: | Linux | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||
| Last Closed: | 2014-05-21 17:22:03 UTC | Type: | Bug | ||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||
| Embargoed: | |||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Téo M.
2013-02-09 10:41:52 UTC
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>
|