Plymouth

[plfiorini]

Some notes from IRC:

<plfiorini> apachelogger: does plymouth have some sort of protocol that needs to be used by the DM or it's just Xorg not running with -background none and possibly other args plus vt.handoff?
<plfiorini> oh and the sddm.service needs to be after plymouth-quit.service
<apachelogger> plfiorini: the gist of integration: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/kdebase-workspace/lucid/view/head:/debian/patches/kubuntu_34_kdm_plymouth_transition.diff
<apachelogger> basically use plymouth binary to talk to daemon, query vt it is using, use that vt, tell plymouth to quit but not repaint the vt before x starts
<apachelogger> as for the systemd units: I am not sure what plymouth quit does, but on upstart from what I remember the respective DM units would call plymouth quit when the DM unit actually is not intended to start (e.g. cmdline contains text argument) and conversively the plymouth-stop upstart unit would call plymouth quit when an unsupported DM is started
<apachelogger> *not sure what plymouth-quit.service does* ^^
<apachelogger> upstart nonesense FTR http://paste.ubuntu.com/7638410/
<apachelogger> plfiorini: I am reasonable certain for the systemd stuff you can just look at any of the other major DMs, I think pretty much every distribution has plymouth transition support
<plfiorini> apachelogger: i will look at gdm code but calling plymout quit will be handled by the systemd unit and that's less code to write :P
<apachelogger> plfiorini: you still need to call quit from inside sddm
<apachelogger> plymouth quit --retain-splash
<apachelogger> that forces plymouth to not repaint the VT
<plfiorini> apachelogger: ok in fact the plymouth-quit.service doesn't call plymouth quit with --retain-splash so that might not work as expected unless it's the default now
<apachelogger> plfiorini: quit without argument will repaint the VT (i.e. will go black), while with retain it will nto repaint and simply preserve whatever the last render run looked like
<apachelogger> the problem is that if a DM doesn't implement plymouth support plymouth may run on VT1 and DM on VT2 and then you'd have the last render of plymouth hanging around on VT1, that's what plymouth-quit.service is supposed to prevent, well, and the fact that you don't want a useless plymouthd binary running all the time ^^

[xiangzhai]

Hi @plfiorini

sddm does not support plymouth smooth transtion

And I am trying to implement it learn from lightdm ;-)

lightdm dbus interface

In the lightdm main entry point

It provides system-bus interface if run it as root, for examplesudo systemctl start ligthdm-plymouth.service
getuid() == 0 ? system-bus : session-bus

If the system or session bus created successfully, it calls bus_acquired_cb and register Seat Modules, such as XLocal, XRemote, Unity and sort of protocols, then start the DisplayManager, quit the active Plymouth:
getuid() == 0 ? system-bus : session-bus -> bus_acquired_cb -> seat_register_module -> display_manager_start -> plymouth_get_is_active -> plymouth_quit

Different like sddm, lightdm still provides some Methods to add seat (AddSeat is deprecated):
getuid() == 0 ? system-bus : session-bus -> AddLocalXSeat Method -> display_manager_add_seat

Here I do not discuss mir or mir-container session type!

1. create X server
2. get vt
3. check plymouth active status and has active vt
4. do smooth transition

seat-xlocal -> seat_xlocal_create_display_server -> create_x_server -> get_vt -> plymouth_get_is_active && plymouth_has_active_vt -> display_server_ready_cb -> plymouth_quit
-> play_server_transition_plymouth_cb -> plymouth_get_is_running -> plymouth_quit
-> plymouth_deactivate
-> plymouth_get_is_active -> plymouth_quit

lightdm-plymouth service

Conflicts=getty@tty1.service plymouth-quit.service

After=systemd-user-sessions.service getty@tty1.service plymouth-quit.service

Please have a look at my implementation Thanks a lot!

Regards,
Leslie Zhai

[xavier83]

Any update on this issue?

[plfiorini]

@xavier83 plymouth should be already supported with systemd, what is left is support for non systemd systems which sadly require to manually handle plymouth.

[xavier83]

I was wondering that there is no sddm-plymouth.service provided, as suggested here for gdm like gdm-plymouth.service. btw, is it recently fixed? probably the one in arch is a bit outdated(sddm-0.13)

[plfiorini]

@xavier83 i suspect the wiki is not up to date, sddm.service has After=... plymouth-quit.service like gdm.service had back then (I copied it from gdm) and the X server is started with -noreset so you can smothly fade between plymouth and sddm at startup already.

[plfiorini]

...aaaand of course it doesn't work nicely on Fedora but works on Arch

[alex94cp]

...aaaand of course it doesn't work nicely on Fedora but works on Arch

Why is that?

[vlig]

@plfiorini so I must to create sddm-plymouth.service by myself? Can you show yours one please? I just cant understand what to do for smooth transitions in Arch+SDDM... 😕
I disabled plymouth few days ago because of that, but want to try it again. Thanks.

