Created attachment 24844 [details] xorg log file I have a Dell E228WFP attached to my Dell Latitude docking station using DVI. When I start X, the resolution of the external screen is set incorrectly to 1280x1024, where it should be 1680x1050. The laptop screen is set correctly at 1440x900. I've had this problem with older versions of xorg as well, but decided to bug it just now, because KMS does detect the native resolution of the external screen correctly. I can manually correct the problem by running: xrandr --output DVI1 --mode 1680x1050 I do not use xorg.conf. I'm unsure which version to select of xorg, as 1.6 is not in the list. I'm running Archlinux, with these (relevant) packages: xorg-server 1.6.0-3 xf86-video-intel 2.6.3-3
hi So you hope to use native mode(1680x1050) for your dvi monitor both in KMS and UMS ? 1 In KMS you can chose your preferred mode by xorg.conf as below Section "Monitor" Identifier "DVI1" ... Option "PreferredMode" "1680x1050" ... ... EndSection Section "Screen" Identifier "xxxx" Monitor "DVI1" ... ... EndSection. 2 In UMS, could you please upload your xorg log file with modedebug option on ? thanks maling
I only care about KMS (even though the problem exhibits in UMS as well). Sorry for not being clear, but what I was trying to say, is that during boot time, the console is using the correct native resolution. It is when xorg starts, that it picks the wrong resolution, as seen in this snippet of the logfile: (II) intel(0): Output DVI1 using initial mode 1280x1024 As the kernel can detect the native resolution of the screen, I would assume the intel driver could do so as well without using an xorg.conf? I would really like to run xorg without conf.
it looks like you do have a xorg.conf file... (II) intel(0): Using hsync ranges from config file (II) intel(0): Using vrefresh ranges from config file might because the sync ranges that rules out the native 1680x1050 mode for your DVI monitor...could you pls double check?
Created attachment 24896 [details] Xorg.log as generated after every xorg.conf file was removed.
Hmm. I'm not sure how it got to that configuration file, as there was no /etc/X11/xorg.conf. There were however a couple of backup files named like /etc/X11/xorg.conf.something. Removed those just to be sure. The lines stating that it had read something from the config have now disappeared, but the same problem still occurs. The initial mode for the external display is set to 1280x1024. I've uploaded the new Xorg.log.
The keywords field of this bug still shows NEEDINFO. Do you really need more info, or should I have removed that keyword myself after the last update? Thanks.
(In reply to comment #6) > The keywords field of this bug still shows NEEDINFO. Do you really need more > info, or should I have removed that keyword myself after the last update? Yes, you should remove NEEDINFO after providing the info.
Hi Ernst Eeldert, Because xorg will chose close current mode of scrn although driver in KMS provide prefeered mode(log file shows Modeline "1680x1050"x0.0, but xorg chose Modeline "1280x1024"x0.0), we have to set up preferred mode in advance in xorg.conf in order to work normally. Any modes to be set is chosen by xorg, not driver in KMS and UMS. Thanks maling
I understand that the mode is choosen by xorg. However, I fail to understand why the KMS driver is able to automatically select the correct resolution during boot, and xorg needs a config file to achieve the same. Is KMS' mode detection logic different/smarter than xorg's?
(In reply to comment #9) > I understand that the mode is choosen by xorg. However, I fail to understand > why the KMS driver is able to automatically select the correct resolution > during boot, the KMS driver only fetch edid from monitor, and translate it into modes arranged in priority order(such as 1680x1050) then transmit them to xorg. > and xorg needs a config file to achieve the same. Is KMS' mode Xorg(xf86SetDesiredModes function) will chose corresponding modes based on some condition, ask KMS driver to set. > detection logic different/smarter than xorg's? thanks maling
hi maling, thanks for your quick response. So the question would be then why xorg chooses 1280 while KMS tells it that 1680 is available as well? Can we do some more troubleshooting to verify that KMS really provides xorg with the correct information?
Created attachment 25052 [details] please try the patch on xserver, then upload log file thanks. The patch is for xserver, which will tell us what modes are provided by kms driver, please try it. Thanks for your help! maling
It seems that xorg-server gets passed in the correct mode. See attached logfile for results from patched server.
Created attachment 25064 [details] patched xorg-server logfile
(In reply to comment #14) > Created an attachment (id=25064) [details] > patched xorg-server logfile The log shows: 1) for lvds mode from edid by kms driver is Modeline "1440x900"x0.0 95.44 1440 1504 1536 1744 900 903 906 912 -hsync -vsync (54.7 kHz) 2) for DVI1 modes from edid by kms driver are Modeline "1680x1050"x0.0 119.00 1680 1728 1760 1840 1050 1053 1059 1080 +hsync -vsync (64.7 kHz) ... Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) Yes as we mentioned kms driver provide correct resolutions such as "1680x1050"x0.0, but xorg chose defult mode-1280x1024 as initial mode.
(In reply to comment #16) > Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync > (31.5 kHz) > Yes as we mentioned kms driver provide correct resolutions such as > "1680x1050"x0.0, but xorg chose defult mode-1280x1024 as initial mode. So, we have proved that: 1. KMS sets the console to the right resolution and sends all possible ones (correctly) to x. 2. X gets both 1680 and 1280 and chooses 1280 3. We can get x to use 1680 by stating this in xorg.conf or using xrandr So the real question is, why does x on its own, when we do not force it, not use 1680 but goes for the 1280 resolution? Is this a bug? Or is there any reason for it to use 1280 that we can see in the logs?
if (xf86TargetUserpref(scrn, config, modes, enabled, width, height)) xf86DrvMsg(i, X_INFO, "Using user preference for initial modes\n"); else if (xf86TargetPreferred(scrn, config, modes, enabled, width, height)) xf86DrvMsg(i, X_INFO, "Using exact sizes for initial modes\n"); else if (xf86TargetAspect(scrn, config, modes, enabled, width, height)) xf86DrvMsg(i, X_INFO, "Using fuzzy aspect match for initial modes\n"); else if (xf86TargetFallback(scrn, config, modes, enabled, width, height)) xf86DrvMsg(i, X_INFO, "Using sloppy heuristic for initial modes\n"); else xf86DrvMsg(i, X_WARNING, "Unable to find initial modes\n"); Above is the logic used in xserver for init mode selection. Your lvds panel and external monitor has too few common modes for xserver to decide...in your case it goes into the Fallback.. :) you might call it a bug, but this isn't really a driver's bug...
> you might call it a bug, but this isn't really a driver's bug... I see your point. I'm still wondering though why the KMS driver does set the resolution correctly for the console. Also, I have the lid of my laptop closed all the time, so I'm unsure why it takes those modes into the equation. Is there a driver option to force it to use the highest available resolution of both screens? Or would that cause problems with my LVDS screen (even though the lid is closed)?
(In reply to comment #19) > > you might call it a bug, but this isn't really a driver's bug... > > I see your point. I'm still wondering though why the KMS driver does set the > resolution correctly for the console. I think the problem you care about is related with Xorg, so we would move Xorg bug list, right? > > Also, I have the lid of my laptop closed all the time, so I'm unsure why it > takes those modes into the equation. Is there a driver option to force it to > use the highest available resolution of both screens? Or would that cause > problems with my LVDS screen (even though the lid is closed)? Yes, when you have the lid of laptop closed, laptop should be disconnected. however it is very complex and weird, has become known issue for us and on the progress. And could you file new bug for this issue ? Thanks Ma Ling >
> I think the problem you care about is related with Xorg, so we would move Xorg > bug list, right? I guess so. My knowledge of where xorg behaviour stops and where driver behaviour starts is too limited to judge. > Yes, when you have the lid of laptop closed, laptop should be disconnected. > however it is very complex and weird, has become known issue for us and on the > progress. And could you file new bug for this issue ? Will do.
(In reply to comment #21) > > I think the problem you care about is related with Xorg, so we would move Xorg > > bug list, right? > I guess so. My knowledge of where xorg behaviour stops and where driver > behaviour starts is too limited to judge. > > Yes, when you have the lid of laptop closed, laptop should be disconnected. > > however it is very complex and weird, has become known issue for us and on the > > progress. And could you file new bug for this issue ? > Will do.
(In reply to comment #21) > > Yes, when you have the lid of laptop closed, laptop should be disconnected. > > however it is very complex and weird, has become known issue for us and on the > > progress. And could you file new bug for this issue ? > > Will do. > I guess that's bug#11455.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.
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.