Re: weston: recommendations for implementing splashscreen in a custom shell?
On Fri, Jan 13, 2017 at 5:50 AM, Daniel Stone wrote: > 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. > Yes, I'd be interested to see whatever you come up with there. That sounds like exactly the expressiveness I was looking for. -Matt ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: weston: recommendations for implementing splashscreen in a custom shell?
Hi, On 13 January 2017 at 11:42, Pekka Paalanen 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 wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: weston: recommendations for implementing splashscreen in a custom shell?
On Fri, 30 Dec 2016 15:07:38 -0600 Matt Hoosier 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 wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
weston: recommendations for implementing splashscreen in a custom shell?
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. Regards, Matt ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
