Created attachment 78703 [details]
glxinfo

You are running git master? Could you please specify which git commit you are running?

Hi Martin

Thanks for your response. I never write this because I set it it in the dropdown list. Yes I use the latest git master...compiled it yesterday.

git commit: ce998ad37d8cf31e7b8a7f874074b8ea452e9daa

I saw it in the dropdown, I just wanted to be sure :-)

Could you please do a git bisect. A working commit as a start should be: 2dc68744d0b031ff5af44e872f49af226d449ee4 and I guess that 298721074d41e03e198a5c60d957014111b0eb0a is the commit which broke it.

I'm pretty sure it is.

@Johannes - you could also check where you fail by adding
if (depth == 32)
   qDebug() << "have foobar";

            if (buffer_size != depth && (buffer_size - alpha_size) != depth)
                continue;
if (depth == 32)
   qDebug() << "have buffersize";
            if (depth == 32 && alpha_size != 8)
                continue;
if (depth == 32)
   qDebug() << "have 8bit alpha";
            XVisualInfo *vi = glXGetVisualFromFBConfig(display(), configs[j]);
            if (vi == NULL)
                continue;
if (depth == 32)
   qDebug() << "have info";
            int visual_depth = vi->depth;
            XFree(vi);

            if (visual_depth != depth)
                continue;
if (depth == 32)
   qDebug() << "have info matching depth";
            int bind_rgb, bind_rgba;
            glXGetFBConfigAttrib(display(), configs[j], GLX_BIND_TO_TEXTURE_RGBA_EXT, &bind_rgba);
            glXGetFBConfigAttrib(display(), configs[j], GLX_BIND_TO_TEXTURE_RGB_EXT,  &bind_rgb);

            // Skip this config if it cannot be bound to a texture
            if (!bind_rgb && !bind_rgba)
                continue;
if (depth == 32)
   qDebug() << "have bound sth.";

Created attachment 78716 [details]
kwin --replace output with debug statements

Is it still necessary that I do this git bisect?

There's no matching visual for any 32bit FBConfig, though glxinfo suggests 0x0bb (multisampling) would.

I assume 32bit visuals were not required but matching 32/24 variants would have done.

-            if (visual_depth != depth)
+            if (visual_depth != depth && !(visual_depth == 24 && depth == 32))
                continue;

just a wild guess, though, not examined the patch.

(In reply to comment #9)
> -            if (visual_depth != depth)
> +            if (visual_depth != depth && !(visual_depth == 24 && depth ==
> 32))
>                 continue;

Hey Thomas

This fixed it!!! Thanks a lot!!!

@Fredrik
is a 32bit depth visual for a 32bit depth fb config actually mandatory?

@Johannes
please have a close look on whether there're visual bugs esp. with eg. blurring (below translucent windows) or translucent windows (oxygen-transparent, bespin, qtcurve?) in general.

If the visual depth isn't 32, then the visual isn't the ARGB32 visual.

The real issue is that we specify that glXChooseFBConfig() should only return visuals without caveats, but the glxinfo output shows that the 32-bit visual is marked as non-conformant.

If the line that says:

    GLX_CONFIG_CAVEAT,  GLX_NONE,

is changed to

    GLX_CONFIG_CAVEAT,  GLX_DONT_CARE,

it should fix the problem.

Tested blurring and translucent windows with oxygen-transparent and it looks very good. Can't see any problems.

see comment #12 for the actual issue.

@Fredrik
That's kinda unfortunate, since the order seems to be
GLX_CONFIG_CAVEAT where the precedence is:
GLX_NONE
GLX_SLOW_CONFIG <- "ewww"..
GLX_NON_CONFORMANT_CONFIG

So maybe we should test for GLX_NONE and GLX_NON_CONFORMANT_CONFIG explicitly (where i don't know what ncon would mean in this case or others and "slow" may be the better variant nevertheless if available?)

(In reply to comment #14)
> That's kinda unfortunate, since the order seems to be
> GLX_CONFIG_CAVEAT where the precedence is:
> GLX_NONE
> GLX_SLOW_CONFIG <- "ewww"..
> GLX_NON_CONFORMANT_CONFIG
> 
> So maybe we should test for GLX_NONE and GLX_NON_CONFORMANT_CONFIG
> explicitly (where i don't know what ncon would mean in this case or others
> and "slow" may be the better variant nevertheless if available?)

It's a theoretical problem since catalyst doesn't have any slow configs.
But yeah, it looks like maybe we shouldn't just rely on glXChooseFBConfig().

(Sorry for the late reply, I completely forgot about this bug until now)

Git commit 5edf346ad8a19b6989fad7290e599824dd2414f2 by Fredrik Höglund.
Committed on 11/06/2013 at 19:54.
Pushed by fredrik into branch 'master'.

kwin/glx: Relax the GLX_CONFIG_CAVEAT requirement

Allow drawable configs with caveats. The ARGB32 visual is marked as
non-conformant in the Catalyst driver.

M  +1    -1    kwin/glxbackend.cpp

http://commits.kde.org/kde-workspace/5edf346ad8a19b6989fad7290e599824dd2414f2

(In reply to comment #15)
> (Sorry for the late reply, I completely forgot about this bug until now)
Nevermind - tbvh: so did I :-\

@Martin
is it possible to have bugzilla send reminders, ie. have a checkbox that says "remind me in two weeks from now" one could tick on expecting a reply but not exactly "waiting for info"?

> @Martin
> is it possible to have bugzilla send reminders, ie. have a checkbox that
> says "remind me in two weeks from now" one could tick on expecting a reply
> but not exactly "waiting for info"?
yes there is the "whining" feature [1]. It can be used to send mails in a 
schedule. To Plasma mailing list some reports about regressions are sent. One 
could use a keyword to mark the bugs and send mails for all bugs with that 
keyword which haven't been changed over the last two weeks.

[1] http://www.bugzilla.org/docs/tip/en/html/whining.html