Created attachment 23515 [details] Log when for the "bad" case Forwarding my own bug report from Ubuntu: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/273306 this bug has also been reported for Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498262 Bug description: When a monitor is connected to the DVI port, the intel driver sometimes detects a monitor on the VGA port and sets the resolution to match this non-existent monitor. The behaviour is random, but can usually be reproduced by restaring the X-server about 10 times. The bias changes, though, so sometimes it has to be restarted several times for the "normal" behaviour to happen. Expected behaviour (good, happens sometimes): The X-server starts and a resolution of 1600x1200 which is the native monitor resolution is chosen. Actual behaviour (bad, happens sometimes): The X-server starts and shows a resolution of 1152x864 (in Hardy with intel-2.2.1 the resolution would be right but the taskbar would not be at the bottom of the screen). In the good case, Xorg.0.log reports: (II) intel(0): Output VGA disconnected (II) intel(0): Output TMDS-1 connected (II) intel(0): Using exact sizes for initial modes (II) intel(0): Output TMDS-1 using initial mode 1600x1200 ... (II) intel(0): Output configuration: (II) intel(0): Pipe A is on (II) intel(0): Display plane A is now enabled and connected to pipe A. (II) intel(0): Pipe B is off (II) intel(0): Display plane B is now disabled and connected to pipe B. (II) intel(0): Output VGA is connected to pipe none (II) intel(0): Output TMDS-1 is connected to pipe A In the bad case, the above lines are: (II) intel(0): Output VGA connected (II) intel(0): Output TMDS-1 connected (II) intel(0): Using fuzzy aspect match for initial modes (II) intel(0): Output VGA using initial mode 1152x864 (II) intel(0): Output TMDS-1 using initial mode 1152x864 ... (II) intel(0): Output configuration: (II) intel(0): Pipe A is on (II) intel(0): Display plane A is now enabled and connected to pipe A. (II) intel(0): Pipe B is on (II) intel(0): Display plane B is now enabled and connected to pipe B. (II) intel(0): Output VGA is connected to pipe A (II) intel(0): Output TMDS-1 is connected to pipe B System environment: -- chipset: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller [8086:2582] (rev 04) -- system architecture: 32-bit -- xf86-video-intel: from at least 2.2.1 until git 2.6.99.1+git20090207.3aa8591a -- xserver: 1.5.99.902 -- kernel: 2.6.28-8-generic -- Linux distribution: Ubuntu (Hardy, Intrepid and Jaunty) -- Machine or mobo model: Dell Optiplex 745 Ultra Small Form Factor -- Display connector: DVI Reproducing steps: -- Start the computer -- Log in and out (or Zap if the option is enabled) if the problem does not occur right away. Additional info: The Dell Optiplex 745 USFF has a DVI-I port and no VGA port. It comes with a cable that takes DVI-I to VGA and DVI-D. I think other models of the Optiplex 745 only has a VGA port and possibility to add a DVI. I usually don't have the adapter attached and use a DVI-D cable, but I have also tested going via the adapter. When the monitor is attached to the VGA output of the adapter, no problems occur. Xrandr behaviour: xrandr does some strange things, which I think may be correlated: In the "bad" case it shows Screen 0: minimum 320 x 200, current 1152 x 864, maximum 1600 x 1600 VGA disconnected 1152x864+0+0 (normal left inverted right x axis y axis) 0mm x 0mm TMDS-1 connected 1152x864+0+0 (normal left inverted right x axis y axis) 367mm x 275mm 1600x1200 60.0 + 1280x1024 75.0 60.0 1152x864 75.0* 1024x768 75.0 60.0 800x600 75.0 60.3 640x480 75.0 59.9 720x400 70.1 1152x864 (0x3e) 81.6MHz h: width 1152 start 1216 end 1336 total 1520 skew 0 clock 53.7KHz v: height 864 start 865 end 868 total 895 clock 60.0Hz (note the 0mm x 0mm for the disconnected VGA) In the "good" case it usually shows Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 1600 x 1600 VGA disconnected (normal left inverted right x axis y axis) TMDS-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 367mm x 275mm 1600x1200 60.0*+ 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.0 60.0 800x600 75.0 60.3 640x480 75.0 59.9 720x400 70.1 (note that there is no longer a "0mm x 0mm" on the VGA line), but every now and then it shows Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 1600 x 1600 VGA connected (normal left inverted right x axis y axis) 1360x768 59.8 1152x864 60.0 1024x768 60.0 800x600 60.3 640x480 59.9 TMDS-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 367mm x 275mm 1600x1200 60.0*+ 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.0 60.0 800x600 75.0 60.3 640x480 75.0 59.9 720x400 70.1 This latter xrandr output is correlated with some extra EDID related lines being added to Xorg.0.log compared to the other case. The two first two are the additions that happen in the "disconnected" case, and the last two the ones that happen in the "connected" case: http://launchpadlibrarian.net/21295589/3195-disconnected-diff.txt http://launchpadlibrarian.net/21295590/b657-disconnected-diff.txt http://launchpadlibrarian.net/21295591/4c61-connected-diff.txt http://launchpadlibrarian.net/21295592/72cf-connected-diff.txt (these diff-files are from driver version 2.5.1 - I hope that is fine).
Created attachment 23516 [details] Log for the "good" case
Created attachment 23517 [details] Output of xrandr --verbose in the "bad" case
Created attachment 23518 [details] Output of xrandr --verbose in the "good" case when it shows VGA disconnected
Created attachment 23519 [details] Output of xrandr --verbose in the "good" case when it shows VGA connected
Created attachment 23520 [details] The most common output of intel_reg_dumper in the "bad" case
Created attachment 23521 [details] Occational output of intel_reg_dumper in the "bad" case
Created attachment 23522 [details] Occational output of intel_reg_dumper in the "bad" case (2)
Created attachment 23523 [details] Occational output of intel_reg_dumper in the "bad" case (3)
Created attachment 23524 [details] The most common output of intel_reg_dumper in the "good" case
Created attachment 23526 [details] Occational output of intel_reg_dumper in the "good" case (1)
Created attachment 23527 [details] Occational output of intel_reg_dumper in the "good" case (2)
(In reply to comment #0) > -- Machine or mobo model: Dell Optiplex 745 Ultra Small Form Factor Sorry, this problem occurs on the Dell Optiplex SX280 Ultra Small Form Factor which has the 915G chipset (the 745 ones have 965Q). I have both models here, and mixed up the model numbers. Also, I forgot to mention that adding to xorg.conf: Section "Device" ... Option "Monitor-VGA" "VGA" EndSection and the new section: Section "Monitor" Identifier "VGA" Option "Ignore" "True" EndSection solves the problem (at least until someone tries to connect a VGA for real).
Geir, thanks for filing the bug according to the template. This is definitely a good bug report sample :)
Thanks, Geir Ove Myhr, and it will let us come back faster with a solution..:) I think we've got the root cause, in fact, I've been waiting for such a case to verify.. stay tuned.
Created attachment 23673 [details] [review] crt ddc detect patch Could you test with this patch against current git master?
(In reply to comment #15) > Created an attachment (id=23673) [details] > crt ddc detect patch > > Could you test with this patch against current git master? > I wasn't able to build git-master [1], but Tormod Volden included the patch in yesterday's ubuntu build of git-master[2], and I was able to test that. The patch didn't change anything. The behaviour is the same as before, and the outputs of intel_reg_dumper are exactly the same in both the good and the bad case. The output of `xrandr --verbose` has not changed for the bad case or the good case when it reports no connected VGA (except for the Timestamp line), but for the good case with VGA connected one of the mode lines changed slightly for the fictional VGA ("1360x768 (0x87)" changed into "1360x768 (0xa8)" and "1152x864 (0x88)" into "1152x864 (0xa9)"). I will attach the updated Xorg.0.log for both cases (I usually remove the ubuntu-specific timestamps with `sed 's/\[[0-9 ]*\.[0-9]*\]\ (/(/g'` for diffing, but there may be more elegant ways). [1]: https://lists.ubuntu.com/archives/ubuntu-x/2009-March/000430.html [2]: https://launchpad.net/~xorg-edgers/+archive/ppa
Created attachment 23759 [details] Log when for the "bad" case with patch 23673
Created attachment 23760 [details] Log for the "good" case with patch 23673
Created attachment 23761 [details] Output of xrandr --verbose in the "good" case when it shows VGA connected with patch 23673
there are indeed some difference. From the log in comment# 17 and comment# 18, VGA is always shown as disconnected during initconfig, which is good... However, in the "bad" case, I see the trace of VGA get_modes from time to time in the log, which means later on detection becomes successful ( which shouldn't happen ). The other interesting behaviour is good or bad case "happens somtime"... Hmm.. another thing is this in the log: (EE) intel(0): First SDVOB output reported failure to sync BTW, Geir Ove Myhr, for the xrandr output in comment# 19, did you get it right after you login to the desktop environment? thanks.
(In reply to comment #20) > BTW, Geir Ove Myhr, > > for the xrandr output in comment# 19, did you get it right after you login to > the desktop environment? Yes, pretty much since I restarted the X-server until the good case happend and then logged in to get the log and compare it with the previous one (it seems to be biased towards the bad case at the moment). It would not be the first run of xrandr after login, though, since I run something like xrandr --verbose | tee xrandr.out | head several times until I get the VGA connected output (which I think happens around 1 in 10 times or less). I can test tomorrow if the output changes over time (except for the timestamp). Is there anything I should do in between to help trigger a change? Is there anything specific I should look for?
(In reply to comment #21) > I can test tomorrow if the output changes over time. After leaving the computer logged in overnight in the good state, I still get the exact same output of `xrandr --verbose` as yesterday. Every now and then it is the same as in comment# 19 (including same Timestamp), but most of the time it is the same as comment# 3 (except that the Timestamp is the same as in comment# 19).
*** Bug 20715 has been marked as a duplicate of this bug. ***
hi Geir Ove Myhr, Could you please upload bad in comments #17 and good in comments #18 cases respectively with modedebug option on ? Thanks Ma Ling
Created attachment 24673 [details] Log for the "bad" case with patch 23673 (ModeDebug true) Sorry, the Jaunty development version I used had ModeDebug on by default at the time, but I didn't take into account that I had just replaced xorg with the one from git-master.
Created attachment 24674 [details] Log for the "good" case with patch 23673 (ModeDebug true)
Created attachment 24675 [details] Another log for the "good" case with patch 23673 (ModeDebug true) Just adding another log in case it makes a difference. The previous one was taken from when Xorg started in the "good" state directly after a cold boot. This one is from restarting the xserver repeatedly until the good case happend again. In this case the hardware state on x-startup is the same as in the "bad" case. In the "good" case after boot PIPEASTAT is 0x00000203 while after restart of the xserver it is 0x00000000 both in the good and bad case.
I have tested the issue on the same dell machine. There is another symptom, by dvi-to-vga adapter the driver can't get edid from the same monitor(i know there live vga edid) although xrandr -q can detect vga output stably.
(In reply to comment #28) > I have tested the issue on the same dell machine. There is another symptom, > by dvi-to-vga adapter the driver can't get edid from the same monitor(i know > there live vga edid) although xrandr -q can detect vga output stably. > what about the bug reporter's issue? Can you reproduce it or not?
(In reply to comment #29) > (In reply to comment #28) > > I have tested the issue on the same dell machine. There is another symptom, > > by dvi-to-vga adapter the driver can't get edid from the same monitor(i know > > there live vga edid) although xrandr -q can detect vga output stably. > > > what about the bug reporter's issue? Can you reproduce it or not? yes, I tested, and found the same problem by continuously typing xrandr -q command.
Created attachment 25461 [details] please try the debug patch on your machine, thanks.
(In reply to comment #31) > Created an attachment (id=25461) [details] > please try the debug patch on your machine, thanks. Let's see if I get this right... Latest GIT master with this patch applied in addition to the patch in comment 15? And since this is a debug patch, you don't expect it to change the behavior, but it should dump more to Xorg.0.log? I'll try to get this done soon, but please tell me if I got this wrong.
(In reply to comment #32) > Let's see if I get this right... Latest GIT master with this patch applied in > addition to the patch in comment 15? And since this is a debug patch, you don't > expect it to change the behavior, but it should dump more to Xorg.0.log? I guess the last patch was not really for enabling debug output. With both patches, the problem is fixed for me. I have restarted xorg 20 times, each time getting the correct resolution. Also, the output of `xrandr -q` is constant. As a side note, with the git master as of today (a8a771a8), the xrandr output without the patch would in addition to the previous different behavior sometimes add the lines 1360x768 (0xcc) 84.8MHz h: width 1360 start 1432 end 1568 total 1776 skew 0 clock 47.7KHz v: height 768 start 771 end 781 total 798 clock 59.8Hz 1152x864 (0xcd) 81.6MHz h: width 1152 start 1216 end 1336 total 1520 skew 0 clock 53.7KHz v: height 864 start 865 end 868 total 895 clock 60.0Hz to the end of the output. In these cases it would take much longer (almost one second) to complete the command. This behavior also goes away with the two patches applied. Would you also like me to test with _only_ the patch from comment #31 applied (not the one from comment #15)?
Created attachment 25482 [details] Log with both patches applied, only good case happens
Created attachment 25483 [details] Log for the "good" case without any patches on 2.7.99.1+git20090505
Created attachment 25484 [details] Log for the "bad" case without any patches on 2.7.99.1+git20090505
hi Geir Ove Myhr, please only try the patch in comments #31 aginst latest driver to check whether vga can be detected correctly. thanks for your help Ma Ling
(In reply to comment #37) > please only try the patch in comments #31 aginst latest driver to check whether > vga can be detected correctly. Okay, I have built the driver with only the patch in comment #31, and everything is working! I tried * with a DVI connected and restarted the server 17 times * with a DVI connected via the splitter cable * with a VGA connected via the splitter cable * with both the DVI and VGA connected via the splitter cable In all these cases is worked perfectly. In the last case the monitors were mirrored. In the first case I also ran `xrandr -q` 1000 times and the output was the same every time. I also tried to set SubSection "Display" Virtual 3200 1200 EndSubSection in xorg.conf, in order to run both monitors in side-by-side mode, but setting this crashes the xserver. I installed the driver without the patch and it also happened there, so this is an unrelated bug.
Created attachment 25556 [details] Log with patch from #31 applied, only DVI connected, only the good case happened
Created attachment 25557 [details] Log with patch from #31 applied, only DVI connected (via splitter), only the good case happened
Created attachment 25558 [details] Log with patch from #31 applied, only VGA connected (via splitter), only the good case happened
Created attachment 25559 [details] Log with patch from #31 applied, DVI and VGA connected (via splitter), only the good case happened
Created attachment 25851 [details] please try the patch on your machine. thanks hi Geir Ove Myhr The debug patch intends to detect no-existed vga when you only plug dvi monitor, please try it on your machine thanks for your help Ma Ling
(In reply to comment #43) > Created an attachment (id=25851) [details] > please try the patch on your machine. thanks I tried the patch from comment #43, and it fixes the problem. I have only tested with DVI attached, but as far as I understood this is all that was necessary. If I understand correctly, the debug patch from comment #31 makes sure that the function i830_crt_detect_load always returns FALSE. That patch was for checking that it was indeed that function which in some cases returned TRUE and causing the problems. Right? > hi Geir Ove Myhr > The debug patch intends to detect no-existed vga when you only plug dvi > monitor, please try it on your machine I tested the debug patch in comment #31 with only DVI and gave the result in comments #38 and #39.
Created attachment 25864 [details] Log with the patch from #43 applied, only DVI connected, only the good case
Since the patch in comment #43 fixed the problem, will this be the final patch that will go into driver?
Hi Geir Ove Myhr we have merged the patch, please update your driver, I close the issue now. Thanks Ma Ling commit 88f766be008008d76c150e3ac16f09d4ecbb6d53 Author: Ma Ling <ling.ma@intel.com> Date: Fri May 15 15:22:11 2009 +0800 Wait doubled regis to be stable for load pipe detection We have two approaches for VGA detections: hot plug detection for 945G onwards and load pipe detection for Pre-945G. load pipe detection will get one free pipe ,and set border color as red and blue, then check CRT status by swf register. Because pipe registers in hires mode are double buffered, once set force border bit in pipeconf register, we have to wait for a vblank until it is effective, otherwise result is unstable. It fixed freedesktop bug #20463
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.