Greeter on Wayland - rebased #1393

aleixpol · 2021-04-20T17:49:39Z

Rebased version of #1379

Had to be creative in some places since it changed quite a bit.

src/CMakeLists.txt

components/2.0/PictureBox.qml

plfiorini

the branch contains commits that we don't want anymore.
i would have applied the patch on top of the new develop instead of rebasing it.

plfiorini · 2021-04-20T19:13:08Z

src/daemon/Display.cpp

+                status == Auth::HELPER_OTHER_ERROR)
+            stop();
+        else
+            VirtualTerminal::jumpToVt(m_terminalId, true);


we decided not to stop the greeter

src/greeter/GreeterApp.cpp

src/helper/UserSession.cpp

plfiorini · 2021-04-20T19:16:45Z

src/helper/UserSession.cpp

@@ -224,6 +248,7 @@ namespace SDDM {
            qCritical() << "setgid(" << pw.pw_gid << ") failed for user: " << username;
            exit(Auth::HELPER_OTHER_ERROR);
        }
+        qputenv("XDG_RUNTIME_DIR", QByteArrayLiteral("/run/user/") + QByteArray::number(pw.pw_uid));


For WaylandSocketWatcher to work.

This looks not great. Either something like pam_systemd creates it and it can be used or sddm has to create its own and use that path. Just guessing that it will be /run/user/<uid> smells like a hack.

pam_systemd does create it

Exactly, but then it should only be used in the context that $XDG_RUNTIME_DIR is actually set in

In FreeBSD for instance (or with ConsoleKit in general, not sure), XDG_RUNTIME_DIR is actually set up by the session scripts and somewhere below /tmp IIRC.

On FreeBSD both consolekit2 (upstream + downstream) and pam_xdg (downstream) use /var/run/user/<uid>, hardcoded at build-time.

Right. If something else (e.g. pam_systemd) created XDG_RUNTIME_DIR, then you must READ the environment variable XDG_RUNTIME_DIR to find out its value. Or maybe there is a d-bus interface to ask for it if this is not your current session, I don't know. It would be incorrect to guess what the value might be and set XDG_RUNTIME_DIR to that guessed value.

plfiorini · 2021-04-20T19:17:38Z

src/helper/waylandhelper.cpp

+            process, [](int exitCode, QProcess::ExitStatus exitStatus) {
+        qDebug() << "wayland compositor finished" << exitCode << exitStatus;
+        if (exitCode != 0 || exitStatus != QProcess::NormalExit)
+            QCoreApplication::instance()->quit();


this will quit the helper, we don't want this

This code is copied from XOrgUserHelper::startProcess.

I guess we'll need to include a start failed signal.

Ultimately we'll need quitting anyway. If the compositor (wayland or xorg) can't be started.

plfiorini · 2021-04-20T19:18:31Z

src/helper/waylandhelper.cpp

+void WaylandHelper::switchVt()
+{
+    int vtNumber = m_environment.value(QStringLiteral("XDG_VTNR")).toInt();
+    VirtualTerminal::jumpToVt(vtNumber, true);


i think UserSession already do that

I had to bring back the WaylandSocketWatcher because we need to wait for the compositor to start before we can start the sddm-greeter.

An alternative implementation would be to have the sddm-greeter block at start until the compositor appears.

aleixpol · 2021-05-04T23:44:00Z

Ping?

aleixpol · 2021-05-15T23:26:45Z

Ping?

Mazino-Urek · 2021-06-05T15:00:42Z

It would have really great if this feature landed before Plasma 5.23.

Introduce a new display server option to run the greeter with. In the future this will be the default display server. This patch contains the most important parts to get the greeter running on Wayland, but it's not possible to select a keyboard layout. At the moment the Wayland socket is assumed to be "wayland-0" but in a multi-seat configuration we would have more than one greeter running, each with a diffent socket and the assumption won't work anymore. In the future we will figure out how to do, after all at the moment this is considered enough for most people. Closes: #440

Includes a GreeterEnvironment configuration entry.

plfiorini · 2021-06-08T06:47:47Z

Added a couple of environment variables for fullscreen-shell and disable window decoration, then rebased on top of the latest develop. I will give it one more last test later this evening and merge if it works fine.

aleixpol · 2021-06-09T10:08:38Z

Thanks!

isopix · 2021-06-22T15:35:33Z

Waylanded SDDM really sucks on mulit-monitor setups, because it’s not cloned across displays, and menu items appeared on internal(closed laptop lid) display, than I’ve been clicking (so it was impossible to change Session for me). It uses Weston by default, and from my research Weston doesn’t support clone-mode-by-default (ass application argument).
Maybe other Wayland compositor(than weston) could do that?

aleixpol · 2021-06-22T16:51:41Z

Maybe other Wayland compositor(than weston) could do that?

Yes, that's what the CompositorCommand setting is for.

isopix · 2021-06-22T17:06:46Z

I know. But for now sddm with wayland is downgrade to sddm on X11 on multimonitor setups. I wanted to point that IMHO SDDM should choose other compositor for wayland as default. I've simply went back to X11 setup. But SDDM should definitely work with multi-monitor setups. And while strict multimonitor setups are in decline, due to widescreens larger displays becoming cheaper, every laptop with external monitor acts as multi-monitor setup (because while I've set internal display as disabled, I must go trough SDDM for it). Also SDDM should work out-of-the-box on as many configurations as possible, and mine laptop+ext. screen is not so exotic. So I think the current state of SDDM+weston mariage (in wayland mode) is not acceptable (I know that X11 is default, but I guess that with current pro-wyaland trend, you want to change that as quickly as possible) cheers, Krzysztof Krakowia

…

On 6/22/21, Aleix Pol ***@***.***> wrote: > Maybe other Wayland compositor(than weston) could do that? Yes, that's what the CompositorCommand setting is for. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #1393 (comment)

ppaalanen · 2021-06-29T07:29:54Z

Was there a discussion somewhere on how you ended up choosing to use Weston's fullscreen-shell protocol extension?

I see that you are planning to run on more than Weston, which I think is a good idea, and I suppose it also means the greeter works on the xdg-shell family of protocol extensions, not just fullscreen-shell.

As for the clone mode, you could have the greeter set up similar windows on all outputs. That does not need clone mode support from Weston, and it will fit diverse monitors much much better than a clone mode because a) resolution aware text rendering instead of raster scaling, and b) you can fit the UI layout to the available screen estate on each monitor.

