Unsynced TMDS with xf86-video-intel on 945GM

[Alex Deucher]

On 5/16/07, René Rebe <rene at exactcode.de> wrote:
> On Wednesday 16 May 2007 21:36:22 Keith Packard wrote:
> > On Mon, 2007-05-14 at 09:18 +0200, René Rebe wrote:
> >
> > > However often (like about 80% of the X starts) I get flickering and rolling thru
> > > pixel trash on the external display. It "looks" like there is some sync (or so)
> > > missing or imprecise, as it's the actual desktop pixel content flushing and
> > > shuffling by.
> >
> > > This can be fixed by re-enabling the LVDS and disabling it again:
> >
> > Sounds like the mode programming has some stability issues; the
> > registers in the chip must be programmed in the right sequence and with
> > the right delays between various steps in the process. Failing to wait
> > long enough for a PLL to lock can result in 'bad' behaviour like this.
> >
> > About the only way to debug this is to add delays at various points in
> > the mode setting operation, most likely the CRTC timing programming,
> > although it's possible that the SDVO programming is broken instead.
> >
> > One thing to always try is the latest development version of the X
> > server and intel driver; there are a few minor fixes which may be
> > related. Plus, patches you come up with won't need to be ported forward.
>
> Do you have an explanation why the distortion on the TMDS-1
> is mostly disappearing when I rotate the 3D desktop cube?
>
> I would rather expect the "mis-programmed" TMDS output
> to have a static noise than changing with 3D engine load, ... ?
>

Probably memory controller contention.  Some cheap radeon cards with
slow memory have the same problem when 3D is active.  The memory
controller can't service both clients (crtc and 3D) fast enough.  You
may try reducing the timing on your panel or, if you can, bump the
crtc's priority in the memory controller.  This will come at the
expense of 3D performance.

Alex