With the below change in simple-shm.c, weston+fbdev backend will be stuck
and other compositors may work. It depends on compositor implementation and
the actual behavior supposed to be is not clearly defined. I'm still trying
to identify fix in weston, it looks like state information is overwritten
before idle_repaint is being called.
window->callback = wl_surface_frame(window->surface);
wl_callback_add_listener(window->callback, &frame_listener, window);
wl_surface_commit(window->surface);
+ wl_surface_attach(window->surface, 0, 0, 0);
+wl_surface_damage(window->surface,
0, 0, 0, 0);
+ wl_surface_commit(window->surface);
But the cause is wl_buffer set to null from the client and as per
discussions it is not recommended. So we are trying to get this issue fixed
in the QTWayland plugin.
https://bugreports.qt.io/browse/QTBUG-47902
Some proposal to hide the surface would be greatly appreciated.
Below the discussion in the thread.
"I did a quick check on gtk+ and it seems that in:
gdk_wayland_window_hide_surface (GdkWindow *window)
they actually destroy* the surface ... which sounds wrong as well?
I tried to dig into EFL code as well .. but gave up due to not finding the
implementation of efl_gfx_visible_set (if someone can either point to that
or find the actual function to look at, that would be nice)"
On Mon, Aug 24, 2015 at 4:35 AM, Pekka Paalanen <[email protected]> wrote:
> On Fri, 21 Aug 2015 19:04:11 -0500
> Prabhu S <[email protected]> wrote:
>
> > Below is the case where I'm getting stuck with the actual test case.
> > Wondering why there is no callback [email protected] or
> > [email protected]
> > The EGL implementation depends on these callback/buffer release.
>
> You will not get [email protected], because the NULL wl_buffer has
> overwritten the other wl_buffer, leaving the wl_surface without any
> content, which makes it disappear from screen. Frame callbacks are not
> intended to be posted for non-visible wl_surfaces.
>
> You should get [email protected] though. I bet you actually do get
> it, but something else is stopping the incoming Wayland events from
> being dispatched. See:
> http://lists.freedesktop.org/archives/wayland-devel/2014-April/014121.html
> and "protocol dumpers" on:
> http://wayland.freedesktop.org/extras.html
>
> My wild guess would be that something is blocking, waiting on the frame
> callback, likely EGL. It's not really EGL's bug but the application's
> (or Qt).
>
> > Also noticed if the valid buffer is attached immediately after null
> buffer,
> > everything is fine, so most of the time it is unnoticed. If the frame is
>
> Hmm, no, things should not be fine in that case. Well, it depends on
> what role the wl_surface you are committing on has, but the very least
> it may cause flicker.
>
> You definetely want to get rid of that null attach. You do not want to
> just ignore it.
>
> > complex, egl will attach after null frame.
> >
>
> It sounds like your application is committing to the wl_surface behind
> Qt's back somehow, and it only works occasionally by luck.
>
> > I will keep debug if any other race conditions in my implementation.
> >
> > [3741557.293] -> [email protected](new id wl_callback@25)
> > [3741557.476] -> [email protected](wl_buffer@29, 0, 0)
> > [3741557.676] -> [email protected](0, 0, 800, 480)
> > [3741557.906] -> [email protected]() <=EGL
> > [3741558.500] -> [email protected](nil, 0, 0) <=QTWayland
> > [3741558.604] -> [email protected]() <=QTWayland
> > stuck
> >
> >
> > On Fri, Aug 21, 2015 at 12:16 PM, Jasper St. Pierre <
> [email protected]>
> > wrote:
>
> ...
>
> > > However crazy it is, the logic sort of makes sense -- the "frame"
> > > event is guaranteed to be called once a frame when the surface content
> > > is painted and shown on the screen. When there's no surface content,
> > > it isn't painted, so the frame event isn't called.
> > >
> > > I'm not sure what you mean about a buffer release event -- you never
> > > attached a buffer to begin with, so I can't imagine how you'll get an
> > > event on it.
> > >
> > > On Fri, Aug 21, 2015 at 10:03 AM, Prabhu S <[email protected]>
> wrote:
> > > > Hi,
> > > > Based on the wayland protocol specification for wl_surface::attach
> > > >>>If wl_surface.attach is sent with a NULL wl_buffer, the following
> > > >>> wl_surface.commit will remove the surface content.
> > > >
> > > > Wondering if wl_surface_attach called with wl_buffer=NULL, will
> there be
> > > any
> > > > wl_buffer release event or frame callbacks?
> > > >
> > > > Modified the redraw in simple-shm.c as below and not receiving any
> > > callback
> > > > or buffer release. It just got stuck.
> > > > The same thing is being done in qtwayland to hide the surface and it
> is
> > > > getting stuck. Some help to check this case would be helpful.
> > > >
> > > > static int odd = 1;
> > > > if(odd == 1){
> > > > wl_surface_attach(window->surface, buffer->buffer, 0, 0);
> > > > wl_surface_damage(window->surface,
> > > > 20, 20, window->width - 40, window->height
> -
> > > 40);
> > > > odd = 0;
> > > > }
> > > > else{
> > > > wl_surface_attach(window->surface, 0, 0, 0);
> > > > wl_surface_damage(window->surface,
> > > > 0, 0, 0, 0);
> > > > odd=1;
> > > > }
> > > >
> > > >
> > > >
> > > > [823379.816] -> [email protected]_surface(new id wl_surface@3)
> > > > [823379.949] -> [email protected]_xdg_surface(new id xdg_surface@7,
> > > > wl_surface@3)
> > > > [823380.120] -> [email protected]_title("simple-shm")
> > > > [823380.244] -> [email protected](0, 0, 250, 250)
> > > > [823381.333] -> [email protected]_pool(new id wl_shm_pool@8, fd 5,
> > > 250000)
> > > > [823381.561] -> [email protected]_buffer(new id wl_buffer@9, 0,
> 250,
> > > > 250, 1000, 1)
> > > > [823381.870] -> [email protected]()
> > > > [823384.880] -> [email protected](wl_buffer@9, 0, 0)
> > > > [823385.095] -> [email protected](20, 20, 210, 210)
> > > > [823385.317] -> [email protected](new id wl_callback@10)
> > > > [823385.443] -> [email protected]()
> > > > [823388.852] [email protected]_id(8)
> > > > [823388.979] [email protected](0, 0, array, 4)
> > > > [823389.238] -> [email protected]_configure(4)
> > > > [823401.773] [email protected]_id(10)
> > > > [823401.908] [email protected]()
>
> This is the buffer release you expected. Note, that release can come
> before the next buffer is attached, like here. This is typical for a
> compositor using GL while the client is using software rendering
> (wl_shm). Things can differ if the client is using GL or if the
> compositor is not using GL.
>
> > > > [823401.991] [email protected](4056537)
> > > > [823404.239] -> [email protected](nil, 0, 0)
> > > > [823404.442] -> [email protected](0, 0, 0, 0)
> > > > [823404.663] -> [email protected](new id wl_callback@10)
> > > > [823404.792] -> [email protected]()
> > > > [823406.292] [email protected](0, 0, array, 5)
> > > > [823406.524] -> [email protected]_configure(5)
>
> Just like Jasper explained, wl_callback@10 will not be signalled until
> the surface is composited the next time. Without a wl_buffer, it won't
> get composited. The spec for wl_surface.frame says:
>
> "A server should avoid signalling the frame callbacks if the
> surface is not visible in any way"
>
> Committing a NULL wl_buffer causes the wl_surface to be not visible.
>
>
> Thanks,
> pq
>
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
