weston: recommendations for implementing splashscreen in a custom shell?

[Pekka Paalanen]

On Fri, 30 Dec 2016 15:07:38 -0600
Matt Hoosier <matt.hoosier at gmail.com> wrote:

> 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.

Hi,

indeed you have identified the problems with your ideas.

Weston's desktop-shell uses an event from the helper client to signal
when it is ready, and fades in only after that (if the fade-in
animation is enabled). I understand you want to keep the boot splash
image instead, but keep that event in mind.

I think it should be possible for Weston to scrape the current image on
an active output when it starts up, but so far it has not been
implemented. I have a vague recollection that something with the Xorg
server (the video DDXen?) might do a similar thing, if you need an
example.

If you actually manage to scrape the original boot splash, you can have
Weston keep showing it until your helper client is ready to take over.

It might even be as simple as postponing Weston's first modeset until
the helper client is ready, since existing screen contents should stay
put until then, IIRC.

In any case, I believe it requires some work with the DRM-backend
and/or libweston core. I think it might be nice to add a libweston
function that the shell code needs to call before a backend actually
starts driving the outputs. I can't say off-hand how that
implementation should look like, though.

Scraping the original boot picture would only be necessary if one
wanted to do e.g. a cross-fade to the desktop.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170113/7bc7da7c/attachment.sig>