Bug 22852 - [r300 KMS] modesetting not accepted by monitor
[r300 KMS] modesetting not accepted by monitor
Status: RESOLVED FIXED
Product: DRI
Classification: Unclassified
Component: DRM/Radeon
unspecified
x86 (IA32) Linux (All)
: low normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-20 08:04 UTC by Arno Schuring
Modified: 2010-08-24 14:08 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
dmesg. At 10000s I switched from 6.12.2 driver to 6.12.99 (31.48 KB, patch)
2009-07-20 08:04 UTC, Arno Schuring
no flags Details | Splinter Review
Xorg.log from (working) 6.12.2 driver (102.67 KB, patch)
2009-07-20 08:06 UTC, Arno Schuring
no flags Details | Splinter Review
Xorg.log with (non-working) 6.12.99 driver (363.03 KB, patch)
2009-07-20 08:08 UTC, Arno Schuring
no flags Details | Splinter Review
dmesg with VGA-1 failing because of EDID errors (31.89 KB, text/plain)
2009-08-06 12:58 UTC, Arno Schuring
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arno Schuring 2009-07-20 08:04:46 UTC
Created attachment 27849 [details] [review]
dmesg. At 10000s I switched from 6.12.2 driver to 6.12.99

Using kernel modesetting, one of my two monitors does not accept any mode set via xrandr, nor does it accept the default mode set during boot. The other monitor works fine, but xrandr shows less modes than with an older driver.

--

I'm currently testing the radeon modesetting features on my Radeon 9550. My system has X.org from Debian unstable, a manually-compiled Linux kernel with kms enabled, and Radeon drivers from the Ubuntu PPA xorg-edgers/radeon-kms (https://launchpad.net/~xorg-edgers/+archive/radeon-kms).

relevant package versions:
xserver-xorg-core                          2:1.6.2-1
xserver-xorg-video-ati                     1:6.12.99+git20090719
xserver-xorg-video-radeon                  1:6.12.99+git20090719
libdrm2                                    2.4.12+git20090717
libdrm-radeon1                             2.4.12+git20090717
libgl1-mesa-dri                            7.6.0~git20090715
linux-image-2.6.31-rc3                     2.6.31-rc3-10.00.Custom


Reverting to the 6.12.2 driver from Debian unstable brings the second monitor back to life. The modelines generated by both drivers appear identical, but in the radeon-kms case, I get the following lines in /var/log/kern.log:

Jul 20 15:35:37 neminis kernel: [13998.608038] [drm] TMDS-8: set mode  35
Jul 20 15:36:16 neminis kernel: [14036.829106] [drm] TMDS-8: set mode  41

The monitor does flicker on and off when I switch between xrandr --off and xrandr --auto, so the port appears correct. I'm running without xorg.conf, so everything is auto-detected.


I'll attach both Xorg logs in a minute. But as for the video modes, XRandr doesn't agree either (VGA-0 = working, DVI-0 = modes not accepted by monitor):


==> xrandr-6.12.2 <==
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 1920 x 1920
VGA-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 340mm x 270mm
   1280x1024      75.0*+   60.0  
   1152x864       75.0  
   1024x768       75.0     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        75.0     72.8     66.7     59.9  
   720x400        70.1  
DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 521mm x 293mm
   1920x1080      60.0 +
   1680x1050      59.9  
   1280x1024      75.0     60.0* 
   1440x900       75.0     59.9  
   1280x960       60.0  
   1152x864       75.0  
   1024x768       75.0     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        75.0     72.8     66.7     59.9  

==> xrandr-6.12.99 <==
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 4096 x 4096
VGA-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 340mm x 270mm
   1280x1024      75.0*+
   1024x768       75.1     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        72.8     75.0     66.7     60.0  
   720x400        70.1  
   0x0             0.0  
DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 521mm x 293mm
   1920x1080      60.0 +
   1280x1024      75.0* 
   1024x768       75.1     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        72.8     75.0     66.7     60.0  
   720x400        70.1  
   0x0             0.0  


(parts of) this could be related to #22638, but it doesn't appear to be the same issue.
Comment 1 Arno Schuring 2009-07-20 08:06:45 UTC
Created attachment 27850 [details] [review]
Xorg.log from (working) 6.12.2 driver
Comment 2 Arno Schuring 2009-07-20 08:08:00 UTC
Created attachment 27851 [details] [review]
Xorg.log with (non-working) 6.12.99 driver
Comment 3 Arno Schuring 2009-08-06 12:58:08 UTC
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.
Comment 4 Arno Schuring 2009-08-07 10:54:46 UTC
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.
Comment 5 Arno Schuring 2009-10-10 15:17:43 UTC
(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.
Comment 6 Arno Schuring 2009-11-25 09:22:24 UTC
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.
Comment 7 Arno Schuring 2009-11-28 14:54:51 UTC
(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.
Comment 8 Alex Deucher 2009-11-28 16:52:29 UTC
(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
Comment 9 Arno Schuring 2009-11-30 04:23:14 UTC
(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.
Comment 10 Julien Cristau 2009-11-30 05:12:00 UTC
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.
Comment 11 Alex Deucher 2009-11-30 07:47:36 UTC
(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.
Comment 12 Arno Schuring 2009-12-01 12:22:03 UTC
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.
Comment 13 Arno Schuring 2010-08-24 14:08:36 UTC
with kernel 2.6.35, I no longer get screen blinks with either xrandr or totem (load_detect still set to 1).