Unsynced TMDS with xf86-video-intel on 945GM

[René Rebe]

On Thursday 17 May 2007 10:57:44 René Rebe wrote:
> On Wednesday 16 May 2007 22:57:57 you wrote:
> > 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.
> 
> Yes I know about such memory bandwith configuration and
> saturation scenarios, especially with shared memory.
> 
> Though in my case it's the other way round: With the rotated
> cube the image is stable while the plain static 2D desktop the
> image is rolling and flickering over the screen.

I just wanted to drop a note that I recently connected my older
LCD screen at home via VGA to the MacBook - and I got exactly
the same random screen pixel content flickering and rolling
garbage. So it is not TMDS related, but some general CRT "whatever"
pipe configuration issue - or memory bandwith related? - in general.

Btw. It "feels" like the pipe's are more often correctly programmed
when I move windows around while the xrandr command is
executed - maybe some registe writing happens too fast?

Yours,

-- 
  René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
  http://exactcode.de | http://t2-project.org | http://rene.rebe.name