Bug 22852

Created attachment 27850 [details] [review]
Xorg.log from (working) 6.12.2 driver

Created attachment 27851 [details] [review]
Xorg.log with (non-working) 6.12.99 driver

Created attachment 28406 [details]
dmesg with VGA-1 failing because of EDID errors

Could it be that somehow the two output clocks are coupled incorrectly? I have updated my kernel about once a week since reporting, and today I got this in dmesg (running -rc4 since last week):


[    0.841972] [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 185
[    0.842015] [drm:edid_is_valid] *ERROR* Raw EDID:
[    0.842051] <3>00 ff ff ff ff ff ff 00 26 cd ac 46 7a 2e 00 00  ........&..Fz...
[    0.842055] <3>31 0e 01 03 0e 22 1b 78 2a 2d 90 a4 57 4a 9c 25  1....".x*-..WJ.%
[    0.842058] <3>11 50 54 bf ef 00 81 80 71 4f 01 01 01 01 01 01  .PT.....qO......
[    0.842061] <3>01 01 01 01 01 01 bc 34 00 98 51 00 2a 40 10 90  .......4..Q.*@..
[    0.842064] <3>13 00 54 0e 11 00 00 1e 00 00 00 ff 00 30 35 33  ..T..........053
[    0.842067] <3>36 35 47 34 43 31 31 38 39 38 00 00 00 fd 00 37  65G4C11898.....7
[    0.842071] <3>4b 18 53 0e 00 0a 20 20 20 20 20 20 00 00 00 fc  K.S...      ....
[    0.842074] <3>00 50 4c 45 34 33 31 0a 20 20 41 ff ff ff ff ff  .PLE431.A.....
[    0.842076] 
[    0.842079] radeon 0000:01:00.0: VGA-1: EDID invalid.
[...]
[    1.043601] [drm] TMDS-8: set mode 1920x1080 1a
[    1.081245] Console: switching to colour frame buffer device 240x67

(EDID's last six bytes are corrupted)

But here's the kicker: now that the VGA port can't be setup because of wrong EDID info, the DVI-0 that used to fail is actually working fine and showing console at boot. Both screens still work correctly with the 6.12.2 driver, so no change there.

In order to rule out any incompatibilities between Debian and Ubuntu, I tried the Ubuntu karmic live-cd (alpha-3) today. The shipped kernel (based on -rc3) supports kms when radeon.modeset=1 is passed on the command line.

This cd exhibited the same symptoms at boot (one monitor killed), but X.org could succesfully initialize the second monitor, using a 6.12.99 driver from 29-06.

Next, I installed the packages from xorg-edgers in the live environment, and the symptoms reappeared. I have tried various combinations of mesa, libdrm, and xorg-video. I apologize for not having exact version numbers - I did create a document containing all my findings but being a live-cd, I stored it only on the tmpfs and during one of my trials I got a hard hang...

Nevertheless, I can confidently say the following:

- the display problems are consistent among all tested kernels (self-built -rc1 to -rc5, and Ubuntu-built -rc3)
- X.org is capable of recovering the second monitor itself, except when using all packages from the xorg-edgers repository. I scanned the build logs for both libdrm and video-ati, and the only difference between the builds (other than checkout dates) is the appearance of enable-radeon-experimental-api in the xorg-edgers libdrm. I assume all other configurations use an older code path for modesetting?
- in all cases where X.org failed to recover the second monitor, xrandr showed incomplete resolution information like I mentioned above.

(In reply to comment #4)
> - in all cases where X.org failed to recover the second monitor, xrandr showed
> incomplete resolution information like I mentioned above.

This last part is no longer true. In fact, with kernel 2.6.32-rc3 and yesterday's git radeon driver, xrandr now gives more resolution options (like a 720x480 mode) that weren't there before. Sadly, the second monitor still fails to recognize the data it's being fed, so no change there.

This appears to be fixed somewhere between 2.6.32-rc5 and 2.6.32-rc7 (or slightly after -rc7), as I now have two screens that display boot messages, and the xorg drivers from the xorg-edgers repository give me two working screens as well.

Oddly, I've been running -rc7 for a week now and only today has the second screen come alive. I guess it required a cold boot instead of the reboots I've been trying before. There is just one slight issue remaining, though: after booting the second screen occasionally blinks, like it does when it switches video modes. This happens a few times during the first ten minutes of uptime, but I haven't seen this happening for the past 30 minutes.

(In reply to comment #6)
> [...] There is just one slight issue remaining, though: after
> booting the second screen occasionally blinks, like it does when it switches
> video modes. This happens a few times during the first ten minutes of uptime,
> but I haven't seen this happening for the past 30 minutes.

This flickering is caused by xrandr queries (gnome-settings-daemon does these, as do several SDL apps I've run). I can reproduce by simply typing xrandr (without options) in a terminal.

(In reply to comment #7)
> This flickering is caused by xrandr queries (gnome-settings-daemon does these,
> as do several SDL apps I've run). I can reproduce by simply typing xrandr
> (without options) in a terminal.
> 

When apps query randr, it probes the outputs for monitors.  If no monitors are connected, the analog ports use load detection to check for monitors which causes a flicker.  IIRC, a new randr call was added that just gets the current config rather than re-probing the outputs.  You can disable load detection using xrandr:
xrandr --output <output> --set "load detection" 0

(In reply to comment #8)
> When apps query randr, it probes the outputs for monitors.  If no monitors are
> connected, the analog ports use load detection to check for monitors which
> causes a flicker.
Thanks for the explanation. That would make sense if the flickering monitor was connected to VGA-0 (or I haven't understood you correctly). But the monitor on VGA-0 does not flicker; it's the DVI-0 port that flickers. My apologies for being incomplete - I should have been more explicit in my previous comment.

>  IIRC, a new randr call was added that just gets the current
> config rather than re-probing the outputs
Which component(s) would I need to update to test this new call? I'm still tracking git for most components, so it's only a matter of time before these calls show up:

ii  libgl1-mesa-dri                 7.7.0~git20091129+mesa-7-7-branch[..]
ii  xserver-xorg-video-ati          1:6.12.99+git20091127[..]
ii  linux-image-2.6.32-rc7          20091113
ii  xserver-xorg-core               2:1.6.5-1


>  You can disable load detection using xrandr:
> xrandr --output <output> --set "load detection" 0

This appears to have no effect. I can't avoid the flickering by setting load detection to 0 on DVI-0, but also if I set load detection to 1 on the VGA-0 port, the VGA-0 port does not flicker.

On Mon, Nov 30, 2009 at 04:23:14 -0800, bugzilla-daemon@freedesktop.org wrote:

> --- Comment #9 from Arno Schuring <aelschuring@hotmail.com>  2009-11-30 04:23:14 PST ---
> (In reply to comment #8)
> >  IIRC, a new randr call was added that just gets the current
> > config rather than re-probing the outputs
> Which component(s) would I need to update to test this new call?
> 
xrandr's --current option makes use of this call, which is available
since xrandr 1.3 and xserver 1.6.

(In reply to comment #9)
> Thanks for the explanation. That would make sense if the flickering monitor was
> connected to VGA-0 (or I haven't understood you correctly). But the monitor on
> VGA-0 does not flicker; it's the DVI-0 port that flickers. My apologies for
> being incomplete - I should have been more explicit in my previous comment.
> 

The load detection code uses the a crtc (display controller) do do the detection so it will affect whichever head is currently driven by that crtc.

> This appears to have no effect. I can't avoid the flickering by setting load
> detection to 0 on DVI-0, but also if I set load detection to 1 on the VGA-0
> port, the VGA-0 port does not flicker.
> 

The option will be load_detection if you are not using KMS.  Check xrandr --verbose to make sure you are using the proper attribute name.  If it's still not working, it's possible that kms isn't properly handling the option.

If all of your connectors have a monitor connected, the driver shouldn't even be using load detection since it's able to get an edid from the monitor.

Firstly: this is getting way off from the original problem. Should I change the summary to reflect this?


(In reply to comment #10)
> xrandr's --current option makes use of this call, which is available
> since xrandr 1.3 and xserver 1.6.
Indeed, I can confirm that $ xrandr --current does not make the screen flicker.

(In reply to comment #11)
> If all of your connectors have a monitor connected, the driver shouldn't even
> be using load detection since it's able to get an edid from the monitor.
I think I understand what's going on now. The flickering is caused by load detection on the S-video port (the only one without a monitor). The non-kms configuration defaults to load_detection=0 on that port, but the flicker appears as soon as I set it to 1:

aschuring@neminis:~$ xrandr --verbose | egrep ^[A-Z]\|load\|CRT
VGA-0 connected [..]
	CRTC:       0
	CRTCs:      0 1
	load_detection: 0 (0x00000000)	range:  (0,1)
DVI-0 connected [..]
	CRTC:       1
	CRTCs:      0 1
	load_detection: 0 (0x00000000)	range:  (0,1)
S-video disconnected [..]
	CRTCs:      0 1
	load_detection: 1 (0x00000001)	range:  (0,1)

In KMS mode however, I can't disable the load detection (or at least it has no effect):

aschuring@neminis:~$ xrandr --verbose | egrep ^[A-Z]\|load
VGA-0 connected [..]
	load detection: 0 (0x00000000)	range:  (1,0)
DVI-0 connected [..]
	load detection: 0 (0x00000000)	range:  (1,0)
S-video disconnected [..]
	load detection: 0 (0x00000000)	range:  (1,0)

With all load detection set to 0, the screen still flickers.

with kernel 2.6.35, I no longer get screen blinks with either xrandr or totem (load_detect still set to 1).