Created attachment 135539 [details] Regdump of the video card state when not working (in 2 display mode) This is a DELL Precision 3520 (also containing an nvidia card). This issue has existed for a number of kernel releases, including at least 4.13 and 4.14. I'm using the latest intel driver available in Gentoo, but this doesn't seem the problem either. This is on xorg-server 1.19.5 xrandr 1.5.0, libXrandr 1.5.1, randrproto 1.5.0 (it seems to be a modesetting issue either in this driver or the kernel) The problem is that the display starts in 3 display configuration: Laptop screen (eDP1), HDMI screen (HDMI1) and VGA screen (DP2). For usability reasons I want to sometimes turn of the laptop screen and I've created a little hook that calls xrandr to do so when the lid is closed. The problem is that when doing so, everything appears to work correctly, except that the HDMI output will not be correct (the display goes into sleep mode - I don't have the equipment to check the signal - but this is on multiple displays by different vendors). It is possible to make the configuration work, but it normally involves a bit of fiddling about with enabling and disabling screens. Even then there seems to be some apparently random state involved. Initial state (quite reliably reproducable from boot, but not always later): - All screens on in extended configuration (from left to right EDP1, HDMI1, DP2) - Execute "xrandr --output EDP1 --off --output HDMI1 --preferred --left-of DP2 --output DP2 --preferred" - KDE thinks the display is enabled and the virtual desktop has the correct size (the mouse also uses that display size). The display goes into poweroff state.
Created attachment 135540 [details] Regdump of the video card state when working correctly (in 2 display mode)
Created attachment 135541 [details] Xrandr --verbose output in non-working state (only difference is timestamps)
I've just tried on drm-tip. The issue is still present there (now without the nvidia module being built, so no tainted kernel). A workaround (that currently works) from the broken state (laptop screen off, others on, but hdmi not displaying): xrandr --output eDP1 --off --output HDMI1 --off --output DP2 --auto xrandr --output HDMI1 --auto --output DP2 --auto xrandr --output HDMI1 --left-of DP2
Can you please attach your Xorg.log and dmesg with drm.debug=6 on the cmdline?
Created attachment 135546 [details] Initial (working configuration) xorg.0.log
Created attachment 135547 [details] Xorg log after "xrandr --output eDP1 --off" This is just after "--output eDP1 --off", it doesn't seem to make a difference how I configure though.
Created attachment 135548 [details] dmesg after the screen has turned off (broken)
Created attachment 135549 [details] dmesg after recovery. Recovery steps were: xrandr --output HDMI1 --off xrandr --output HDMI1 --auto --output DP2 --auto xrandr --output HDMI1 --left-of DP2
Created attachment 135550 [details] Xorg log after the screen has come on again.
It appears that the bug is timing related. When the (workaround) commands are run immediately (in one script) they will not work. If separated by a sleep of sufficient length (sleep 1 doesn't work) they do.
I found another workaround that seems much more stable. If I first place the laptop screen to the right of the VGA screen it will work correctly. The physical setup: LAPTOP(eDP1) - HDMI1 - VGA(DP2) Reconfigured 3screen: HDMI1 - VGA(DP2) - LAPTOP (eDP1) Then 2screen: HDMI1 - VGA(DP2) / Laptop(off - eDP1)
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Closing, please re-open is issue still exists.
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.