Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Display: add plymouth integration #1932

Draft
wants to merge 1 commit into
base: develop
Choose a base branch
from
Draft

Conversation

snowkat
Copy link

@snowkat snowkat commented May 16, 2024

This provides plymouth smooth transition support in SDDM::Display by telling Plymouth to deactivate and quit as the greeter is brought online.

This is similar in goal to #1013, although following the suggestion in #1013 (comment), the plan is to handle the transition from within the sddm daemon.

I wouldn't consider this PR complete, primarily due to the following lines in src/daemon/Display.cpp:

        switch (m_displayServerType) {
        case X11DisplayServerType:
            if (seat()->canTTY()) {
#if HAVE_PLYMOUTH
                // TODO: why can't rootful X11 use fetchAvailableVt?
                if (m_plymouthIsRunning) {
                    quitPlymouth(false);
                    m_plymouthIsRunning = false;
                }
#endif
                m_terminalId = VirtualTerminal::setUpNewVt();
            }

More specifically, the x11 display server type always creates a new VT, whereas x11-user and wayland will use fetchAvailableVt(). Is there a requirement for this to be the case?

My understanding of Plymouth is that to support a smooth transition, the DM needs to load on the active VT (i.e., same as the splash screen), so if there is a requirement, x11 display server type won't be able to support smooth transition support with this method.

This provides plymouth smooth transition support from SDDM::Display by
telling Plymouth to deactivate and quit as the greeter is brought
online.
@Vogtinator
Copy link
Contributor

More specifically, the x11 display server type always creates a new VT, whereas x11-user and wayland will use fetchAvailableVt(). Is there a requirement for this to be the case?

No. The VT handling code is a mess and needs to be redone, see #1896.

My understanding of Plymouth is that to support a smooth transition, the DM needs to load on the active VT (i.e., same as the splash screen), so if there is a requirement, x11 display server type won't be able to support smooth transition support with this method.

AFAICT it's the opposite: The greeter needs to start on another VT, to be able to switch in an instant.

@snowkat
Copy link
Author

snowkat commented May 17, 2024

AFAICT it's the opposite: The greeter needs to start on another VT, to be able to switch in an instant.

That would still cause a flicker, wouldn't it? Admittedly, the best documentation I've found is a 15-year-old mailing list post (https://lists.freedesktop.org/archives/plymouth/2009-June/000126.html), but it describes:

The way it works is instead of running "plymouth quit" we run "plymouth quit --retain-splash" which forces plymouth to keep the splash contents on screen and keep the vt in KD_GRAPHICS mode after plymouth exits. When in this mode the user won't be able to switch to other vts.

We then have a patch fo GDM which forces X to start on the active vt.

From what I can tell of the Plymouth and GDM sources, this is still the case.

@Vogtinator
Copy link
Contributor

AFAICT it's the opposite: The greeter needs to start on another VT, to be able to switch in an instant.

That would still cause a flicker, wouldn't it?

If the mode is the same, it should not. I don't get any flicker here using manual VT switching.

Admittedly, the best documentation I've found is a 15-year-old mailing list post (https://lists.freedesktop.org/archives/plymouth/2009-June/000126.html), but it describes:

The way it works is instead of running "plymouth quit" we run "plymouth quit --retain-splash" which forces plymouth to keep the splash contents on screen and keep the vt in KD_GRAPHICS mode after plymouth exits. When in this mode the user won't be able to switch to other vts.
We then have a patch fo GDM which forces X to start on the active vt.

From what I can tell of the Plymouth and GDM sources, this is still the case.

Ouch. Can we try a better way?

@snowkat
Copy link
Author

snowkat commented May 18, 2024

That would still cause a flicker, wouldn't it?

If the mode is the same, it should not. I don't get any flicker here using manual VT switching.

Heh, it would have been a good idea for me to test before saying that. Can confirm there's no flicker on my system, either.

Ouch. Can we try a better way?

Depends on your definition of a "smooth transition." If we're fine with not supporting the fade-in effect done by GDM and LightDM, the VT switch would be fine.

Arguably it'd be possible to have that effect even when switching the VT, but you'd already need the active VT open to get a "screenshot" of the splash.

@Vogtinator
Copy link
Contributor

Arguably it'd be possible to have that effect even when switching the VT, but you'd already need the active VT open to get a "screenshot" of the splash.

Plymouth could fade out, then after the VT switch sddm or the DE could fade in.

@snowkat
Copy link
Author

snowkat commented May 23, 2024

Plymouth could fade out, then after the VT switch sddm or the DE could fade in.

AFAICT Plymouth doesn't have a fade-out mechanism of its own. The DM seems to be expected to handle all parts of the transition, including animation.

Technically the two-step splash type could do this, but it's more meant to add a little flair when loading is complete, and none of the default themes using two-step use it for a fade-out effect.

@Zamundaaa
Copy link

Ouch. Can we try a better way?

With https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/313 the display server could read back the framebuffer and do a smooth transition that way

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants