Any kernel >= 3.10 results in the display ending up extremely dark and brightness cannot be change using the keys when booting using UEFI. After doing some research it seems there are various backlight issues but I'm not sure which issue exactly I'm dealing with here and what to do about it. Right now I cannot update my kernel or upgrade my distribution because of this.
Please try to adjust the brightness directly through the sysfs interfaces in /sys/class/brightness/* Please do this on both older (working) kernels and newer broken releases and list for each backlight what happens. Also please retest with latest 3.13-rc kernels, there's tons of backlight adjustments. Finally please attach the output of dmesg and lspci -nn.
You specifically mention UEFI here - does it work in CSM/legacy mode? Please make sure you enable drm.debug=0xe module parameter when running 3.13-rc for attaching the dmesg. CC Aaron.
In CSM/Legacy mode the brightness is correct although I notice two things: 1. When I turn the brightness all the way down the display is brighter than when I boot without CSM active. 2. acpi_video0/actual_brightness reflects the display brightness accurately (0-100) when I change the brightness using the keys but intel_backlight/actual_brightness is always 4882 no matter how I adjust the brightness using the keys.
Created attachment 121551 [details] backlight behaviour using 3.9.9 kernel
Created attachment 121561 [details] backlight behaviour using 3.13 kernel
Created attachment 121571 [details] lspci -nn output
Created attachment 121581 [details] dmesg output with kernel parameter drm.debug=0xe
Please attach acpidump: # acpidump > acpidump.txt From the two logs in comment #4 and #5, it seems the backlight control is broken in v3.13 while works well in v3.9. BTW, I suppose the two tests are done with UEFI mode?
Created attachment 121721 [details] acpidump Yes, everything is using UEFI except for the observations in comment #3.
From the acpidump, the ACPI control method to set brightness will make use of IGD when CSMF is 0, and will directly write an IO port when CSMF is 1. I guess CSMF is a reflection of whether CSM mode is in use. Sounds like something is broken in i915 to set brightness on v3.13 kernels.
(In reply to Dennis Jacobfeuerborn from comment #3) > 2. acpi_video0/actual_brightness reflects the display brightness accurately > (0-100) when I change the brightness using the keys but > intel_backlight/actual_brightness is always 4882 no matter how I adjust the > brightness using the keys. Can you please try out what happens when you set the brightness through the sysfs interface? Use the "brightness" file for that.
Going back to CSM mode and testing: Echoing values 0-100 into /sys/class/backlight/acpi_video0/brightness results in the display fading to that brightness level within 2-3 seconds. Echoing values 0-4882 into /sys/class/backlight/intel_backlight/brightness results in no changes to the brightness of the display.
(In reply to Dennis Jacobfeuerborn from comment #12) > Going back to CSM mode and testing: > > Echoing values 0-100 into /sys/class/backlight/acpi_video0/brightness > results in the display fading to that brightness level within 2-3 seconds. > > Echoing values 0-4882 into /sys/class/backlight/intel_backlight/brightness > results in no changes to the brightness of the display. And for UEFI both are broken? Just from this is sounds like the native i915 pwm isn't wired up to anything at all ...
Yes, in UEFI mode nothing happens when i echo values into the "brightness" files though the respective "actual_brightness" shows the correct value afterwards. What's curious is about this is that this is one of those "Sputnik" Laptops that were specifically designed to work with Linux and can be ordered with Ubuntu pre-installed from Dell. Since they are very popular I can't be the only one seeing this. I've got the version with Windows pre-installed though and added Fedora in a dual-boot configuration.
(In reply to Dennis Jacobfeuerborn from comment #14) > What's curious is about this is that this is one of those "Sputnik" Laptops > that were specifically designed to work with Linux and can be ordered with > Ubuntu pre-installed from Dell. Since they are very popular I can't be the > only one seeing this. I've got the version with Windows pre-installed though > and added Fedora in a dual-boot configuration. Sadly, there's no guarantee for anything other than the Ubuntu pre-install image; even a stock Ubuntu release let alone an upstream kernel might not work. http://www.ubuntu.com/certification/hardware/201309-14237/
(In reply to Dennis Jacobfeuerborn from comment #14) > Yes, in UEFI mode nothing happens when i echo values into the "brightness" > files though the respective "actual_brightness" shows the correct value > afterwards. > > What's curious is about this is that this is one of those "Sputnik" Laptops > that were specifically designed to work with Linux and can be ordered with > Ubuntu pre-installed from Dell. Since they are very popular I can't be the > only one seeing this. I've got the version with Windows pre-installed though > and added Fedora in a dual-boot configuration. You are not the only one seeing this. I have the same system with the same issues (Gentoo Mgmt). I have followed this thread and tried all recommendations with the same results. I am currently running 3.13.0-rc7 (UEFI boot). I see the "black screen of death" when booted in 3.13.0-rc8 (same .config). I really have no idea how to help fix this, I just wanted to confirm others are seeing this also.
If backlight problem only happens on >=v3.10 kernels under UEFI mode, doing a bisect probably is a good idea.
Looks like this broke between these versions: good = kernel-3.10.4-300.fc19.x86_64 Tue, 30 Jul 2013 11:17:10 UTC bad = kernel-3.10.5-201.fc19.x86_64 Wed, 07 Aug 2013 15:07:52 UTC In the changelog for 3.10.5 I found the following commit: ====================================================================== commit f12155987bdc8d175b41b2fcbd88e8788c1af92d Author: Kamal Mostafa <kamal@canonical.com> Date: Fri Jul 19 15:02:01 2013 -0700 drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight commit e85843bec6c2ea7c10ec61238396891cc2b753a9 upstream. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941 BugLink: https://bugs.launchpad.net/bugs/1163720 BugLink: https://bugs.launchpad.net/bugs/1162026 Some machines suffer from non-functional backlight controls if BLM_PCH_PWM_ENABLE is set, so provide a quirk to avoid doing so. Apply this quirk to Dell XPS 13 models. Tested-by: Eric Griffith <EGriffith92@gmail.com> Tested-by: Kent Baxley <kent.baxley@canonical.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> ======================================================================
Please try the drm-intel-nightly branch of [1]; we've rewritten the backlight code entirely. [1] http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-nightly
After building a kernel from the drm-nightly-branch i can confirm that with that kernel things seem to work as expected. There is one minor difference though: The max_backlight value is 4882 and under the 3.9.9 kernel I can use the keys to increase brightness until it reaches 4882. On the drm-intel-nightly kernel however the actual brightness only goes up to 4845 using the keys but I can echo 4882 into the brightness file and actual_brightness will reflect that. Since the brightness is only changed in increments it seems under 3.9.9 some sort of code like "if (brightness <= max_brightness_inc) ..." is used but in the new code the <= changed to < maybe which would only allow you to reach max_brightness_inc-1?
(In reply to Dennis Jacobfeuerborn from comment #20) > After building a kernel from the drm-nightly-branch i can confirm that with > that kernel things seem to work as expected. Queued for 3.14. > There is one minor difference though: The max_backlight value is 4882 and > under the 3.9.9 kernel I can use the keys to increase brightness until it > reaches 4882. On the drm-intel-nightly kernel however the actual brightness > only goes up to 4845 using the keys but I can echo 4882 into the brightness > file and actual_brightness will reflect that. Since the brightness is only > changed in increments it seems under 3.9.9 some sort of code like "if > (brightness <= max_brightness_inc) ..." is used but in the new code the <= > changed to < maybe which would only allow you to reach max_brightness_inc-1? Our driver does not have any code handling the keys or the increments.
In case video module played a role in key handling, you can disable it by: # echo 0 > /sys/module/video/parameters/brightness_switch_enabled Other than it, the steps should be decided by user space tool.