Unsynced TMDS with xf86-video-intel on 945GM

[René Rebe]

Hi again, (resend as the first attachment was a little big for the xorg list)

On Thursday 28 June 2007 08:45:47 René Rebe wrote:
> 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,

I have the next observation regarding this "issue" as I mentioned earlier
this is only an issue if the 3D engine is driven, that is when I run a 3D
composition manager - without one, plain old X the 2nd pipe/CRT is
always fine - however, when the 3D compositoer (e.g. Beryl) is running
and I switch to the external output the CPU load is also influencing
this rolling pixel trash issue. Normally I usually switched without any
CPU load, while today I think I switched for the first time while the
laptop was compiling a bigger piece of software and the external
output had nearly no pixel trashing scrolling by - just very little. As
soon as the compilation stopped the external output was a total
rolling thru pixel trash image and I had to do the switch 3-6 times
until the external pixel stream is stable dance.

As I have not much understanding of the inner workings of the Intel
chips I have really no idea how such a strange behaviour can happen,
although I would love to touch code to fix this. But this whole
scenario is soo damn mysterious, ... Maybe the Intel lab can afford to
buy an Apple MacBook, maybe even borrow one from the Intel Mac
department and take a look? Though I think this really is no Apple/EFI/
MacBook issue, but probably a generic problem with the specific
chipset or so:

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
00:07.0 Performance counters: Intel Corporation Unknown device 27a3 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
01:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 22)
02:00.0 Network controller: Atheros Communications, Inc. Unknown device 0024 (rev 01)
03:03.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61)

Xorg log attached.

-- 
  René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
  Geschäftsführer: Susanne Klaus, René Rebe
  Sitz: Berlin, Amtsgericht Charlottenburg HRB 105 123 B
  USt-IdNr.: DE251602478
  http://exactcode.de | http://t2-project.org | http://rene.rebe.name
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Xorg.0.log.bz2
Type: application/x-bzip2
Size: 11864 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20070730/54d1b944/attachment.bin>