At Weston upstream, we had kind of abandoned the fullscreen-shell, but now that it actually has a use case, I wonder what to do. Maybe we should open a Weston issue about the future of the fullscreen-shell?

Weston has also kiosk shell plugin which seems more promising going forward and exposes the xdg-shell family of protocol extensions.

plfiorini · 2021-06-29T10:58:38Z

Was there a discussion somewhere on how you ended up choosing to use Weston's fullscreen-shell protocol extension?

No, I just wanted something that didn't involve a panel but it's temporary.

I see that you are planning to run on more than Weston, which I think is a good idea, and I suppose it also means the greeter works on the xdg-shell family of protocol extensions, not just fullscreen-shell.

The greeter should work very well with xdg-shell.

As for the clone mode, you could have the greeter set up similar windows on all outputs. That does not need clone mode support from Weston, and it will fit diverse monitors much much better than a clone mode because a) resolution aware text rendering instead of raster scaling, and b) you can fit the UI layout to the available screen estate on each monitor.

I need to investigate what's going on here: SDDM creates a window for each screen that is reported by Qt therefore there is no clone mode here as opposed to X11. This should actually be very good for the use case of @isopix but my guess is that Weston still reports the laptop output even though the lid is closed and that's why the greeter goes into that output.

At Weston upstream, we had kind of abandoned the fullscreen-shell, but now that it actually has a use case, I wonder what to do. Maybe we should open a Weston issue about the future of the fullscreen-shell?

Weston has also kiosk shell plugin which seems more promising going forward and exposes the xdg-shell family of protocol extensions.

At the time there was no kiosk shell, so the fullscreen-shell was the best way to get something without a panel.
I'm on Fedora 33 with Weston 8.0.0 and this shell is not available.
Using the kiosk shell plugin is the best going forward and I'm considering to switch to it now, before the SDDM release.

davidedmundson · 2021-06-29T11:12:11Z

The greeter should work very well with xdg-shell.

Released Qt presents a challenge QWindow::setFullscreen() on XDG calls xdg_toplevel.set_fullscreen(null). So on a multi-screen setup you don't know where the window will end up.

Qt's fullscreen-shell did forward the screen.

XDGShell implementation is changed in Qt6 and in KDE's Qt backports.

plfiorini · 2021-06-29T11:16:18Z

The greeter should work very well with xdg-shell.

Released Qt presents a challenge QWindow::setFullscreen() on XDG calls xdg_toplevel.set_fullscreen(null). So on a multi-screen setup you don't know where the window will end up.

Oh I forgot about that

Qt's fullscreen-shell did forward the screen.

Yeah I remember I did get that right when I wrote the shell integration plugin :)

XDGShell implementation is changed in Qt6 and in KDE's Qt backports.

Do you know if distros are using the KDE's Qt backports?

ppaalanen · 2021-06-29T11:41:32Z

Thanks!

I would assume that Weston does not handle the laptop lid switch at all, so probably the internal panel does not even turn off, unless it also appears disconnected from KMS perspective.

darkbasic · 2021-06-29T13:15:12Z

