Re: Problems enabling DRI on i810 chipset with xorg-server 1.4.2
On Sat, 2009-04-18 at 13:58 +1000, Dave Airlie wrote: We never built it... Last word was that i915 was supposed to support all chipsets. Not sure where you heard that, i915 just replaced i830 kernel module, i810/5 has always been a separate module. Ok, I'll have a look, although I wouldn't have any way to test it... Surely, it wouldn't be hard to get it working though... robert. Dave. -- Robert Noland rnol...@2hip.net 2 Hip Networks signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Intel-gfx] Screen Corruption On Intel GM45
2009/4/17 Magnus Kessler magnus.kess...@gmx.net: On Friday 17 April 2009, Jesse Barnes wrote: On Thu, 16 Apr 2009 23:04:36 +0100 Mike Lothian m...@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 Yes switching of the bling allows KDE to be usable - glxgears is also fine Mike ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Qt colormap problem
Hi, When i run Qt gui apps on a recent X debian/unstable system, when the mouse cursor passes over a Qt window, the whole screen goes black with traces of some menu text still visible, and various widget colours of the Qt app go black too. I don't know if all Qt apps do this. The one that currently does is Skype for Etch: http://www.skype.com/intl/en/download/skype/linux/choose/ http://www.skype.com/go/getskype-linux-deb I'm using the icewm window manager. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Qt colormap problem
Hi, When i run Qt gui apps on a recent X debian/unstable system, when the mouse cursor passes over a Qt window, the whole screen goes black with traces of some menu text still visible, and various widget colours of the Qt app go black too. I don't know if all Qt apps do this. The one that currently does is Skype for Etch: http://www.skype.com/intl/en/download/skype/linux/choose/ http://www.skype.com/go/getskype-linux-deb I'm using the icewm window manager. The colours don't change if the mouse passes over only the titlebar or borders of the window. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.7.0
2009/4/17 Stefano Avallone stava...@unina.it: On Friday 17 April 2009 17:32:32 Carl Worth wrote: On Thu, 2009-04-16 at 20:24 -0700, John Ettedgui wrote: On Thu, Apr 16, 2009 at 11:03 AM, Frederik Himpe fhi...@telenet.be wrote: On Wed, 15 Apr 2009 18:29:33 -0700, Carl Worth wrote: We are pleased to announce a major 2.7.0 release of xf86-video-intel Apparently, Jesse's last-minute fix that made it into xf86-video-intel 2.7.0 requires a corresponding fix in the kernel, (which as of yesterday was in Eric's tree but not quite into Linus' tree yet---but it might be there by now, I haven't checked yet.) I can confirm that there is no corruption with 2.6.30-rc2 with jbarnes' last- minute fix manually applied, intel driver 2.7.0 and KMS on GM965. No corruption even after a resume from suspend to disk. Great! Where is jbarnes latest patch? Watch commit id from which tree please? I'm sorry we released things in such a delicate state. Seems to have improved some of the tearing issues I was seeing on 2.6.2 but I'm still running in EXA mode. -- Alex, homepage: http://www.bennee.com/~alex/ CV: http://www.bennee.com/~alex/cv.php ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Intel-gfx] Screen Corruption On Intel GM45
On Saturday 18 Apr 2009 13:57:27 Mike Lothian wrote:
2009/4/17 Magnus Kessler magnus.kess...@gmx.net:
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
Yes switching of the bling allows KDE to be usable - glxgears is also
fine
Mike
I find that with the latest DRI2 related patch to xorg-video-intel (commit
5a07ab502fe1e58e7e37fe554fb42d8d2c8c53ec) most OpenGL applications that failed
with the DRI2 fake front buffer patches alone work again with head of Xorg
server. The exception is kwin. Normally it checks for the availability of
certain OpenGL functions and only enables its compositing if all checks
succeed. With current head of Xorg server, xf86-video-intel and Mesa, kwin
compositing is turned off automatically. Forcing it on through
DisableChecks=true leads to a corrupted screen. Ian Romanick suggested on
IRC to verify that kwin uses glXWait{X,GL} correctly. I'm looking into this.
Magnus
signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
