Bug 19257

Created attachment 21438 [details]
Server configuration file

This is the output from "xrandr -q" (grabbed from a startx session with a rather minimalistic .xinitrc). I will also post an updated xorg.conf which is the result from trying to fiddle with monitor sections.

Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 1920 x 1200
DVI-1 disconnected (normal left inverted right x axis y axis)
DVI-0 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
   1920x1200      60.0*+
   1600x1200      60.0     60.0
   1680x1050      60.0     60.0
   1600x1024      60.2
   1400x1050      60.0
   1280x1024      60.0     60.0
   1440x900       59.9
   1280x960       60.0     60.0
   1360x768       59.8
   1152x864       60.0
   1024x768       60.0
   800x600        60.3
   640x480        60.0     59.9
   720x400        70.1

Created attachment 21506 [details]
New server configuration

Created attachment 21507 [details]
Server log with new configuration

This is a new server log, resulting from starting KDM, waiting a few seconds at the white screen, and then stopping KDM again. The main difference is that the monitor selection (DVI-1 vs. DVI-0) should be sorted now.

Another "fun" effect: sometimes, the machine crashes hard with the "radeon" driver. Once this resulted in a hang at a black screen, and once the machine rebooted, leaving the root filesystem corrupted. The "radeonhd" driver has been perfectly stable so far.

Created attachment 21508 [details]
Server log with radeonhd driver

Log from radeonhd driver. It is rather verbose about output routing, so maybe it is of help defining chip quirks in that area.

Did this used to work previously?  If so, when?  Does it work on the other DVI port?

Created attachment 21509 [details]
Server log, radeonhd, second DVI port

I only tried it with the last two version hitting debian-experimental:

 - 1:6.9.0+git20081129.783cdb73-1
 - 1:6.9.0.91-1

and both yield the same result. Using the other connector does not change the result, though after cycling through radeon and back to radeonhd, the text console runs at an invalid mode. I tried both "Monitor 1" and "Monitor 2" in the screen section, both produce a white screen.

One thing that comes to mind when looking at the server logs is the HPD handling. The radeonhd driver explicitly seems to "invert" the assignment between the ports:

Connector[0] {RHD_CONNECTOR_DVI, "DUAL_LINK_DVI_I DFP1 CRT2", RHD_DDC_2, RHD_HPD_1, { RHD_OUTPUT_UNIPHYA, RHD_OUTPUT_DACB }  }
Connector[1] {RHD_CONNECTOR_TV, "7PIN_DIN TV1 CV", RHD_DDC_0, RHD_HPD_NONE, { RHD_OUTPUT_DACB, RHD_OUTPUT_NONE } }
Connector[2] {RHD_CONNECTOR_DVI, "DUAL_LINK_DVI_I CRT1 DFP2", RHD_DDC_3, RHD_HPD_0, { RHD_OUTPUT_KLDSKP_LVTMA, RHD_OUTPUT_D ACA } }

Created attachment 21510 [details] [review]
coherent mode off

Does this patch help?  It changes the default DVI mode to non-coherent.

That doesn't change anything but two instances of:

-(II) RADEON(0): DIG2 transmitter: Coherent Mode enabled
+(II) RADEON(0): DIG2 transmitter: Coherent Mode disabled

compared to https://bugs.freedesktop.org/attachment.cgi?id=21507 and those are the only instances of the term "coherent" showing up in the log. I only tested the primary DVI output this time, because the log shows proper routing.

Created attachment 21516 [details]
Server log with an analog connection

I dug out an old monitor with an analog connection, and the results are essentially the same. For completeness's sake, here is the log.

I have the same issue here with a RV635 card. Two monitors with 1920x1200 each are connected via DVI.

This has been tested with radeon 6.10.0, X server 1.5.3, and Linux 2.6.28 on x86_64. The same setup works with radeonhd 1.2.4. Using gdm 2.25.2 here, not kdm, but I assume that the application doesn't have any influence.

can you test the atom-rework branch of my personal repo?
http://cgit.freedesktop.org/~agd5f/xf86-video-ati/?h=atom-rework

I tried it by applying a patch of the src/ directory in your branch to the debian package (6.10), which builds fine, but does not produce any changes whatsoever. On the first attempt, I got a white screen, and after restarting kdm, the system crashed hard (to a black screen). The logs don't differ.

(In reply to comment #13)
> I tried it by applying a patch of the src/ directory in your branch to the
> debian package (6.10), which builds fine, but does not produce any changes
> whatsoever. On the first attempt, I got a white screen, and after restarting
> kdm, the system crashed hard (to a black screen). The logs don't differ.
> 

the logs should differ a bit.  Make sure it installed properly and you applied all the patches in that branch.

Created attachment 21759 [details]
Server log with atom-rework branch

Alright, it seems something went wrong with my first attempt, so I just installed straight from the git clone (ati-6_6_2-1432-gc3fb8bb). The log is indeed different, but I'm still getting a white screen.

The log shows an anomaly: "TMDS Type -- UNIPHYUNIPHY1UNIPHY2" which is probably due to forgotten commas in radeon_output.c. The trivial patch follows.

Created attachment 21760 [details] [review]
Trivial patch for wrong enumeration syntax

Do you still have issues with xf86-video-ati git master?

(In reply to comment #17)
> Do you still have issues with xf86-video-ati git master?

Sorry, I forgot about this one (been using radeonhd so far). This bug seems to be resolved with what Debian ships as 6.12.2-2, xserver-xorg-core 1.6.1.901-2, and kernel 2.6.30. I'll mark it as FIXED.

The current git master doesn't compile for me, which may be due to some missing dependency like libdrm or mesa (both from Debian packages, not the r6xx-7xx-branch):

> In file included from atibus.c:30:
> atibus.h:47: error: expected ‘)’ before ‘ATIPtr’
> In file included from atimach64io.h:37,
>                  from atibus.c:32:
> atistruct.h:266: error: expected specifier-qualifier-list before ‘pciVideoPtr’
> In file included from atibus.c:32:
> atimach64io.h: In function ‘ATIDRIMarkSyncInt’:
> atimach64io.h:245: error: ‘struct _ATIRec’ has no member named ‘useEXA’
> [...]

The X server starts and even provides video acceleration, although I yet have to give the radeon driver a bit of a longer spin, radeonhd gave me severe memory corruption (random processes segfaulted) after about an hour of DVD playback, so I'm a bit wary.