Do you know if distros are using the KDE's Qt backports?

I think Arch does: https://archlinux.org/packages/extra/x86_64/qt5-base/

isopix · 2021-06-29T13:58:13Z

On /29/21, Pier Luigi Fiorini ***@***.***> wrote: I need to investigate what's going on here: SDDM creates a window for each screen that is reported by Qt therefore there is no clone mode here as opposed to X11. This should actually be very good for the use case of @isopix but my guess is that Weston still reports the laptop output even though the lid is closed and that's why the greeter goes into that output.

I havem't investigated it rurther, nor I've opened laptop lid. Simply decided this setup is broken, switched to X11 backend and posted there SSDM started in wayland mode on external screen, but dialogs (like session/language/keyboard selection) haven't appeared on this display (not sure about internal one). I was able to login, but not to use stuff that required 'menus' (that starts as external windows/dialogs)

zzag reviewed Apr 20, 2021

View reviewed changes

src/CMakeLists.txt Outdated Show resolved Hide resolved

plfiorini reviewed Apr 20, 2021

View reviewed changes

components/2.0/PictureBox.qml Outdated Show resolved Hide resolved

plfiorini requested changes Apr 20, 2021

View reviewed changes

aleixpol force-pushed the wayland-rebased branch from 6398077 to 73e68df Compare April 21, 2021 09:43

tpgxyz mentioned this pull request May 19, 2021

Wayland session not started on tty1 #1409

Closed

plfiorini mentioned this pull request May 25, 2021

Adding on readme on what SDDM runs #1410

Closed

plfiorini force-pushed the wayland-rebased branch from 6a9c2aa to d180acd Compare June 8, 2021 06:25

plfiorini and others added 2 commits June 8, 2021 08:44

Greeter: Support setting environment variables

e1c7202

Includes a GreeterEnvironment configuration entry.

plfiorini force-pushed the wayland-rebased branch from d180acd to e1c7202 Compare June 8, 2021 06:44

plfiorini added this to the 0.20 milestone Jun 8, 2021

plfiorini approved these changes Jun 9, 2021

View reviewed changes

plfiorini merged commit 56ad91e into develop Jun 9, 2021

plfiorini deleted the wayland-rebased branch June 9, 2021 07:17

This was referenced Jun 24, 2021

Wayland: Remove all remaining X11 dependencies #1420

Open

Wayland: runtime-detect installed compositor #1421

Open

SebTM mentioned this pull request Nov 25, 2022

Time for the annual 0.20 release? #1471

Closed

Conan-Kudo mentioned this pull request Jan 30, 2024

Switch the Wayland greeter default to use Weston's Kiosk shell #1860

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Greeter on Wayland - rebased #1393

Greeter on Wayland - rebased #1393

aleixpol commented Apr 20, 2021

plfiorini left a comment

plfiorini Apr 20, 2021

plfiorini Apr 20, 2021

aleixpol Apr 21, 2021

Vogtinator Feb 2, 2023

davidedmundson Feb 2, 2023

Vogtinator Feb 2, 2023

Vogtinator Feb 2, 2023

jbeich Feb 3, 2023

ppaalanen Feb 3, 2023

plfiorini Apr 20, 2021

aleixpol Apr 21, 2021

plfiorini Apr 20, 2021

aleixpol Apr 21, 2021

aleixpol commented May 4, 2021

aleixpol commented May 15, 2021

Mazino-Urek commented Jun 5, 2021

plfiorini commented Jun 8, 2021

aleixpol commented Jun 9, 2021

isopix commented Jun 22, 2021

aleixpol commented Jun 22, 2021

isopix commented Jun 22, 2021 via email

ppaalanen commented Jun 29, 2021

plfiorini commented Jun 29, 2021

davidedmundson commented Jun 29, 2021

plfiorini commented Jun 29, 2021

ppaalanen commented Jun 29, 2021

darkbasic commented Jun 29, 2021

isopix commented Jun 29, 2021 via email

Greeter on Wayland - rebased #1393

Greeter on Wayland - rebased #1393

Conversation

aleixpol commented Apr 20, 2021

plfiorini left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aleixpol commented May 4, 2021

aleixpol commented May 15, 2021

Mazino-Urek commented Jun 5, 2021

plfiorini commented Jun 8, 2021

aleixpol commented Jun 9, 2021

isopix commented Jun 22, 2021

aleixpol commented Jun 22, 2021

isopix commented Jun 22, 2021 via email

ppaalanen commented Jun 29, 2021

plfiorini commented Jun 29, 2021

davidedmundson commented Jun 29, 2021

plfiorini commented Jun 29, 2021

ppaalanen commented Jun 29, 2021

darkbasic commented Jun 29, 2021

isopix commented Jun 29, 2021 via email