On Fri, 30 Dec 2016 15:07:38 -0600 Matt Hoosier <[email protected]> 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
pgpNeFcSsXS8o.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
