Hi, On 13 January 2017 at 11:42, Pekka Paalanen <[email protected]> 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 _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
