weston: recommendations for implementing splashscreen in a custom shell?

[Matt Hoosier]

Hi,

I maintain a small Weston shell plugin for an an embedded use-case. On the
embedded device, the bootloader first paints a buffer and installs it as
the scanout buffer to the graphics hardware. At some point, userspace has
to take over responsibility for painting that background image. It seems to
make sense for that to be the compositor's job (in the shell plugin), since
it's in complete control of the ordering of surfaces shown by the
compositor.

Currently, my Weston shell plugin delegates the responsibility for painting
the userspace version of the splashscreen to a well-known client program
spawned internally from the shell plugin. This is similar in style to the
way that desktop-shell has a child process paint its background image. But
this approach ends up leading to a race condition: there's a momentary
flicker when the compositor has nothing but its default background to paint
because there are not yet any clients.This flickering phase comes to an end
when the process I spawned to paint the splashscreen image finishes
initializing and posts its first wl_buffer to the compositor. It's brief,
but the window of time during which the bootloader-provided splash is
overwritten by the (blank) default compositor output, is easily noticeable.

Is there an accepted technique for arranging that rich graphic content
(something loaded from a PNG or similar) can be available at the first
moment the compositor draws a frame and assumes responsibility for the DRM
hardware's contents? Perhaps:

* Directly instantiate Weston data structures such as weston_view and
weston_surface equivalent to what would have been done by a Wayland client
program, and hook them into the layer list? This seems to run into problems
about needing wl_client's and wl_resource's that really properly only come
from a client attached to the compositor.

* Keep the splash-image painting and buffer posting all in a child process,
but somehow delay the return of the shell plugin's module_init() function
until I observe the client post a buffer? This seems prone to deadlocking.

Regards,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161230/d3f1a55e/attachment.html>