(discussion started on #xorg-devel on April 11th, providing more info now). My laptop (Dell Latitude D420) has the following board: 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) It is running Xserver 1.3-rc5 and the Intel driver rc4 (from Debian experimental) and works (almost) very well. When plugging an external LCD on the DVI output, I can get 1600x1200 fine. But I need to explicitly request this resolution in xrandr since I only get 1152x864 at startup. Note that the internal panel remains enabled (even if the panel is closed) and gets 1280x800 (its maximal resolution). IIRC, with the old driver (non modesettings) and Xserver 1.1, the LVDS panel would be disabled and I would get 1600x1200 automatically on TMDS. Here's what xrandr says now right after startup with TMDS plugged and LVDS closed but still enabled: Screen 0: minimum 320 x 200, current 1280 x 864, maximum 2048 x 2048 VGA disconnected (normal left inverted right) LVDS connected 1280x800+0+0 (normal left inverted right) 261mm x 163mm 1280x800 60.0*+ 60.0 1280x768 60.0 1024x768 60.0 800x600 60.3 640x480 59.9 TMDS-1 connected 1152x864+0+0 (normal left inverted right) 367mm x 275mm 1600x1200 60.0 + 59.9 1280x1024 75.0 59.9 1152x864 74.8* 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1 TV disconnected (normal left inverted right) I would like to get 1600x1200 automatically at startup on the TMDS, or at least find out why the driver chooses 1152x864. Note that when plugging a VGA display instead of DVI, both LVDS and VGA get 1280x800 at startup. Maybe because the driver thinks it's a good idea to start with the same resolution? But, then, since the TMDS panel I talk about above does not support 1280x800, why does the driver choose 1152x864? Because this resolution is the closest to 1280x800 that the TMDS supports? I will attach xorg.conf, Xorg.0.log with debug enabled and the complete output of xrandr. Brice
Created attachment 9576 [details] xorg.conf
Created attachment 9577 [details] Xorg.0.log with debug enabled, TMDS plugged in, LVDS closed but enabled
Created attachment 9578 [details] xrandr --verbose
Comment on attachment 9578 [details] xrandr --verbose oops, that was xrandr --verbose after doing xrandr --output TMDS --mode 1600x1200
Created attachment 9579 [details] xrandr --verbose with TMDS 1152x864
Interestingly, when both the VGA and TMDS-1 cables are connected to the external LCD display, I seem that I always get 1600x1200 at startup on TMDS-1. I'll attach the corresponding log below.
Created attachment 9912 [details] Log when both TMDS-1 and VGA are attached to the external display (note that I disconnected the VGA cable later after startup, as seen at the end of the log).
The monitor is a Dell UltraSharp 2007FP 20"
Instead of using xrandr/grandr after startup, I tried ModeLine+PreferredMode to force 1600x1200 on the TMDS directly, and for some reason, it fails. I tried this modeline generated by gtf Modeline "1600x1200_60.00" 160.96 1600 1704 1880 2160 1200 1201 1204 1242 -HSync +Vsync Option "PreferredMode" "1600x1200_60.00" and these ones from the log itself Modeline "1600x1200x60.0" 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync Option "PreferredMode" "1600x1200x60.0" Modeline "1600x1200x59.9" 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync Option "PreferredMode" "1600x1200x59.9" They all appear to be accepted, but it keeps using 1152x864 by default. Of course, using xrandr/grandr later makes it possible to switch to any of these modelines. Kind of strange...
This is actually the way the X server is intended to work (for better or worse), it'll try to pick the closest, smaller mode on the external output. Of course, you can change the behavior by configuring your monitors specifically in xorg.conf (don't forget to increase your Virtual size). Jesse
> This is actually the way the X server is intended to work (for better or > worse), it'll try to pick the closest, smaller mode on the external output. Ok, that explains why the default config gets this behavior. > Of course, you can change the behavior by configuring your monitors > specifically in xorg.conf (don't forget to increase your Virtual size). If you look at comment #9, you'll see that it doesn't work. I have Virtual 2048 2048, Monitor-TMDS-1 and ModeLine + Preferred pointing to 1600x1200. But, I still get 1152x864 on my TMDS. The log says that the 1600x1200 ModeLines are accepted (I see them in xrandr and I can switch to them later). Surprisingly, it seems to work fine for VGA (Option Monitor-VGA + ModeLine + PreferredMode gives me 1600x1200).on a different monitor here. I won't have access to my Dell monitor before monday, it has both VGA and DVI ports, I'll see whether VGA works there too and repost my current config and some logs so that you can compare TMDS and VGA behaviors.
< keithp> bgoglin: that's a different bug -- PreferredMode in the config is the same as PreferredMode in the EDID, and the LVDS PreferredMode overrides the TMDS PreferredMode < keithp> PreferredModes are executed in output order, so VGA will override LVDS, but LVDS will override TMDS < keithp> I thought i had fixed things so that the PreferredMode option would override a PreferredMode from EDID (or the LVDS BIOS panel size) < keithp> If present, that fix would only be on server master though < bgoglin> keithp: so I have no way to workaround this in the config? < keithp> nope < keithp> *that* is a bug I don't think I'll be able to test xserver master on this machine soon...
Created attachment 11347 [details] [review] Prefers user-specified PreferredMode over EDID/BIOS specified preferred modes Please try out this patch; it should cause the config file to override the EDID/BIOS detected preferred modes.
Keith's patch works, thanks a lot, I now get my PreferredMode (1600x1200) on TMDS-1 at startup. Can we get this patch committed in server-1.4-branch ? :)
this bug seems to be resolved, but someone open it on 27th, Sept. Would you please add some comment? Or, it'll be marked as resolved. thanks!
Keith, would you commit the attached patch?
> this bug seems to be resolved, but someone open it on 27th, Sept. Would you > please add some comment? Or, it'll be marked as resolved. thanks! Michael, I don't think this bug has been reopened recently. IIRC, I left it open since from Sept 3rd since Keith's patch worked but it hasn't been committed yet.
*** Bug 12587 has been marked as a duplicate of this bug. ***
I forgot to push this patch to master... Done now, this bug should be fixed.
*** Bug 13151 has been marked as a duplicate of this bug. ***
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.