Destroying the xdg_surface is absolutely OK. I'm not sure why the Qt people consider it wrong.
On Wed, Sep 2, 2015 at 11:38 AM, Prabhu S <[email protected]> wrote: > 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 > > -- Jasper _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
