Bug 20463

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