Created attachment 87303 [details] xorg log This configuration was working fine on xorg 1.13/xf86-video-intel 2.99.901, but broke when I upgraded to 1.14.3/2.99.903. If you believe it'd be helpful, I could easily test other versions of xf86-video-intel, but switching back to xorg 1.13 may prove tricky. The issue is that when I start X, I have both LVDS1 and HDMI1 screens mirrored (as expected). xrandr reports the following: $ xrandr -q Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 32767 x 32767 LVDS1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 310mm x 174mm 1600x900 60.0 + 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm 1920x1200 60.0*+ 1920x1080 60.0 ... Note that there's no * next to the 1600x900 mode on LVDS1. (It is, however, displaying everything just fine.) When I then try to run xrandr --output HDMI1 --above LVDS1 it fails with a BadMatch (or BadValue) error (don't have the exact error handy, can provide if necessary). Running xrandr --output LVDS1 --auto restores the * next to the 1600x900 mode, and allows a subsequent --above command to work as well. Attached is my Xorg log. Note the following odd lines on init: [701508.168] (--) intel(0): Output LVDS1 using initial mode on pipe 0 [701508.168] (--) intel(0): Output HDMI1 using initial mode 1920x1200 on pipe 1 ... [701508.178] (II) intel(0): switch to mode 1600x900@60.0 on pipe 0 using LVDS1, position (0, 0), rotation normal [701508.199] (II) intel(0): switch to mode 1920x1200@60.0 on pipe 1 using HDMI1, position (0, 0), rotation normal I have an essentially empty xorg.conf (nothing specific to intel display/monitors).
You truncated the xrandr output, there is usually something anomalous at the end in these cases. Note the similarity with bug 70132.
Nothing funny in xrandr, here is the full output. (Except the VIRTUAL screen mode.) The bug does seem similar to #70132, and the version numbers seem to match up. I'll do a bisect between .901 and .903 if there are no obvious candidates. Note that I'm on 3.10.7 (+ gentoo patches, but they are usually not too invasive -- http://dev.gentoo.org/~mpagano/genpatches/patches-3.10-13.htm) for both the originally working and the broken setups. $ xrandr -q Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 32767 x 32767 LVDS1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 310mm x 174mm 1600x900 60.0 + 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm 1920x1200 60.0*+ 1920x1080 60.0 1920x1080i 60.1 1600x1200 60.0 1280x1024 75.0 60.0 1152x864 75.0 1280x720 60.0 1440x576i 50.1 1024x768 75.1 60.0 1440x480i 60.1 800x600 75.0 60.3 720x480 59.9 640x480 75.0 60.0 59.9 720x400 70.1 DP1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) HDMI3 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) (0x4c) 98.2MHz h: width 1600 start 1648 end 1680 total 1760 skew 0 clock 55.8KHz v: height 900 start 902 end 907 total 930 clock 60.0Hz
At the end there you have the unclaimed mode that is current for the LVDS1 - that shouldn't be there! Can you please attach xrandr --verbose?
Created attachment 87306 [details] xrandr-verbose.log The verbose xrandr log (xrandr --verbose).
Hmmm... I haven't been able to reproduce this with further tests. Even rebooting with the exact same kernel/driver versions, I now end up with a working configuration. Either triggering this requires a more specific set of circumstances, or it was a fluke of some sort. I'm going to close this for now, sorry for the trouble. If it happens again, I'll reopen.
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.