SDDM & KDE Plasma both run on wayland but SDDM still switch tty

niquedegraaff · 2023-03-20 22:24:43

I've got both SDDM and KDE working in Wayland, which is great. But I for some reason, SDDM is still opening a new TTY on login, which causes a instant ugly black screen, and makes the kde plasma splash irrelevant because it's already gone before the tty was able to print it's content to the screen.

KDE is running in wayland as per echo $XDM_SESSION_TYPE outputs wayland. I've also checked (from another tty) if SDDM is really running on wayland, and yes, it's XDM_SESSION_TYPE env variable was also set to wayland

I've set the CompositorCommand=kwin_wayland --no-lockscreen setting under the [Wayland] section in the /etc/sddm.conf file (which is the highest priority file) as stated in the ArchWiki.

So, I'm 1000000% sure, both are running in kwin_wayland.

Now, why is SDDM still switching tty after successfully authenticated and load in a whole new kwin_wayland session?
This should not happen, as SDDM is running in wayland, and it should just close it's own window in current kwin_wayland session and fire plasma and then exit -> Creating a smooth transition between login manager and desktop!

This is my /etc/sddm.conf file

[Autologin]
Relogin=false
Session=
user=

[General]
DisplayServer=wayland
GreeterEnvironment=QT_WAYLAND_SHELL_INTEGRATION=layer-shell
InputMethod=maliit-keyboard
Numlock=on
HaltCommand=/usr/bin/systemctl poweroff
RebootCommand=/usr/bin/systemctl reboot

[Theme]
Current=breeze
DisableAvatarsThreshold=7
EnableAvatars=true
FacesDir=/usr/share/sddm/faces
ThemeDir=/usr/share/sddm/themes

[Users]
DefaultPath=/usr/local/sbin:/usr/local/bin:/usr/bin
HideShells=
HideUsers=
MaximumUid=60000
MinimumUid=1000
RememberLastSession=true
RememberLastUser=true
ReuseSession=false

[Wayland]
CompositorCommand=kwin_wayland --no-global-shortcuts --no-lockscreen --inputmethod maliit-keyboard 
EnableHiDPI=true
SessionCommand=/usr/share/sddm/scripts/wayland-session
SessionDir=/usr/share/wayland-sessions
SessionLogFile=.local/share/sddm/wayland-session.log

[X11]
DisplayCommand=/usr/share/sddm/scripts/Xsetup
DisplayStopCommand=/usr/share/sddm/scripts/Xstop
EnableHiDPI=true
SessionCommand=/usr/share/sddm/scripts/Xsession
SessionDir=/usr/share/xsessions
SessionLogFile=.local/share/sddm/xorg-session.log
XauthPath=/usr/bin/xauth
XephyrPath=/usr/bin/Xephyr
UserAuthFile=.Xauthority

In my journalctl output I found this piece of text that shows me it is actually really creating a whole new session. I wonder why?!

mrt 20 22:35:55 nique-desktop-linux sddm[512]: Authenticated successfully
mrt 20 22:35:55 nique-desktop-linux sddm-greeter[529]: Message received from daemon: LoginSucceeded
mrt 20 22:35:55 nique-desktop-linux sddm-helper[634]: pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred
mrt 20 22:35:55 nique-desktop-linux audit[634]: CRED_ACQ pid=634 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_shells,pam_faillock,pam_permit,pam_faillock acct="nique" exe="/usr/lib/sdd>
mrt 20 22:35:55 nique-desktop-linux audit[634]: SYSCALL arch=c000003e syscall=1 success=yes exit=4 a0=e a1=7fff05ab1100 a2=4 a3=0 items=0 ppid=512 pid=634 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgi>
mrt 20 22:35:55 nique-desktop-linux audit: PROCTITLE proctitle=2F7573722F6C69622F7364646D2F7364646D2D68656C706572002D2D736F636B6574002F746D702F7364646D2D617574682D37343737613165632D376265332D343336662D38393837>
mrt 20 22:35:55 nique-desktop-linux sddm-helper[634]: pam_unix(sddm:session): session opened for user nique(uid=1000) by (uid=0)
mrt 20 22:35:55 nique-desktop-linux kernel: audit: type=1100 audit(1679348155.375:63): pid=634 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_shells,pam_faillock,pam_permit,pam_fa>
mrt 20 22:35:55 nique-desktop-linux kernel: audit: type=1101 audit(1679348155.375:64): pid=634 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_access,pam_unix,pam_permit,pam_time acct=>
mrt 20 22:35:55 nique-desktop-linux kernel: audit: type=1103 audit(1679348155.375:65): pid=634 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_shells,pam_faillock,pam_permit,pam_faillock >
mrt 20 22:35:55 nique-desktop-linux kernel: audit: type=1006 audit(1679348155.375:66): pid=634 uid=0 old-auid=4294967295 auid=1000 tty=(none) old-ses=4294967295 ses=2 res=1
mrt 20 22:35:55 nique-desktop-linux kernel: audit: type=1300 audit(1679348155.375:66): arch=c000003e syscall=1 success=yes exit=4 a0=e a1=7fff05ab1100 a2=4 a3=0 items=0 ppid=512 pid=634 auid=1000 uid=0 gid=0 e>
mrt 20 22:35:55 nique-desktop-linux kernel: audit: type=1327 audit(1679348155.375:66): proctitle=2F7573722F6C69622F7364646D2F7364646D2D68656C706572002D2D736F636B6574002F746D702F7364646D2D617574682D373437376131>
mrt 20 22:35:55 nique-desktop-linux systemd[1]: Created slice User Slice of UID 1000.
mrt 20 22:35:55 nique-desktop-linux systemd[1]: Starting User Runtime Directory /run/user/1000...
mrt 20 22:35:55 nique-desktop-linux systemd-logind[442]: New session 2 of user nique.
mrt 20 22:35:55 nique-desktop-linux systemd[1]: Finished User Runtime Directory /run/user/1000.

