Description of problem:
After upgrading to kernel-3.14.2-200.fc20.x86_64 the screen is extremely dim. If I boot kernel-3.13.10-200.fc20.x86_64 the screen is nice and bright.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot machine
Laptop screen is so dim it is nearly impossible to read.
Screen is bright enough to make it easy to read the screen.
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c)
Seeing this too, it appears to be
I'm going to be testing kernel-3.15.0-0.rc3.git4.2.fc21 here shortly.
3.15-rc3 is a bust too (functions similar to 3.14.2 in that regard for me), so maybe that referenced fdo bug may not be accurate (still testing).
Found one workaround:
echo $(cat max_brightness) > brightness
makes screen viewable again, and now:
* keyboard brightness controls seem to work
* intel_backlight interface seems to work to both get/set values
* dell_backlight interface works to get brightness, but setting fails
* kde OSD and brightness slider still do not work to control backlight.
* xbacklight seems to be able to get backlight values, but setting fails.
Retesting with 3.14.2-200.fc20 to compare, one thing is different to comment #3
* intel_backlight interface works to set, but get values don't get updated after adjusting brightness via keyboard controls
Backlight issues have been ping-ponging terribly for a few releases. The FreeDesktop.org bug you point to shows that.
Rex, do you also have a Lattitude D630?
Sorry for not mentioning details explicitly... Yes, I'm seeing this on a latitude d630 model (also have a d620 which is as-yet untested).
I've some general info on backlight problems + step-by-step debug instructions here:
You can give those a try, but I don't think that those really apply to this specific problem, since the D630 is quite old, and this is mostly targeted at various problems with newer models.
Looking at: https://bugs.freedesktop.org/show_bug.cgi?id=76276, I don't think that that one applies either, since it is for the XPS 13 which is much newer, and more over it should be fixed on 3.15-rc3.
So this likely is some regression in the ACPI code.
Hmm, Rex, can you try:
With both a working and a non working kernel ?
I don't have any backlight/acpi_video0 (on any kernel) afaict. Only these:
# ls /sys/class/backlight/
(In reply to Rex Dieter from comment #9)
> I don't have any backlight/acpi_video0 (on any kernel) afaict. Only these:
> # ls /sys/class/backlight/
> dell_backlight intel_backlight
Hmm, ok, well that atleast rules out some changes of mine which went into 3.14, as those only affect the acpi_video backlight code. the dell_laptop driver seems pretty much unchanged between 3.13 and 3.14. So I'm fraid this is going to be tricky to debug, I think the best way to pinpoint the cause of this is doing a git-bisect. I know that is a lot of work, but I cannot come up with anything else.
I also confirm this issue on a Dell Latitude D630. Starts very dim and then the brightness hotkeys are completely non-functional.
/sys/class/backlight/dell_backlight/brightness exists and seems to have the value for brightness.
Upgraded to kernel-3.14.3-200.fc20.x86_64 this morning and backlighting on the Dell Latitude D630 is still broken. I see in the changelog that the backlighting for quite a few laptops was fixed.
Any troubleshooting info needed for this or is the backlighting code in the kernel getting overhauled and it is just a matter of time before the regressions are reversed?
(In reply to Scott Dowdle from comment #13)
> Upgraded to kernel-3.14.3-200.fc20.x86_64 this morning and backlighting on
> the Dell Latitude D630 is still broken. I see in the changelog that the
> backlighting for quite a few laptops was fixed.
> Any troubleshooting info needed for this or is the backlighting code in the
> kernel getting overhauled and it is just a matter of time before the
> regressions are reversed?
I'm afraid that all the recent fixes are unrelated to the D630, they all apply to the acpi_video driver, which is used on newer model laptops. It seems that at the same time that we've gotten our selves a whole lot of acpi_video issues, the Dell Latitude D630 has regressed too, but I believe this to be unrelated.
I'm afraid that the best way I can come up with to work towards a fix for this is doing a git bisect, which I do realize is quite a bit of work. Still that is the best bet I can give you to get to the bottom of this.
I confirm this on my Dell Latitude D630. In the past, (before installing today's updates), upon boot, my screen was almost too dim to read. I could use the GUI to adjust it, but as of today, I could no longer adjust the screen brightness. The function keys do not work either. When using the GUI, the slider does move, but the screen remains at its minimum brightness level. Doing any kind of CLI work is very difficult because it is almost impossible to read (at least with 57-year-old eyes). Have not attempted to use an external mouse, but doubt that will be a fix.
Confirming same issue on Dell Latitude D630, fresh install of f20. This appears to be universal to all D630 models running the latest kernel.
I'll try to get my hands an a D630 and see what I can do in the mean time, if someone could git bisect this it would be great. Otherwise I suggest staying with an older kernel for now.
Hans, where do you live? I have one with this issue that I could send you. I live in Wisconsin, in the great lakes region of the United States.
I can reproduce this on a Dell Latitude D830 (with intel only graphics).
The root cause here is that /sys/class/backlight/intel_backlight/brigtness contains 255000 where the max is 255255 which is as bright as usual.
So for a quick and dirty workaround echo "255255" > /sys/class/backlight/intel_backlight/brightness does work temporarily.
(which I already described here https://srctwig.com/blog/dell-latitude-brightness-fixup-hack )
$ uname -r
I bisected the kernel, and found that the following commit causes the issue:
b35684b8fa94e04f55fd38bf672b737741d2f9e2 is the first bad commit
Author: Jani Nikula <firstname.lastname@example.org>
Date: Thu Nov 14 12:13:41 2013 +0200
drm/i915: do full backlight setup at enable time
We should now have all the information we need to do a full
initialization of the backlight registers.
v2: Keep QUIRK_NO_PCH_PWM_ENABLE for now (Imre).
Signed-off-by: Jani Nikula <email@example.com>
Reviewed-by: Imre Deak <firstname.lastname@example.org>
Signed-off-by: Daniel Vetter <email@example.com>
:040000 040000 0aae5515ca62ff1bfd2e1c2769e30c58b016ffeb 01c2f8cd145f8cf29730908d52e7e89b787a059e M drivers
First of all many thanks for doing the bisect. Given the result it is probably bet if you send a mail to
firstname.lastname@example.org about this, that will get you into direct contact with the intel drv authors.
Hans, Isn't that the commit that has a revert queued for 3.14.5?
(In reply to Josh Boyer from comment #22)
> Hans, Isn't that the commit that has a revert queued for 3.14.5?
No the partial revert is only for re-adding the QUIRK_NO_PCH_PWM_ENABLE which was dropped in earlier versions: http://patchwork.freedesktop.org/patch/25087/
Would be good to add this to the Fedora kernels for XPS users though (or just wait for it to trickle down).
Thanks to Marc Milgram putting a ton of time into bisecting this, this now has a fix upstream (with a CC for stable).
Given that this is a rather severe regression, I believe that it would be good to add the fix to the Fedora kernels ASAP, rather then waiting for it to trickle down through stable. I'll attach the patch here.
Josh, can you take care of adding this patch to the Fedora kernels please ?
Created attachment 907692 [details]
[PATCH] drm_i915: set backlight duty cycle after backlight enable for gen4
kernel-3.14.7-200.fc20 has been submitted as an update for Fedora 20.
kernel-3.14.7-100.fc19 has been submitted as an update for Fedora 19.
Many thanks for everyone's heroic efforts. I can confirm kernel-3.14.7-200.fc20 is golden for my dell latitude d630 (will karma++ once it hits -testing)
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.14.7-200.fc20'
as soon as you are able to, then reboot.
Please go to the following url:
then log in and leave karma (feedback).
(In reply to Fedora Update System from comment #31)
> Package kernel-3.14.7-200.fc20:
> * should fix your issue,
> * was pushed to the Fedora 20 testing repository,
> * should be available at your local mirror within two days.
> Update it with:
> # su -c 'yum update --enablerepo=updates-testing kernel-3.14.7-200.fc20'
> as soon as you are able to, then reboot.
> Please go to the following url:
> then log in and leave karma (feedback).
Confirming fix on my D630 with the kernel update from testing repository (see above). All looks good after about 30 minutes up-time (previously screen would have woefully dimmed by this point). Many thanks to everyone for the efforts to correct this issue.
Add me to the list of people the 3.14.7-200 build works for. Yeah. Thanks!
Now if all other testing shows no additional issues... and the package gets pushed to updates this bug can be closed. Right after I post this I'm heading over to give it some karma.
kernel-3.14.7-200.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Thanks! Works for me too.
System: Dell Inspiron 1420
Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller, rev 0c
PCI IDs 8086:2a02 and 8086:2a03.
kernel-3.14.7-100.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.