[ghost]

@vlig I came close to a smooth transition with sddm (no flickering & no black screen) by changing /usr/lib/systemd/system/sddm-plymouth.service

[Unit]
Description=Simple Desktop Display Manager
Documentation=man:sddm(1) man:sddm.conf(5)
Conflicts=getty@tty1.service plymouth-quit.service
Wants=plymouth-deactivate.service
After=systemd-user-sessions.service getty@tty1.service plymouth-deactivate.service plymouth-quit.service

[Service]
ExecStart=/usr/bin/sddm
Restart=always

[Install]
Alias=display-manager.service

Make a custom plymouth package if you are on Arch to avoid getting it overwritten by an update. I'll submit the changes to the AUR in a few.

Edit 09/28 8PM: It seem that it broke plymouth.poweroff because of the way sddm exits. Will investigate...
Edit2 09/28 9PM: Confirmed, plymouth-quit-wait.service wait definitively which broke further plymouth actions. Fixing...
Rgds,

[J5lx]

Actually the files in /usr/lib/systemd/ aren't supposed to be changed by the user. Instead you should put your overrides in /etc/systemd/, which is used specifically for that purpose, so package updates won't undo the changes. See systemd.unit(5) for details. I hope this helps :)

[vlig]

@NainKult thanks, but no difference. Still squared only animated part, on black flickering screen with "starting version 231" and blinking cursor below. Switch off back to native textboot. I'm using nvidia driver (not nouveau), maybe its because of non-fbdev?..

[hexadecatrienoic]

With the current service file, the VT flickers to black between plymouth-quit.service starting and plymouth-sddm.service starting. If plymouth-quit.service is never run, Plymouth drops directly into SDDM without showing the VT. Is there a way to run plymouth-quit.service after SDDM is already running and drawing?

[aviallon]

@NainKult You are a genius ! Thanks a lot ! Perfectly smooth transition now 👍 😄
Should be added in next release.

[romanlex]

@NainKult thx it's work properly

Maybe anybody known how make smooth from rEFInd to plymouth)))?

[romanlex]

@NainKult @aviallon On my Arch Linux adding plymouth-quit.service to Conflicts section has bad sideeffect
I can't change tty Ctrl+Alt+F(2-7) bacause have message with unnstopable job(

[aviallon]

You're right. I'm currently trying to solve this issue. Le dim. 22 avr. 2018 à 14:43, Roman O <notifications@github.com> a écrit :

…

@NainKult <https://github.com/NainKult> @aviallon <https://github.com/aviallon> On my Arch Linux adding plymouth-quit.service to Conflicts section has bad sideeffect I can't change tty Ctrl+Alt+F(2-7) bacause have message with unnstopable job( — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#196 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHIgjAiWcZhSH2a1OvvQODJ3nTDSlFWmks5trHrigaJpZM4CD_i2> .

[romanlex]

@aviallon could you write in this issues about how solve this?

[aviallon]

Okay found out how to solve this : we just add plymouth-quit-wait.service in Conflict

[romanlex]

@aviallon now in the system process always wait plymouthd with 1% CPU usage 👿

I think this proccess must be done after sddm start

And when I trying shutdown the system I don't see plymouth, only console output of systemd

[aviallon]

I got the same problem on my computer. Currently working on a fix, but that's not simple, since it must quit after sddm is ready. And I don't know if sddm provides such an information. I'll keep you updated about my progress.

[aviallon]

The easiest would be a service which kills Plymouth after some time, like 30s.

[aviallon]

@romanlex Okay, found a dirty but working workaround : create a script in /usr/lib/sddm/quit-plymouth with :

#!/bin/bash

/bin/sleep 15
/usr/bin/plymouth quit --retain-splash

then modify sddm-plymouth.service and add ExecStartPost=/usr/lib/sddm/quit-plymouth after the ExecStart line.
Don't forget to chmod a+x /usr/lib/sddm/quit-plymouth and tada plymouth quits after some time.
But I'll still search for a cleaner method though.

[random404-bot]

any news ? i try to configure for myself

[gulafaran]

nothing new on this?

[ugjka]

No scripts needed :)

systemctl edit --full sddm-plymouth.service

[Unit]
Description=Simple Desktop Display Manager
Documentation=man:sddm(1) man:sddm.conf(5)
Conflicts=getty@tty1.service plymouth-quit.service
Wants=plymouth-deactivate.service
After=systemd-user-sessions.service getty@tty1.service plymouth-deactivate.service plymouth-quit.service

[Service]
ExecStart=/usr/bin/sddm
ExecStartPost=/bin/sleep 30
ExecStartPost=/usr/bin/plymouth quit --retain-splash
Restart=always

[Install]
Alias=display-manager.service