Last edited by niquedegraaff (2023-03-20 22:29:09)

stanczew · 2023-03-21 05:25:27

One interesting thing is that this happens only with manual login. With autologin, the user session is spawned on TTY1 as expected.

Autologin:

systemd[1]: Started user@1000.service.
systemd[1]: Started session-1.scope.
sddm-helper[542]: Starting Wayland user session: "/usr/share/sddm/scripts/wayland-session" "/usr/lib/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland"
sddm-helper[552]: Jumping to VT 1
sddm-helper[552]: VT mode fixed
sddm[539]: Session started true

After logging out (uid 999 is sddm):

systemd[1]: Started user@999.service.
systemd[1]: Started session-c1.scope.
sddm-helper[1169]: Jumping to VT 1
sddm-helper[1169]: VT mode fixed
sddm[539]: Greeter session started successfully

Manual login:

systemd[1]: Started user@1000.service.
systemd[1]: session-c1.scope: Deactivated successfully.
systemd[1]: session-c1.scope: Consumed 2.432s CPU time.
systemd-logind[517]: Session c1 logged out. Waiting for processes to exit.
systemd[1]: Started session-4.scope.
systemd-logind[517]: Removed session c1.
sddm-helper[1245]: Starting Wayland user session: "/usr/share/sddm/scripts/wayland-session" "/usr/lib/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland"
sddm-helper[1256]: Jumping to VT 2
sddm-helper[1256]: VT mode didn't need to be fixed
sddm[539]: Session started true

I suppose it might be related to the fact that the user session is started before SDDM session exited completely. Maybe SDDM picks the first available VT for the user session, and since SDDM itself is still running on VT1, the user session is spawned on VT2? (Then SDDM session exits and VT1 is left empty.) And with autologin SDDM doesn't need to spawn its own session, so the first available VT for the user session is VT1.

I might be completely wrong, this is just what I can think of without delving into the code.

(I'm using the newest sddm-git, e07e805.)

niquedegraaff · 2023-03-21 12:18:27

Yes, great find. I'm also on sddm-git 0.19.0.209.ge070805-1.

I think this current behavior is undesired. And i do think that ssdm does not need to spawn a new session when manually login. I'm going to dive in the sddm codebase to see what function is actually responsible for this.

And yes, I know , it's a little OCD thing, but I want a smooth desktop experience and promote a linux desktop experience to friends and family. But I cant because, these simple things are just poking in my eye tbh. Just look at the boot sequence below, it's ridiculous.

With my linux system, these are the steps:

1) Turn the computer on
2) PC shows UEFI boot screen
3) PC shows Grub menu, where i choose Manjaro
4) PC shows black screen
5) PC shows UEFI boot screen again
6) PC shows black screen
7) PC shows boot screen [i]again[/i] :S, but now with with animation
8) PC shows black screen 
9) PC shows SDDM Login screen
10) Now i can log in
11) PC shows black screen [i]again[/i].. sigh..
12) PC shows just the last 100ms of the KDE splash load screen
13) Finally on desktop.

I want to cut out many black screens and preferably use one boot screen. I know i can cut GRUB out (configured with key-stroke while booting so i can still open it).

But I want to start with the latest: the transition from login screen to desktop. It should be like Windows 11: No black screens. And I know it is possible, possibly with a sddm fork and change the helper class that opens a new unnecessary session.

Research edit
I discovered in /src/backend/PamBackend.cpp that for the autologin process, sddm-greeter is never fired. It probably never uses wayland.

bool PamBackend::start(const QString &user) {
        bool result;

        QString service = QStringLiteral("sddm");

        if (user == QStringLiteral("sddm") && m_greeter)
            service = QStringLiteral("sddm-greeter");
        else if (m_autologin)
            service = QStringLiteral("sddm-autologin");
        result = m_pam->start(service, user);

        if (!result)
            m_app->error(m_pam->errorString(), Auth::ERROR_INTERNAL);

        return result;
    }

