Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T

[Alex Deucher]

On 8/30/07, Branden Robinson <branden at debian.org> wrote:
> On Thu, Aug 30, 2007 at 01:17:29PM -0400, Alex Deucher wrote:
> > Ok.  now we just need to figure out how the ports are mapped. Since
> > you have two DVI ports I suspect the one you are currently using it
> > drive by an external tmds chip, which is not fully supported at the
> > moment (it might work if OF or macos init's the chip first).  That may
> > be part of the reason for the interference.
> >
> > try the following connector table:
> >
> > # port  ddc            dac       tmds     connector
> > # port0 VGA_DCC primary external DVI-I
> > # port1 DVI_DCC  tvdac     internal  DVI-I
> > Option "ConnectorTable" "3,0,1,3,2,1,0,3"
>
> Progress!
>
> This restores the video card's ability to talk to the monitor.
>
> Unfortunately, not only does the original bug not appear to be fixed, but
> there is further degradation.
>
> See the following screenshots.  The first was after a restart of kdm.  The
> second was after exiting that session and starting a new "generation" of
> the X server, though I'm not sure if/how that matters.
>
> http://redwald.deadbeast.net/tmp/branden_grief_4.jpeg
> http://redwald.deadbeast.net/tmp/branden_grief_5.jpeg
>
> I'll call that new problem #1: this looks like actual framebuffer
> corruption on top of the video signal interference (sic?) I've been
> experiencing since I filed this bug.
>
> More data points:
>
> xvidtune no longer works to fix the pinkness and striping effect.  But I
> reckon this is expected thanks to some X extension jiggery-pokery -- RandR
> 1.2 superseding XVidMode.  At least that's my vague understanding.
> Corrections welcome.  :)
>
> Based on that conjecture, I poked around with xrandr (the utility), and
> came up with the following recipe:
>
> xrandr --output DVI-1 --mode 0x4f
> xrandr --output DVI-1 --mode 0x4e
>
> (0x4e is the mode I actually start in.)
>
> Any mode change fixes the problem, but modes with resolutions smaller than
> 1600x1200 get rejected as being too small.  Michel Dänzer seemed to think
> that should work.  Should it?

Depends on the monitor.  In most cases it should.  Can you send me the
output of xrandr --verbose?  the strange colors and such may be due to
the external TMDS chip.  it may need some special handling that we are
not currently doing that gets fixed after you switch modes.  Can you
try again with the same connectortable option but the monitor attached
to the other DVI port?  there's a greater chance of that port working
correctly as it uses internal tmds which we know how to program
correctly.

>
> New problem #2: The X cursor is corrupted.  It looks like the cursor has
> been sectionally barrel-shifted about the vertical axis.  This doesn't
> visibly affect the insertion point cursor that xterm uses, but the normal
> right-pointing arrow that KDE uses barely is, and the white hand cursor KDE
> uses when you hover over the task bar is dramatically affected.
>

known server issue see bug:
https://bugs.freedesktop.org/show_bug.cgi?id=11796

> New problem #3: Console framebuffer corruption: While the X server is
> alive, there is no problem, but when the X server exits, every character
> cell on the text VTs gets its left and right halves swapped, making the
> console unreadable without great effort.  The only way I have figured out
> to correct this is to restart the X server.

not sure about this.  It may be some issue with radeonfb or the
external tmds chip not being reset properly.

Alex