Bug 90534 - integrated LVDS displays stays dark (firmware-linux-nonfree-0.43)
Summary: integrated LVDS displays stays dark (firmware-linux-nonfree-0.43)
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2015-05-20 11:11 UTC by Elmar Stellnberger
Modified: 2015-11-27 12:17 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Xorg.0.log -logverbose 8 (59.78 KB, text/plain)
2015-05-20 11:11 UTC, Elmar Stellnberger
no flags Details
xorg.conf in use (11.13 KB, text/plain)
2015-05-20 11:12 UTC, Elmar Stellnberger
no flags Details
output of xrandr (1.20 KB, text/plain)
2015-05-20 11:12 UTC, Elmar Stellnberger
no flags Details
/proc/cmdline (217 bytes, text/plain)
2015-05-20 11:25 UTC, Elmar Stellnberger
no flags Details
dmesg (71.27 KB, text/plain)
2015-05-21 09:52 UTC, Elmar Stellnberger
no flags Details

Description Elmar Stellnberger 2015-05-20 11:11:15 UTC
After upgrading to Xorg 1.16.4 my integrated LVDS display stays dark though it is shown by xrandr as active and can be configured by xrandr. It was known to work with Debian oldstable (likely 1:7.7+3~deb7u1; do not have that installation any more). Using firmware-linux-nonfree-0.43; related bugs: Bug 90475, Bug 90474.

Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 8192 x 8192
LVDS connected 1920x1200+0+0 (normal left inverted right x axis y axis) 367mm x 230mm
   1920x1200     59.95*+
DIN disconnected (normal left inverted right x axis y axis)
HDMI-0 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 550mm x 344mm
   1920x1200     59.95*+
VGA-0 disconnected (normal left inverted right x axis y axis)
Comment 1 Elmar Stellnberger 2015-05-20 11:11:56 UTC
Created attachment 115916 [details]
Xorg.0.log -logverbose 8
Comment 2 Elmar Stellnberger 2015-05-20 11:12:14 UTC
Created attachment 115917 [details]
xorg.conf in use
Comment 3 Elmar Stellnberger 2015-05-20 11:12:31 UTC
Created attachment 115918 [details]
output of xrandr
Comment 4 Elmar Stellnberger 2015-05-20 11:25:18 UTC
Created attachment 115922 [details]
Comment 5 Alex Deucher 2015-05-20 15:42:28 UTC
Does booting with radeon.backlight=0 on the kernel command line in grub help?
Comment 6 Elmar Stellnberger 2015-05-20 16:19:13 UTC
radeon.backlight=0 does not seem to make a difference (LVDS display stays black after xrandr config, mouse can be moved into black area disappearing there). The LVDS had to be configured manually now in order to show a * next to 1920x1200 though (not sure if this is a difference).
Comment 7 Alex Deucher 2015-05-20 16:49:29 UTC
Does it work correctly if you remove your xorg.conf and the video and uvesa options from your kernel command line?
Comment 8 Elmar Stellnberger 2015-05-20 18:55:40 UTC
No, that does not help (same symptoms as for comment #6). Note also that the LVDS is enabled before and after starting the X-server when I boot without firmware-linux-nonfree while it gets disabled on boot as soon as I install this package (most likely on load of the kernel modules).
Comment 9 Alex Deucher 2015-05-20 20:28:55 UTC
Please attach your dmesg output.
Comment 10 Elmar Stellnberger 2015-05-21 09:52:16 UTC
Created attachment 115944 [details]

Here comes the dmesg (same parameters as before). Note that I have 1920x1200 also on the console vt01-vt05 so that it apparently ignores the uvesafb.mode_option=1600x1200-24@60,mtrr:3,ywrap option (some elder kernels made use of it; I considered it somewhat better readable to have 1600x1200 on the console because then the font size gets larger.).
Comment 11 Elmar Stellnberger 2015-05-30 16:12:05 UTC
This is a very painful bug as notebooks tend to only have one monitor which stays dark here; - and it is a regression. Please, please try to do something about it!!
Comment 12 Alex Deucher 2015-06-01 13:53:26 UTC
Can you bisect?
Comment 13 Elmar Stellnberger 2015-06-01 13:58:27 UTC
Oh, no! First there are several years between those two version of Xorg and secondly I believe the problem is thightly entangled with the introduction/usage of the new proprietary radeon firmware. I would expect that at the certain point in time where the radeon frimware was introduced to be used by radeon that from there on it does not work. I would be ready to test it if you can give me a git-commit# or tag from the last version without it and the first one with it. This could infringe the testing problem enormously.
Comment 14 Alex Deucher 2015-06-01 14:03:21 UTC
The firmware has always been a requirement and is not involved in modesetting at all.
Comment 15 Elmar Stellnberger 2015-06-01 14:15:35 UTC
Formerly this firmware was OSS and as far as I can remember it had always been working while the firmware had been OSS. Alex, it would be very nice if you could give me a hint from where on I should start to test. From which point in time on was there a non-OSS firmware in use for radeon? Note that it still works without this firmware. Maybe I do not need to bisect Xorg but very likely just the firmware.
Comment 16 Christian König 2015-06-01 14:24:19 UTC
(In reply to Elmar Stellnberger from comment #15)
> Formerly this firmware was OSS and as far as I can remember it had always
> been working while the firmware had been OSS.

The firmware for radeon has always been proprietary, but you only need it for acceleration.

Pure modesetting should still work without. The problem is that we rarely test without the firmware, so this breaks from time to time.

Since your bug sounds like an external display still works I would expect that acceleration actually works perfectly fine. So the firmware most likely isn't the cause of the problem.

I would rather guess that it is an issue with the newer kernel. Please try downgrading that one first and see if you can find a working version. Then bisect from those two points in time.
Comment 17 Elmar Stellnberger 2015-06-01 14:27:38 UTC
So bisect the kernel and leave Xorg in peace?
Comment 18 Christian König 2015-06-01 14:28:38 UTC
(In reply to Elmar Stellnberger from comment #17)
> So bisect the kernel and leave Xorg in peace?

Yes, exactly. Any idea what kernel version did you used before?
Comment 19 Alex Deucher 2015-06-01 14:29:03 UTC
It's always been the same firmware.  firmware is firmware.  Different distros have changed their packaging polices with respect to firmware.  That might be the case for you (e.g., distro used to just include the firmware with the kernel and now ships it as a separate package).  As to narrowing it down, I'd suggest trying interim kernels between the last know good one and most recent one you've tried to see of you can narrow down when it broke.  E.g., if kernel 3.14 worked and 3.15 is bad you know the regression happened in the 3.15 kernel cycle.
Comment 20 Elmar Stellnberger 2015-11-27 12:17:16 UTC
Unfortunately the notebook where this issue was observed is already broken (does neither boot nor do I get into the BIOS) ...

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.