It seems the root window is no longer using a double buffered GLX visual, causing a lot of programs to fail (compiz primarily). Drivers (e.g. ati and radeon) seem to go out of their way to make sure that a double buffered visual is the default, but their tweaks are abstracted away at some point. As there doesn't seem to be a direct connection between the visuals exported by the driver, and the visuals visible to X clients, I suspect that the new RandR 1.2 visual abstraction stuff is the culprit. Output from glxinfo: visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x25 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x27 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x28 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x29 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2a 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2b 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2d 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2e 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2f 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x30 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x31 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x32 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x4c 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 Ncon This does not change when I modify the driver (radeon) to export _only_ double buffered visuals. The root window also seems to select the first visual, which never seems to be double buffered.
Which versions of xserver and mesa is this with?
xorg-x11-server-Xorg-1.4.99.1-0.10.fc9 mesa-libGL-7.1-0.4.fc9
As I don't have this problem with upstream Git master branches, and Red Hat folks are making a lot of changes in this area, have you tried to sort this out downstream first?
No, I haven't. I rarely get a problem caused by Red Hat patches, so I tend to go to the source first. :) Could you share a dump from a radeon machine you have for comparison? Also, what is the odd behaviour here? The lack of relation between driver visuals and those seen by the X clients? The order of visuals? The one selected for the root window?
Hmm... It seems a recent update has fixed the problem. I now have this: 3 GLX Visuals visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x51 32 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 16 GLXFBConfigs: visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x52 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x53 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x54 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x55 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x56 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x57 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x58 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x59 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x5a 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x5b 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x5c 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x5d 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x5e 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x5f 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x60 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x61 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow So the root window has selected a double-buffered visual. Feel free to close this bug and have a look at the following problem, bug 13331, instead. ;)
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.