It also looks like this piece of code in /src/helper/UserSession.cpp is part of the process:

void UserSession::setupChildProcess() {
        // Session type
        QString sessionType = processEnvironment().value(QStringLiteral("XDG_SESSION_TYPE"));
        QString sessionClass = processEnvironment().value(QStringLiteral("XDG_SESSION_CLASS"));
        const bool hasDisplayServer = !m_displayServerCmd.isEmpty();
        const bool x11UserSession = sessionType == QLatin1String("x11") && sessionClass == QLatin1String("user");
        const bool waylandUserSession = sessionType == QLatin1String("wayland") && sessionClass == QLatin1String("user");

        // When the display server is part of the session, we leak the VT into
        // the session as stdin so that it stays open without races
        if (hasDisplayServer || waylandUserSession) {
            // open VT and get the fd
            int vtNumber = processEnvironment().value(QStringLiteral("XDG_VTNR")).toInt();
            QString ttyString = VirtualTerminal::path(vtNumber);
            int vtFd = ::open(qPrintable(ttyString), O_RDWR | O_NOCTTY);

            // when this is true we'll take control of the tty
            bool takeControl = false;

            if (vtFd > 0) {
                dup2(vtFd, STDIN_FILENO);
                ::close(vtFd);
                takeControl = true;
            } else {
                int stdinFd = ::open("/dev/null", O_RDWR);
                dup2(stdinFd, STDIN_FILENO);
                ::close(stdinFd);
            }

            // set this process as session leader
            if (setsid() < 0) {
                qCritical("Failed to set pid %lld as leader of the new session and process group: %s",
                          QCoreApplication::applicationPid(), strerror(errno));
                exit(Auth::HELPER_OTHER_ERROR);
            }

            // take control of the tty
            if (takeControl) {
                if (ioctl(STDIN_FILENO, TIOCSCTTY) < 0) {
                    const auto error = strerror(errno);
                    qCritical().nospace() << "Failed to take control of " << ttyString << " (" << QFileInfo(ttyString).owner() << "): " << error;
                    exit(Auth::HELPER_TTY_ERROR);
                }
            }

            VirtualTerminal::jumpToVt(vtNumber, x11UserSession);
        }

Last edited by niquedegraaff (2023-03-21 14:40:34)

niquedegraaff · 2023-03-24 09:28:25

I decided to uninstall sddm and install greetd as a backend and code my own qt qml driven greeter app that runs on kwin_wayland. When the user successfully authenticated, the app provides a splash screen while the desktop is loading in a background kwin_wayland compositor instance. When it is ready, the app hands over the compositor to the new instance and closes it's own. No more black screens.

Sddm is barely updated, pull requests are there but not looked in to. I dont understand why KDE uses it as default while they could easily write their own greeter app built on greetd backend. Probably less complex than a Kalc app.

Last edited by niquedegraaff (2023-03-24 09:33:21)

jeois · 2023-04-07 22:06:12

I was already having issues with SDDM and cursors. Now that I've switched to Wayland, this.

Auto-login doesn't alleviate it for me for some reason either.

_Yank · 2024-03-18 21:00:08

niquedegraaff wrote:

I decided to uninstall sddm and install greetd as a backend and code my own qt qml driven greeter app that runs on kwin_wayland. When the user successfully authenticated, the app provides a splash screen while the desktop is loading in a background kwin_wayland compositor instance. When it is ready, the app hands over the compositor to the new instance and closes it's own. No more black screens.
Sddm is barely updated, pull requests are there but not looked in to. I dont understand why KDE uses it as default while they could easily write their own greeter app built on greetd backend. Probably less complex than a Kalc app.

Would you explain how you've managed to do that?

I'm currently using kwin_wayland as a compositor for Regreet (greetd greeter) with the following greetd config command:

kwin_wayland --drm --exit-with-session --no-lockscreen --no-global-shortcuts --locale1 regreet > /dev/null 2>&1

However there's still one black screen when transitioning from it to Plasma.

Arch Linux

#1 2023-03-20 22:24:43

SDDM & KDE Plasma both run on wayland but SDDM still switch tty

#2 2023-03-21 05:25:27

Re: SDDM & KDE Plasma both run on wayland but SDDM still switch tty

#3 2023-03-21 12:18:27

Re: SDDM & KDE Plasma both run on wayland but SDDM still switch tty

#4 2023-03-24 09:28:25

Re: SDDM & KDE Plasma both run on wayland but SDDM still switch tty

#5 2023-04-07 22:06:12

Re: SDDM & KDE Plasma both run on wayland but SDDM still switch tty

#6 2024-03-18 21:00:08

Re: SDDM & KDE Plasma both run on wayland but SDDM still switch tty

Board footer