Fail to bind wayland interface after a shell surface is created

Zhao, Halley halley.zhao at intel.com
Wed Aug 7 17:47:35 PDT 2013


Some debugs show, after a shell surface is created, the future registry_handle_global (of wl_registry_listener) doesn't receive any interface.
There are some wl_registry_listener in the stack, if I skip wl_shell_get_shell_surface from the previous bind, it will be ok.

It seems: after one shell surface is created, wayland server will not broadcast its interface again. - even for the interfaces has nothing to do with wl_shell.

The background is:
In multimedia stack, wl_registry_listener is used in different layer:
app may use the shell surface to handle window stack.
Middleware (gst-vaapi) may use wl_shell (in case create wl_surface of its own), wl_output to get screen resolution for full-screen support, even wl_compositor to handle region_opaque
Video driver uses wl_drm interface to manage wl_buffer.

Usually it is ok (by gst-launch), because decoder runs first, which load video driver to setup wl_drm interface, then video render (vaapisink) create a wl_surface (and its shell surface) to display video frames.
However, that's not typical usage.
In real case, media player (app) connects to Weston, creates a wl_surface, then app set wl_display/wl_surface to middleware (vaapisink), vaapi sink will try to create shell_surface from the wl_surface.
Next, media pipeline starts to run, decoder loads video driver, driver doesn't receive any interface(wl_registry_listener) from Weston. Then fail.

(by the way, in this case, it's better app creates the shell surface, not vaapisink. Anyway, It doesn't impact the result)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130808/fb3b943b/attachment.html>


More information about the wayland-devel mailing list