From Grub to Shutdown project update

[Martin Graesslin]

On Monday, August 1, 2016 10:49:16 AM CEST Harald Sitter wrote:
> On Mon, Aug 1, 2016 at 8:35 AM, Martin Graesslin <mgraesslin at kde.org> wrote:
> > On Monday, July 25, 2016 12:24:56 PM CEST Jens Reuterberg wrote:
> >> KSPLASH
> >> Ksplash is removed in favour for two clear effects, one is the "fade to
> >> desktop" already present in Kwin, the other is an effect where SDDM fades
> >> in a very specific way. (the SDDM interface fades leaving only the
> >> chosen logged in users avatar fading slightly slower (can be seen in the
> >> thumbnail gif named "SDDMfade")
> >> Essentially SDDM fades, and then directly as part of it visually, a fade
> >> to
> >> desktop.
> > 
> > Removing KSplash directly breaks the login effect (I assume that's what is
> > meant with "fade to desktop"). It gets activated by the ksplash window
> > closing and then fades out the ksplash window.
> > 
> > I don't see how this can be done in a Wayland world. (Neither do I see how
> > this can be done in a X11 world). To explain: When switching from SDDM to
> > KWin/Wayland, KWin takes over the display, SDDM is no longer able to
> > render to it.
> 
> Deceit and trickery! ;)
> 
> I think the important bit is that visually it needs to look like SDDM
> is doing the lifting, whether or not it actually does is
> inconsequential to the visual result.
> 
> 3 ways this can be done:
> 
> 1) Fading to black: SDDM fades to black before starting the session.
> The first thing the session does is paint black, launches something
> that sits on top of everything else (a ksplash, if you will ;)), this
> something continues to be black until it fades to desktop. This
> obviously doesn't work on HDD so let's ignore this option because it
> is stupid.
> 
> The other 2 options imply an interaction between the DM and something
> in the session.
> 
> 2) Now you see me... now you don't: The last thing SDDM does is take a
> "screenshot" of itself. It puts that into some file with a very unique
> and predictable path. A something in the session (again, a ksplash, if
> you will) picks up the file and draws it on screen and then does some
> animation (which will natrually be limited). Obvious concern here is
> that this won't be able to properly reflect resolution switches since
> all that can be done in the session is image manipulation at this
> point. On the plus side it should be fairly cheap to implement and
> might be a good first step.
> 
> 3) Meta-meta-meta-programming: Our SDDM theme is QML, KSplash is QML.
> Before session start the theme either serializes its dataset into some
> file with a predictable path, a something in the session now loads the
> dataset AND SDDM's actual QML files and entirely replicates the state
> the UI was in on the SDDM. A variation of this, which might well be
> harder to do, is fully fixing up the QML files. Namely the theme
> itself dumps its own QML but instead of Label { text: variable } it
> uses it's state i.e. Label { text: "Kitten" }. By rendering the theme
> QML in the session we can accurately handle whatever happens during
> session startup, it is for all intents and purposes like a shared code
> base for SDMD and KSplash at that point. Whether or not this actually
> has use over option 2 I can't say, it certainly sounds cooler in my
> mind ;)

On X11 the option 2 could be simplified: sddm renders it's last screenshot into 
the root window, when ksplash starts it grabs the content from the root window 
and uses that as the background. But the same problem as you already wrote: 
it's problematic with multi-screen and resolution changes. Also this approach 
only works if there is no compositor running (which is true at the early 
startup phase).

> 
> Seeing as I know nothing about wayland I am not sure if this can be
> done better there.

It's pretty much the same on Wayland. The startup in KWin is to render a black 
screen to perform the initial mode setting. That could also be a different 
image.

From that time on the compositor is running which always renders a black 
background and the windows on top of it.

> 
> (Also random note: SDDM's UI is run as an own process 'sddm-greeter',
> I suppose one could actually have that "jump" outputs? I.e. one minute
> it's on sddm's X, the next it is on the session X)

That can only work if it's still the same X. If a new X is started for the 
user session it won't work, neither for switching to Wayland.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20160801/fdcb930f/attachment-0001.sig>