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. >xrandr 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)
Created attachment 115916 [details] Xorg.0.log -logverbose 8
Created attachment 115917 [details] xorg.conf in use
Created attachment 115918 [details] output of xrandr
Created attachment 115922 [details] /proc/cmdline
Does booting with radeon.backlight=0 on the kernel command line in grub help?
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).
Does it work correctly if you remove your xorg.conf and the video and uvesa options from your kernel command line?
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).
Please attach your dmesg output.
Created attachment 115944 [details] dmesg 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.).
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!!
Can you bisect?
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.
The firmware has always been a requirement and is not involved in modesetting at all.
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.
(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.
So bisect the kernel and leave Xorg in peace?
(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?
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.
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.