I have a toshbia M100 with a GMA 945/950 in it and I want to be able to use
composite but when I use a compsiting manger such as the ones found in xfwm or
kwin or if I use xcompmgr OpenGL windows draw themselves on top of everything
else regardless to the actual window layering. I will attach configuration
files, log files and a screenshot of the problem.
Created attachment 7494 [details]
Screenshot of problem
This screenshot shows glxgears running behind Konsole with xcompmgr running,
but this happens with other composite managers as well and with other OpenGL
programs such as screensavers.
Created attachment 7495 [details]
Xorg Configuration File
Created attachment 7496 [details]
Fixing this is far from trivial, see http://dri.freedesktop.org/wiki/DirectRenderingToRedirectedWindows for a sketch of the road ahead.
Why does EVERYONE ELSE with this EXACT chip not have this problem. Is it actually a driver problem? I've read reports of people being able to run Beryl with no problem on this chip. How do I prove this is a Hardware fault so Toshiba will fix it?
(In reply to comment #5)
> Why does EVERYONE ELSE with this EXACT chip not have this problem.
How did you get that impression? Everybody should have the same problem under the same circumstances.
> Is it actually a driver problem?
It's more complicated than that, see comment #4.
> I've read reports of people being able to run Beryl with no problem on this
I can only guess based on this little information, but maybe they're using Xgl.
> How do I prove this is a Hardware fault
It probably isn't.
I have the same problem on my laptop (incidentally also a Toshiba M100). I never noticed it until I stumbled across this bug report and checked for myself.
Is there any work currently to have it fixed? Or is the fix still being merely discussed...
(In reply to comment #8)
> Is there any work currently to have it fixed? Or is the fix still being merely
There is work going on here, but the scope of this is a lot bigger than your average bug fix. We need to rework the interaction and interface between the kernel drm, the X server and the 3D DRI drivers. We're probably talking man-years of work here, so you'll have to wait a little longer :) Michels roadmap mentioned in comment 4 gives an idea of the changes we're looking at.
*** Bug 6283 has been marked as a duplicate of this bug. ***
*** Bug 1208 has been marked as a duplicate of this bug. ***
Any progress? This bug is over a year old. I bought a laptop with an intel graphics chip because I wanted to use a free software driver but obviously that was a mistake. Next time I'll go with an NVIDIA chip. The drivers may be proprietary but at least their stuff WORKS! It's nearly 2008, I should be able to have nice effects on my computer. KDE 4 is coming out soon and I won't be able to use it to it's full potential because this is BROKEN!
It's your decision to make: don't let us stop you.
Joseph, there's been lots of progress on this front, but the final bits haven't been released yet afaik, though Kristian may have more details on what's available for testing etc.
Isn't there any kind of workaround for this? I don't care much for performance on the particular machine where this problem occurs, but it would be nice if toys like Google Earth or Celestia would have usable menus. Any idea?
(In reply to comment #15)
> Isn't there any kind of workaround for this?
Unfortunately not - the only way to get correct compositing is to properly redirect the rendering.
*** Bug 14034 has been marked as a duplicate of this bug. ***
I would be interested in amd64 testing, when something's available.
I'm having the same problem on my desktop.
Q965 Integrated Graphics Controller (rev 02) --> Intel® GMA 3000
It will likely affect my eeepc also.
Sorry for the spam, but is there any update on this?
Although I understand that this is not, by any stretch of the imagination, a trivial fix, there seem to be more and more Linux-based devices that are coming out in the next few months that all exhibit this issue, and it sucks to have to choose between composite or GL. This suckage increases as we are now starting to get more application<=>GL integration on the desktop.
Anyway, thanks for all the hard work!
PS. I can provide testing on the 945GSE chipset.
There should be a fix for this in the next release.
It's called DRI2.
Anyone know how I can get a version of Xorg with DRI2 on Gentoo?
Hooray for DRI2!
*** Bug 19742 has been marked as a duplicate of this bug. ***
*** Bug 19974 has been marked as a duplicate of this bug. ***
I can confirm that this is fixed int ubuntu jaunty alpha5 by enabling dri2 and uxa. Thank you very much.
*** Bug 27947 has been marked as a duplicate of this bug. ***
Why is this marked as FIXED? I see that one poster found a workaround by manually enabling dri2 and uxa on Ubuntu, but the fix was never ported to the released version of the driver. That is, even on Ubuntu, users are bitten by this bug unless the know how to enable dri2 and uxa, and assuming that they know that they even have to.
I am reopening until the issue is fixed, a workaround (or manually enabling dri2/uxa) is not a fix.
One of the main points of DRI2 was to fix GL + composite. It will only work as expected with a DRI2 capable driver. DRI2 is not a workaround, it is the fix.
> One of the main points of DRI2 was to fix GL + composite. It
> will only work as expected with a DRI2 capable driver. DRI2 is
> not a workaround, it is the fix.
I have misunderstood, then. I understood this issue to be for improving OpenGL (and DRI) support for a specific driver. I was too quick to mark my own bug as a dupe (see comment 25). I will reopen that bug as a request to enable DRI in radeonhd.
> --- Comment #28 from Dotan Cohen <email@example.com> 2010-05-03 12:19:42 PDT ---
> I will reopen that bug as a request to enable DRI in radeonhd.
don't. just use radeon instead.