<div dir="ltr"><span style="font-size:12.8px">Hi,</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">* Directly instantiate Weston data structures such as weston_view and weston_surface equivalent to what would have been done by a <span class="gmail-il">Wayland</span> 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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">* 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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Regards,</div><div style="font-size:12.8px">Matt</div></div>