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