[Intel-gfx] Screen Corruption On Intel GM45
Magnus Kessler
Magnus.Kessler at gmx.net
Thu Apr 16 23:32:47 PDT 2009
On Friday 17 April 2009, Jesse Barnes wrote:
> On Thu, 16 Apr 2009 23:04:36 +0100
>
> Mike Lothian <mike at fireburn.co.uk> wrote:
> > Hi
> >
> > I've noticed some horrible screen corruption using the lastest git
> > xorg & intel stack with in X.
> >
> > I've made the screen usable by booting with i915.modeset=0 with
> > Linus's latest tree (this just gives me a back screen with the
> > intel-next tree)
> >
> > I think the problem surfaced the same time as the tiling patches
> > appeared - is there a way to disable tiling to test this?
> >
> > My 2.6.29 and last weeks git kernels would refuse to startx for very
> > long not allowing kde to start (it was possible to recognise the
> > loading screen) it would just crash X then try and start it again
> >
> > The latest intel-next tree allows KDE to start WITH the corruption now
> > when KMS is enabled. When I VT switch the consoles look fine, it's
> > only X that's corrupted
> >
> > Hope this isn't too random a bug report
>
> On GM45 you'll need
> http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h
>=f544847fbaf099278343f875987a983f2b913134 which is currently in Eric's
> drm-intel-next branch. Otherwise in a KMS config the 2D driver will try
> to use a tiled buffer but the kernel won't set it up properly and you'll
> just get corruption.
Even with this patch, any non-trivial OpenGL using application will lead to
a garbled screen within its own output window. The rest of the screen is
unaffected.
If the entire screen is corrupted when KDE starts up, this is most likely
due to kwin compositing effects. Mike, can you try to set "[Compositing]
Enabled=false" in your kwinrc file and restart KDE? This should give you a
working KDE again with HEAD of xserver, although without the bling. Any
OpenGL application you start within that session (or in a plain startx
session with e.g. twm) will still be corrupted.
For me xserver at commit 808fd2c67f303cb721769375b11ce8b90ffc1909 (just
before the DRI2 fake front buffer patches) with the memory leak fix
7b6400a1b8d2f228fcbedf17c30a7e3924e4dd2a applied on top works quite well for
the time being.
Magnus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.x.org/archives/xorg/attachments/20090417/f1d705a5/attachment.pgp>
More information about the xorg
mailing list