Bug 317972 - dektop effects don't work with OpenGl, but direct rendering works is enabled using catalyst
Summary: dektop effects don't work with OpenGl, but direct rendering works is enabled ...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Unclassified
Component: general (show other bugs)
Version: git master
Platform: Archlinux Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-07 11:48 UTC by Johannes K.
Modified: 2013-06-12 06:55 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
glxinfo (28.13 KB, text/plain)
2013-04-07 11:48 UTC, Johannes K.
Details
kwin --replace output with debug statements (11.39 KB, text/plain)
2013-04-07 21:24 UTC, Johannes K.
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes K. 2013-04-07 11:48:05 UTC
Hi

OpenGL Desktop effects used to work very will with catalyst. But suddenly only XRender works.
"Kwin --replace" gives me:

kwin(1374) kdemain: KWIN_DIRECT_GL set, not forcing LIBGL_ALWAYS_INDIRECT=1
kwin(1374) KWin::Options::loadCompositingConfig: Compositing forced to OpenGL mode by environment variable
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
kwin(1374)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from "/var/tmp/kdecache-joker/ksycoca4"
kwin(1374) KWin::Compositor::slotCompositingOptionsInitialized: Initializing OpenGL compositing
kwin(1374): Could not find a framebuffer configuration for depth 32. 
kwin(1374) KWin::OpenGLBackend::setFailed: Creating the OpenGL rendering failed:  "Could not initialize the drawable configs" 
kwin(1374): Failed to initialize compositing, compositing disabled 
kwin(1374): Consult http://techbase.kde.org/Projects/KWin/4.0-release-notes#Setting_up 

Attached you can find the output of glxinfo.
I hope you can help me...

Johannes

Reproducible: Always
Comment 1 Johannes K. 2013-04-07 11:48:57 UTC
Created attachment 78703 [details]
glxinfo
Comment 2 Martin Flöser 2013-04-07 13:16:16 UTC
You are running git master? Could you please specify which git commit you are running?
Comment 3 Johannes K. 2013-04-07 19:41:51 UTC
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.
Comment 4 Johannes K. 2013-04-07 20:01:56 UTC
git commit: ce998ad37d8cf31e7b8a7f874074b8ea452e9daa
Comment 5 Martin Flöser 2013-04-07 20:02:27 UTC
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.
Comment 6 Thomas Lübking 2013-04-07 20:09:13 UTC
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.";
Comment 7 Johannes K. 2013-04-07 21:24:50 UTC
Created attachment 78716 [details]
kwin --replace output with debug statements
Comment 8 Johannes K. 2013-04-07 21:27:46 UTC
Is it still necessary that I do this git bisect?
Comment 9 Thomas Lübking 2013-04-07 21:49:08 UTC
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.
Comment 10 Johannes K. 2013-04-08 08:42:29 UTC
(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!!!
Comment 11 Thomas Lübking 2013-04-08 11:21:49 UTC
@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.
Comment 12 Fredrik Höglund 2013-04-08 21:54:36 UTC
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.
Comment 13 Johannes K. 2013-04-09 15:30:02 UTC
Tested blurring and translucent windows with oxygen-transparent and it looks very good. Can't see any problems.
Comment 14 Thomas Lübking 2013-04-09 17:54:47 UTC
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?)
Comment 15 Fredrik Höglund 2013-06-11 18:43:37 UTC
(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)
Comment 16 Fredrik Höglund 2013-06-11 18:48:43 UTC
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
Comment 17 Thomas Lübking 2013-06-11 19:36:02 UTC
(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"?
Comment 18 Martin Flöser 2013-06-12 06:55:29 UTC
> @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