I just got a new Thin-ITX board (Asus H81T) with a Core i3-4170, and I get an annoying problem: I have a single monitor connected to this machine, using the DVI connection, yet X11 thinks there are two monitors: % xrandr Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 8192 x 8192 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) HDMI2 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 546mm x 352mm 1920x1200 59.95*+ 1600x1200 60.00 1680x1050 59.88 1280x1024 75.02 60.02 1440x900 59.90 1280x960 60.00 1152x864 75.00 1024x768 75.08 70.07 60.00 832x624 74.55 800x600 72.19 75.00 60.32 56.25 640x480 75.00 72.81 66.67 60.00 720x400 70.08 DP1 connected (normal left inverted right x axis y axis) 1024x768 60.00 800x600 60.32 56.25 848x480 60.00 640x480 59.94 HDMI3 disconnected (normal left inverted right x axis y axis) % This is the output after I manually turned the DP1 display off. In the BIOS I'm offered some options about the internal LVDS connection, and the above output is what I get when this option says "disabled". If I enable this option, then I don't get this DP1 output but get an eDP1 output instead, with the same problem except made worse because this eDP1 output is then marked as "primary" which forces me to do all kinds of gymnastics in order to actually get to see the login screen. How can I get rid of this "phantom" display? Also, FWIW, I get the impression that this also affects the Linux console, since it doesn't use up all my monitor (I'd estimate that it only uses the 1024x768 top-left portion of it).
Try adding video=DP-1:d to your commandline, or echo off | sudo tee /sys/class/drm/card0-DP-1/status
"video=DP-1:d" did the trick, thank you very much! Does that mean that it's fundamentally a bug in my motherboard ('s BIOS)?
Not really, something is very odd in the detection phase. If you remove the video= parameter and replace it with drm.debug=6 then please attach the dmesg from boot, we may be able to identify a problem in our code.
Created attachment 119203 [details] dmesg log with drm.debug=6 Here's the dmesg output from boot with drm.debug=6 and without any video=... parameter.
(In reply to monnier from comment #4) > Created attachment 119203 [details] > dmesg log with drm.debug=6 > > Here's the dmesg output from boot with drm.debug=6 and without any video=... > parameter. So there's definitely a DP device of some sort attached to the port since DPCD works. The EDID read doesn't seem to go too well though due to aux defers. Can you repeat the test with kernel version 4.3+, and attach the new log (with debugs enabled)?
Timeout, closing.
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.