On Wed, 2009-04-29 at 22:23 +0200, GSR wrote: > Hi, > daen...@debian.org (2009-04-29 at 1716.10 +0200): > > On Tue, 2009-04-28 at 22:07 +0200, GSR wrote: > > > Hi, > > > daen...@debian.org (2009-04-28 at 1105.49 +0200): > > > > > I have been also trying other 3D apps, like Supertuxkart, and found > > > > > out the one running via PLib/SDL does not cause stacking issues, just > > > > > that in screenshots I get black pixels in zones covered by other > > > > > windows and the 3D content in non covered parts. STK from SVN does not > > > > > use SDL anymore... and the full bug appears. > > > > > > > > Does running the affected apps with > > > > > > > > XLIB_SKIP_ARGB_VISUALS=1 > > > > > > > > work around the problem? > > > > > > With that glxgears just prints: > > > > > > ---8<--- > > > Error: couldn't get an RGB, Double-buffered visual > > > --->8---
Hmm, actually I can reproduce this... I'll get it fixed upstream. While your problem probably isn't directly related to this, XLIB_SKIP_ARGB_VISUALS=1 should serve as a workaround for it if it wasn't for this other problem. > My logs have been reporting for some time that both DRI and DRI2 are > being loaded, but at the same time it shows: > > ---8<--- > (II) AIGLX: Screen 0 is not DRI2 capable > --->8--- > > And xdpyinfo shows DRI2 and XFree86-DRI. A bit confusing. These just mean the X server extensions are available, not that the drivers actually support DRI2. DRI2 support for the Radeon drivers is being worked on, but it'll probably be a while before it shows up in end user releases. > > > There is also a 2D app that causes black zones in similar fashion than > > > 3D ones (its pixels which are covered by others appear as black). > > > > That's expected, obscured parts of windows are not usually preserved in > > X11. > > I know, but no idea how that applies. To make it clear, the "weird 2D" > window is below the others. I can get screenshots of it if uncovered, > and I can get screenshots of other 2D windows. When a 2D window is > placed over the "funny" one, then the overlapping pixels appear black > in captures, while monitor shows the contents of all windows fine. > > 3D case is the same... it is like if some kind of "censor" went over > pixels looking for where 3D or the "weird 2D" are behind others and > set black the pixels delivered to the capture process. What I expected > is to see whatever is on top, thus preserving (or not) things that are > behind should not matter. See attached screenshot and mockup of what > it should show. Hmm, not sure what's going on then. However, the Mesa driver isn't involved for 2D windows, so this is probably a separate issue. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
