Running mesa/demos/glsync that is using single buffered direct color visual. When window is focused whole screen is black except that hardware cursor is visible. If focus goes to another window with Alt+tab glsync is rendered correctly in background. Same problem did happen to gears too when it selected double buffered direct color visual. I did try to debug the problem: - XQueryColors return correct looking colors (except that red/gree/blue members are set to zero if they shouldn't be) - Clipping Rectangles are set correctly. Problem is visible with all r200, r300 and r600 drivers so it seems like shared problem between radeons at least. I don't know if others drivers do have problems with direct color. Also same problem is visible with different window managers (kwin&metacity at least) My versions are: xserver 1.6.2+git20090724+server-1.6-branch.606f6dba mesa 7.6.0~git20090723.3b4235d4 & git self compiled git master xf86-video-ati 6.12.99+git20090725.57f2c83a
I doubt this is a bug in the X driver - if it didn't set the hardware palette correctly, that should be evident in other circumstances. I think most likely it's simply due to the app getting a direct colour visual when it doesn't really need one nor can really handle it. I suspect the proper solution would be to make the X server generate the depth 32 GLX visual separately from the other GLX visuals again. Please attach your glxinfo output. Another possibility is that something between the app and the X driver is generating an incorrect default colour map.
Created attachment 28159 [details] glxinfo I forgot to mention that glsync is using 24 bit single buffered visual: 0x63 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
*** Bug 23337 has been marked as a duplicate of this bug. ***
Being a regression for radeon in Mesa 7.5 since Mesa 7.4.4 shouldn't this be reassigned to Mesa --> Drivers/DRI/Radeon?
Created attachment 28687 [details] glxinfo-radeon-Mesa-7.4.4
Created attachment 28688 [details] glxinfo-radeon-Mesa-7.5
Maybe relevant diff: --- glxinfo-radeon-Mesa-7.4.4 +++ glxinfo-radeon-Mesa-7.5 @@ -84,4 +84,4 @@ 0x85 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x86 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x87 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow -0x6a 32 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None +0x6a 32 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 Ncon
glxinfo is from http://bugs.freedesktop.org/attachment.cgi?id=28662
Difference in visual was to mark special composite visual nonconforming so applications won't try to pick it. The problem is not in Mesa as far as I can understand because from Mesa everything looks correct. So it might very well be any other component handling color map between Mesa and hw. The best approach to find the problem would be upgrading all components one by one and finding which upgrade breaks the color map. After that doing bisect would help to locate the problem. I haven't had tie to do it self yet because that test is going to be huge. Specially because I' using development distro so I would have to install stable distro to start from working state. So components that can take blame are mesa, xserver, ddx (xf86-video-ati), libdrm and drm kernel modules. Most likely to take the blame are one of 3 first.
(In reply to comment #4) > Being a regression for radeon in Mesa 7.5 since Mesa 7.4.4 [...] It's not (just) a Mesa regression. (And BTW this isn't really the same as bug 23337 as that one's about a double buffered app, which should be fixed in the current 7.4 and 7.5 branches) There's at least two separate issues: First, whereas the depth 32 GLX visual was traditionally separate from the 'normal' GLX visuals and marked as non-conformant, at some point (in 1.5 or 1.6 IIRC) xserver started mixing it in with the 'normal' GLX visuals and stopped marking it non-conformant. This lead to some double buffered apps (which is much more common than single buffered) picking up the depth 32 visual for their windows. This can't work correctly with DRI1 because windows using the depth 32 visual are always composited, even when there's no compositing manager. I fixed (or in hindsight, worked around) this in Mesa by marking the depth 32 visual as non-conformant again with DRI1. This in turn lead to the same apps picking up a direct color visual, that's bug 23337. So I pushed another fix/workaround to avoid the problem for double buffered apps, but this lead to single buffered apps picking up a direct color visual, which is what this bug is about. Note that while the depth 32 visual works correctly with DRI2, it's still not desirable because the compositing involves an additional copy for each frame. So one good way to avoid the whole problem should be to make xserver create the depth 32 GLX visual separately from the 'normal' GLX visuals again. Secondly, there's the problem that using a direct color visual results in a (mostly) black screen. This could be a bug in the X driver (unlikely, as it handles colour maps correctly otherwise), the X server, the apps or possibly even the window manager.
The glxgears issue is fixed in Mesa 7.5.1. Not sure if by accident or by intention though.
(In reply to comment #11) > The glxgears issue is fixed in Mesa 7.5.1. Not sure if by accident or by > intention though. See the reference to bug 23337 in comment #10. :)
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.