[Cogl] Is there an X window named "." created when using Cogl/Clutter with GLES/EGL/X11?

Neil Roberts neil at linux.intel.com
Wed Apr 16 03:28:59 PDT 2014


Hi,

You should be able to make Clutter use a 24-bit visual by including
clutter/x11/clutter-x11.h and calling the following before clutter_init
is called:

  clutter_x11_set_use_argb_visual (FALSE);

However, that should be the default anyway so it is a bit surprising
that Clutter is using a 32-bit visual. Are you sure that the foreign
window you are creating is 24-bit and that you are not calling
clutter_x11_set_use_argb_visual(TRUE) somewhere accidentally?

Regards,
- Neil

Reza Ghassemi <reza.robin1 at gmail.com> writes:

> Hi Robert,
> It turns out the problem occurring stems from an issue with our creation of
> the X window and use of the clutter_x11_set_stage_foreign interface.  We've
> encountered both fatal and non-fatal issues when this routine returns FALSE:
>
> Our code:
>   if (clutter_x11_set_stage_foreign(CLUTTER_STAGE(stage), XWIN) == FALSE)
>     LOG_WARN(logger, "Failed to set foreign X window.");
>
> We thought that a depth mismatch between the foreign window (our root
> window is 24 bpp and we are using CopyFromParent to create it) and the
> clutter initialized depth was *non*-*fatal *because everything seemed to
> work.  However, what was really happening was that the foreign window was
> not set and clutter was creating its own window at 32 bpp.  So there are
> two windows when there should be one. This caused problems trying to
> hide/suspend the app because the second window was still on top eating
> input.
> As a hack to try to get it working we commented out the return FALSE below
> and then the foreign window is set successfully and the app seems to behave
> correctly with one window.  Can you think of any gotchas from doing this?
>  We're out of time to dig much deeper.
>
> Thanks,
> Reza
>
> We are using clutter 1-14.2. Will upgrade someday.
> clutter-stage-x11.c:
>
>   if (depth != xvisinfo->depth)
>     {
>       g_warning ("The depth of the visual of the foreign window is %d, but "
>                  "Clutter has been initialized to require a visual depth "
>                  "of %d",
>                  depth,
>                  xvisinfo->depth);
>     /*  return FALSE; */
>     }
>
>
> On Tue, Apr 15, 2014 at 11:59 AM, Robert Bragg <robert at sixbynine.org> wrote:
>
>> Hi Reza,
>>
>> Cogl creates a dummy 1x1 window positioned at (-100,-100) that is
>> never mapped by Cogl. This is created because GLX doesn't let you
>> interact with a GL context unless it is associated with a drawable and
>> we want to interact with GL before your application explicitly creates
>> a window/stage.
>>
>> I'm not sure why you would ever be seeing this window though, since it
>> is never mapped by Cogl, so maybe the window you are seeing is created
>> by something else. Also Cogl doesn't set any window manager hints to
>> give that dummy window a title of "." so that also makes me guess this
>> dummy window isn't made by Cogl. B.t.w how are you determining that
>> the window is named "." are you seeing a window manager frame and
>> title for that window? That certainly shouldn't happen for the Cogl
>> dummy window, even if it did some how get mapped then the window is
>> marked as override-redirect and so the window manager should basically
>> ignore it.
>>
>> Perhaps you can set some breakpoints on XCreateWindow,
>> XCreateSimpleWindow and XMapWindow to see what other things are
>> creating X windows and mapping them.
>>
>> Regards,
>> Robert
>>
>>
>> On Tue, Apr 15, 2014 at 7:36 PM, Reza Ghassemi <reza.robin1 at gmail.com>
>> wrote:
>> > Hi,
>> > We have an issue where an X window named "." of the same size and
>> position
>> > of our main window is created when launching our Clutter app and we don't
>> > know who is creating it.  On this system we need to unmap this window
>> along
>> > with the main window when our app suspends itself to avoid input going to
>> > this "dummy" which appears to be below our main window.  I see some code
>> in
>> > the WGL implementation referring to a window named "." but not in EGL.
>>  Any
>> > ideas?
>> >
>> > We're kinda in a hurry to fix this.
>> >
>> > Thanks,
>> > Reza
>>
> _______________________________________________
> Cogl mailing list
> Cogl at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/cogl


More information about the Cogl mailing list