weston: recommendations for implementing splashscreen in a custom shell?

[Daniel Stone]

Hi,

On 13 January 2017 at 11:42, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 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.

I'd be 100% in favour of this approach: delaying the original modesets
until the shell indicates that the scene graph as it stands is totally
quiescent. I'm working along those lines as we speak for atomic
anyway: we need to do one single modeset covering all outputs, rather
than individually. I'll try to keep that in mind when doing that and
CC you both on the patch which actually implements that.

(Skip the following paragraph if you don't care about KMS details.)

The reason I need to is because currently, we schedule every output
repaint independently, which sets the configuration for that output
only. With the old drmModeSetCrtc API, moving a connector to a CRTC
was possible in a single hop: if you started with CRTC A -> connector
B and CRTC Y -> connector Z, then Weston decided to use CRTC A ->
connector Z and CRTC Y -> connector B, you could do this with one
call. Setting CRTC A would disable CRTC Y as its connectors had
disappeared. With atomic, you need to explicitly add CRTC Y in, rather
than it implicitly being disabled. I'd mostly managed to steer clear
of it, but this week something changed such that Mutter and the kernel
pick a different CRTC/connector pairing than Weston does.

We can hack around this by trying to keep an existing CRTC/connector
pairing where possible, which is desirable for performance reasons if
nothing else anyway. But we do need to switch to a single atomic
modeset for all outputs, not just for performance but also so we can
perform reconfigurations which were previously not possible in
intermediate steps.

Cheers,
Daniel