[r300 KMS] modesetting not accepted by monitor

[aschuring]

I tried the alpha-3 CD of karmic today to verify a problem I have with kernel modesetting on my machine: when booting with radeon.modeset=1, one of my monitors is not correctly initialized and remains blank. The alpha-3 cd is suffering from the same problem, although you'd have to explicitly modify the kernel command line to hit it.

The current karmic X stack (I did an upgrade after booting into the live environment) does reinitialize the second monitor succesfully, so once X is started the problems disappear. However, as soon as I switch to a console screen, the second monitor shuts down again.

I also tried installing the current versions from the xorg-edgers PPA, and using that stack the second monitor stays dead. I haven't looked at the code, but I assume this is because xorg-edgers libdrm is compiled with enable-radeon-experimental-api by default.

Upstream bug report is 22852 (https://bugs.freedesktop.org/show_bug.cgi?id=22852).

[yes, I'm reporting about a bleeding-edge feature not currently enabled by default. Consider this a heads-up in case you might still be considering enabling this by default]

[aschuring (aelschuring)]

Created an attachment (id=27850)
Xorg.log from (working) 6.12.2 driver

[aschuring (aelschuring)]

Created an attachment (id=27851)
Xorg.log with (non-working) 6.12.99 driver

[aschuring (aelschuring)]

Created an attachment (id=28406)
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.

[aschuring (aelschuring)]

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.

[aschuring (aelschuring)]

I tried the alpha-3 CD of karmic today to verify a problem I have with kernel modesetting on my machine: when booting with radeon.modeset=1, one of my monitors is not correctly initialized and remains blank. The alpha-3 cd is suffering from the same problem, although you'd have to explicitly modify the kernel command line to hit it.

The current karmic X stack (I did an upgrade after booting into the live environment) does reinitialize the second monitor succesfully, so once X is started the problems disappear. However, as soon as I switch to a console screen, the second monitor shuts down again.

I also tried installing the current versions from the xorg-edgers PPA, and using that stack the second monitor stays dead. I haven't looked at the code, but I assume this is because xorg-edgers libdrm is compiled with enable-radeon-experimental-api by default.

Upstream bug report is 22852 (https://bugs.freedesktop.org/show_bug.cgi?id=22852).

[yes, I'm reporting about a bleeding-edge feature not currently enabled by default. Consider this a heads-up in case you might still be considering enabling this by default]

[aschuring (aelschuring)]

wrong package, my apologies. Bryce asked me to report it against X.org

[Bryce Harrington (bryce)]

Fixed it up, and thanks for forwarding it upstream already.

[aschuring (aelschuring)]

> ** Also affects: xserver-xorg-video-intel (Ubuntu)
> Importance: Undecided
> Status: New

I think you meant xserver-xorg-video-radeon, right?

[Geir Ove Myhr (gomyhr)]

xserver-xorg-video-ati should be the right package. The actual code for KMS is contained in the linux kernel source package, but we usually keep bug reports in the driver packages until a kernel patch is ready.

[aschuring (aelschuring)]

(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.

[aschuring (aelschuring)]

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.

[aschuring (aelschuring)]

(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.

[agd5f (agd5f)]

(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

[aschuring (aelschuring)]

(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.

[Julien Cristau (jcristau)]

On Mon, Nov 30, 2009 at 04:23:14 -0800, <email address hidden> wrote:

> --- Comment #9 from Arno Schuring <email address hidden> 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.

[agd5f (agd5f)]

(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.

[aschuring (aelschuring)]

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.

[aschuring (aelschuring)]

Just a quick update: the original problem (wrong signal clocks) has been fixed upstream and the bug no longer appears with a 2.6.33 kernel (haven't tried a .32 kernel recently). There is only a minor issue remaining with load detection, which causes the monitors to blink when probing outputs (occurs when starting g-s-d or totem for example).

[Bryce Harrington (bryce)]

[This is an automatic notification.]

Hi aschuring,

This bug was reported against an earlier version of Ubuntu, can you
test if it still occurs on Lucid?

Please note we also provide technical support for older versions of
Ubuntu, but not in the bug tracker. Instead, to raise the issue through
normal support channels, please see:

    http://www.ubuntu.com/support

If you are the original reporter and can still reproduce the issue on
Lucid, please run the following command to refresh the report:

  apport-collect 410401

If you are not the original reporter, please file a new bug report, so
we can work with you as the original reporter instead (you can reference
bug 410401 in your report if you think it may be related):

  ubuntu-bug xorg

If by chance you can no longer reproduce the issue on Lucid or if you
feel it is no longer relevant, please mark the bug report 'Fix Released'
or 'Invalid' as appropriate, at the following URL:

  https://bugs.launchpad.net/ubuntu/+bug/410401

[aschuring (aelschuring)]

This is no longer an issue. Upstream bug is still open because with KMS the driver performs load-detect on already enabled outputs, causing occasional screen flicker

[aschuring (aelschuring)]

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

[Timo Aaltonen (tjaalton)]

thanks, closing.