Created attachment 87520 [details] dmesg output Bug description: I have a laptop, model Acer Aspire 5750G, connected to an external screen via the VGA port and I setup my desktop manager (XFCE v4.10.1) to only use the external screen. So the problem I have is when I want to activate the laptop screen it doesn't work. It doesn't turn on. As a workaround, I have to change the resolution two times in the laptop screen and then it works. So basically I have these commands in a script to do it with a keyboard shortcut: 1. xrandr --output HDMI1 --off --output LVDS1 --mode 1024x768 --pos 1280x0 --rotate normal --output DP1 --off --output VGA1 --mode 1280x1024 --pos 0x0 --rotate normal 2. xrandr --output HDMI1 --off --output LVDS1 --mode 1366x768 --pos 1280x0 --rotate normal --output DP1 --off --output VGA1 --mode 1280x1024 --pos 0x0 --rotate normal Only at 2nd step, the laptop screen turns on. If I just repeat the first step, it remains off. After the workaround, I can use my desktop manager tools to switch screens instead of this script. The problem only happens as long as I boot the system with the external screen connected. With it disconnected and after xorg is started, if I connect it, I can turn on/off screens fine. System environment: -- chipset: Intel(R) HD Graphics 3000 -- system architecture: 64-bit -- xf86-video-intel: 2.21.15 -- xserver: 1.14.3 -- mesa: 9.2.1 -- libdrm: 2.4.46 -- kernel: 3.11.4 -- Linux distribution: Archlinux -- Machine or mobo model: Acer Aspire 5750G BIOS Information Vendor: Acer Version: V1.21 Release Date: 08/09/2012 BIOS Revision: 21.240 Base Board Information Manufacturer: Acer Product Name: JE50_HR -- Display connector: VGA / LVDS Reproducing steps: 1. Connect an external screen to VGA port 2. Setup the desktop manager to only use the external screen 3. Reboot. 2. Try to turn on the laptop screen using xrandr. Additional info: 1. This situation happens since a long time and several versions of the intel driver, maybe from the very beginning I purchased this laptop, I don't remember well. 2. I ran the intel reg dumper after each step above and at first boot, just in case, it helps you better.
Created attachment 87521 [details] Xorg log
Created attachment 87522 [details] xrandr --verbose output
Created attachment 87523 [details] VBios dump
Created attachment 87524 [details] Intel reg dump at first boot
Created attachment 87525 [details] Intel reg dump after running the first xrandr command
Created attachment 87526 [details] Intel reg dumper after running the second xrandr command
The dmesg doesn't look complete. We have the boot, X starting and then the DE switching off the LVDS, but I don't see the subsequent modesets for the LVDS.
Created attachment 87549 [details] dmesg output after the two xrandr commands
After the first modeset to switch on the LVDS, the backlight is set to 0. Can you please check what xrandr --verbose --output LVDS1 reports after that initial modeset (and the LVDS is still blank) and then try playing with xrandr --output LVDS1 --set Backlight <x> and directly setting /sys/class/backlight/*
Created attachment 87552 [details] xrandr --verbose output after first xrandr command
What also would be useful would be an Xorg.0.log of the modesetting sequence from xf86-video-intel compiled with --enable-debug=full.
It is the backlight. After the first modeset, I can increase it with both, your xrandr command or directly to /sys/class/backlight/intel_backlight/brightness and see that actually the first modeset activated the screen but with the backlight at 0.
I've tweaked the debug slightly in the ddx, and made one more path explicit. If you can compile from xf86-video-intel.git with --enable-debug=full, that will be extremely informative. commit 951f969fa63defbe7cfa52ca97c8985b157bbed0 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Oct 13 12:47:20 2013 +0100 sna: Update DPMS on attached outputs before disabling the CRTC
(In reply to comment #13) > I've tweaked the debug slightly in the ddx, and made one more path explicit. > If you can compile from xf86-video-intel.git with --enable-debug=full, that > will be extremely informative. > > commit 951f969fa63defbe7cfa52ca97c8985b157bbed0 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Sun Oct 13 12:47:20 2013 +0100 > > sna: Update DPMS on attached outputs before disabling the CRTC I tried to compile the driver from git, but I don't think it's currently compilable. Using: ./autogen.sh --prefix=/usr \ --enable-dri \ --with-default-accel=sna \ --enable-debug=full make I get this: http://sprunge.us/WKiS
Gah. Sorry about that, fixed.
Created attachment 87566 [details] Xorg log with driver from git and its full debug - compressed with xz utils This log size is 30 megabytes so I compressed it with xz utils: http://tukaani.org/xz/ Install the corresponding package from your distribution and run: xz -d Xorg.0.log.xz I think it's possible to use 7-zip ( http://www.7-zip.org/ ) too for decompressing it.
It is your desktop environment that sets the backlight to 0 (using the backlight property on LVDS1). It is actually a bug that the kernel in the end overrides it...
Ok, I'm going to change my desktop manager, maybe the next week, from XFCE to maybe GNOME or KDE, and check if that fixes the problem. But... what's the next step? Is there anything I should do?
The only thing I can think of is that the ddx sets a value if we try to enable an output with a zero backlight. Will think about that some more.
(In reply to comment #19) > The only thing I can think of is that the ddx sets a value if we try to > enable an output with a zero backlight. Will think about that some more. Ok. Well, I installed KDE finally. It behaves the same way as XFCE. And then I closed the KDE session and started XFCE. XFCE turned off the laptop screen, keeping the external screen on as it should be. And again, the same behaviour after trying to activate the laptop screen. By the way, Chris, thanks for your support.
The issue with interpreting 0 as off in the ddx is that it is only definitely true for intel_backlight. For an ACPI backlight, 0 means the low brightness as defined by the firmware which may be a valid setting that the user requests. My only suggestion is to shout at whatever userspace is setting the backlight to 0 after turning off the display and asking them whether they are serious?
(In reply to comment #21) > The issue with interpreting 0 as off in the ddx is that it is only > definitely true for intel_backlight. For an ACPI backlight, 0 means the low > brightness as defined by the firmware which may be a valid setting that the > user requests. My only suggestion is to shout at whatever userspace is > setting the backlight to 0 after turning off the display and asking them > whether they are serious? I made another test. I stopped the desktop manager (lightdm) and run Xorg with a simple startx, so no desktop environment, just plain xorg. It started with both screens on. I used xrandr to turn off the laptop screen (--output LVDS1 --off) and kept on the external screen. Xrandr --verbose showed me the backlight properties set to 0. And then I run the first xrandr command from the very beginning of this entire thread... and again, the laptop screen doesn't turn on: the backlight properties are still 0. So with no desktop environment, just plain xorg, the problem is still there.
Hmm. Can you attach the debug Xorg.0.log for the bare X session? That sounds genuinely surprising.
Strange as it sounds, I cannot reproduce the problem with startx anymore. It failed at least two times at the beginning but I wasn't using the driver with full debug. I have a log without the problem, using startx and after a powercycle ... but unless you think it will shed some light, I'm not going to upload it.
(In reply to comment #24) > Strange as it sounds, I cannot reproduce the problem with startx anymore. It > failed at least two times at the beginning but I wasn't using the driver > with full debug. I have a log without the problem, using startx and after a > powercycle ... but unless you think it will shed some light, I'm not going > to upload it. No, I don't think it will help. Please do keep on poking around though, it seems like we have a fun little mystery developing.
Created attachment 87661 [details] Xorg log with startx, driver from git, full debug Finally I've found how to reproduce the problem everytime with bare Xorg... It turns out that --xrandr verbose is the culprit. When I don't run it, the laptop screen turns on just fine. The log was made with just these two commands: 1. xrandr --output LVDS1 --off 2. xrandr --verbose
RRChangeOutputProperty strikes again. HoHum.
The bug with bare X should be fixed by commit 41b6b792d8e9c84c0a71a4bd7600e1c42e86b5bd Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Oct 15 11:23:19 2013 +0100 sna: Preserve the user backlight value for get_property calls When querying the current backlight value, be sure not to overwrite the last user set value by the call to RRChangeOutputProperty. RRChangeOutputProperty calls into set_backlight_property, tricking us into believing that the user has set a new backlight value. The result is that we end up believing that the user chooses a 0 backlight if she should happen to query the property whilst the output is disabled. Reported-by: reztho@archlinux.us Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70406 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> and it is credible that this also fixes the rogue zero backlight with desktop environments as well.
Thanks, Chris, I learnt a lot in the process. I can confirm this fixes the problem with bare X, but unfortunately I cannot for XFCE. Latest patches in git break it and I'm thrown to my display manager, LightDM, everytime I start XFCE. I'll wait to the next stable release of the driver. Thanks again.
commit ad5b6a303b44ba0ae9f8df075a7efec92a2e41ff Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Oct 15 12:48:27 2013 +0100 Revert "sna: Preserve the user backlight value for get_property calls" This reverts commit 41b6b792d8e9c84c0a71a4bd7600e1c42e86b5bd in favour of the better fix to not ask RRChangeOutputProperty to reset the known hardware values. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> commit e76b08cad2770015346fd4cd757de3bb3b6ff37c Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Oct 15 12:46:09 2013 +0100 sna: Disable updating properties upon reading their values When we assign the hardware values to the output properties, we do not need to process the set_property callback to write those values back to hardware. This callback is triggered by the pending update flag passed to RRChangeOutputProperty. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70406 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(In reply to comment #29) > Thanks, Chris, I learnt a lot in the process. > > I can confirm this fixes the problem with bare X, but unfortunately I cannot > for XFCE. Latest patches in git break it and I'm thrown to my display > manager, LightDM, everytime I start XFCE. > > I'll wait to the next stable release of the driver. Thanks again. Still running with assertions enabled? I've a crusade at the moment to find the cause of a nasty assertion failure and so enabled a bunch of asserts that I know should fail.
I compiled the latest git revision. Now I can use it with XFCE and I confirm you succesfully fixed the bug. Thanks.
(In reply to comment #32) > I compiled the latest git revision. Now I can use it with XFCE and I confirm > you succesfully fixed the bug. Thanks. I forgot to add that I compiled it without full debug, of course.
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.