Display Managers for starting X11 and Wayland sessions

johnraff · 2024-08-11 07:35:22

There's a lot to think about here, when looking towards a BunsenLabs that can log users in to either an X11 or Wayland session.

There are some Display Managers that need an X server to run on, but are able to launch Wayland sessions. One such is BL's current DM, lightdm. For them, the flow is:
Start X server
Run DM on X
Launch:
X session: X server continues to run, windows are opened
Wayland: Compositor is launched, windows opened there
DM remains on X server in background (but not using much RAM or CPU)

There are other Wayland-based DMs that can launch X11 or Wayland sessions, a very simple one is greetd. For greetd the flow is:
Greetd starts a Wayland compositor (eg labwc or cage)
Compositor opens a login greeter (eg nwg-hello)
Launch:
X session: X server starts, Wayland compositor and greeter close
Wayland: Compositor running greeter closes, new compositor is launched
Another greeter I want to look at is ReGreet, just from the pretty screenshots...

This is just a placeholder post for now.

One upcoming topic will be pros and cons of continuing to use lightdm.

Reference about lightdm:
https://github.com/canonical/lightdm
(Last release 1.32.0, two years ago.)
https://github.com/canonical/lightdm/commits/main
(Commits still coming in, last was 20th June 2024)
https://www.phoronix.com/news/LightDM-2 … tus-Update
https://discourse.ubuntu.com/t/current- … htdm/29048

johnraff · 2024-08-25 09:40:40

I built lightdm from GitHub's latest commit and it seemed to install OK (felt quite pleased with myself).
But was disappointed to find it still had the same erratic behaviour when starting Wayland sessions.

Maybe it's an issue with lightdm-gtk-greeter?

DeepDayze · 2024-08-25 15:04:03

ReGreet looks very promising as an alternative display manager. If it's as robust and themeable as LightDM then perhaps switch to that DM in Nitrogen (but maybe as an addon in Carbon). It may or may not need hackage to make it work like LightDM and to fit it in with the BL ecosystem.

johnraff wrote:

Maybe it's an issue with lightdm-gtk-greeter?

It may well be that, if LightDM itself starts OK and are able to select the Wayland session.

Last edited by DeepDayze (2024-08-25 15:07:02)

johnraff · 2024-08-26 06:21:14

Lightdm starts OK on Trixie - and we've been using it for years on Debian Stable - and it has a nice feature set. Apart from the login session (standard of course) it lets you choose the session language if there's more than one installed, and also offers some accessibility options. Looks fairly nice too.

It detects Wayland sessions and usually the first time I choose one it starts up OK. What I keep getting is that if I log out and try to launch a Wayland session again, this time it fails. If I reboot the VM it's OK again. I was hoping that an upgrade of lightdm would fix it, but no such luck. All that testing was on a qemu VM, but @micko01 reports that on his laptop lightdm is unable to launch Wayland at all. It is supposed to be able to do that.

But some of the functionality is coming from the front-end lightdm-gtk-greeter. It might help to try slick-greeter (an alternative lightdm greeter, available from Debian) and see if the Wayland flakiness continues or not. Slick-greeter's a good-looking greeter anyway, though it doesn't offer language choice.

Greetd>cage>nwg-greeter has been tested out and at least can launch Wayland sessions OK. ReGreet looks like a possible alternative to nwg-greeter in the same login chain, the screenshots look nice and the description looks promising, so Greetd>cage>ReGreet might work too. Both greetd and cage are small programs without a lot of code to go wrong, and built with Wayland in mind from the start. ReGreet is built on Rust which means it might not be hard to install for a user, but Debian packaging could be difficult. (There's no ReGreet in the Debian repos.)

johnraff · 2024-08-26 07:41:45

It seems lightdm is supposed to run OK on Wayland:
https://lists.freedesktop.org/archives/ … 01172.html

micko01 · 2024-08-26 08:08:19

^yeah it's the graphical greeter that's the issue.

parallels are;
lightdm == greetd
lightdm-gtk-greeter == nwg-hello

It's the greeter, not the daemon that needs the graphical server. Theoretically, nwg-hello, could easily work on lightdm instead of greetd. It's based on the lightdm-elephant-greeter.

That's probably how the raspberry pi folks are using it - they love python over there

I don't think it's X causing the login loop, but probably a bug in the greeter itself. So maybe trying slick is the go. The login loop was quite persistent on my HP laptop, tried all sorts of settings to no avail. I think @hhh had something similar on a friends device IIRC?

I'm still using nwg-hello and just today logged back into xfce on this trixie box to test out an nm-applet bug (turns out specific to sfwbar - no tooltip) and no issue at all.

johnraff · 2024-08-27 06:16:50

I've found part of the puzzle.
It turns out there probably is a bug in lightdm after all, though I haven't yet done any testing with alternative greeters.

These two issues are related to input devices not being detected properly, but switching VT from 7 to 8 also comes into the picture:
https://github.com/canonical/lightdm/issues/63
https://github.com/canonical/lightdm/issues/126

Anyway, I simply added a 'sleep 1' to /usr/bin/bunsenlabs-session just before labwc is called, and logins succeed every time. At the end of the file:

# Run the window manager.
case "$win_man" in
openbox)
    exec /usr/bin/openbox --config-file "$usr_confdir/openbox/bl-rc.xml" --startup "$bl_autostart"
    ;;
labwc)
    sleep 1
    exec /usr/bin/labwc --startup "$bl_autostart"
    ;;
*)
    (
    until pgrep -x "$win_man"
    do
        sleep 0.5s
    done
    "$bl_autostart"
    ) &
    exec "$win_man"
    ;;
esac

For some reason the Wayland session is created on VT 8 not the usual 7, but that's not unheard of.

---
Another thing I found was /usr/share/lightdm/lightdm.conf.d/01_debian.conf:

# Debian specific defaults
#
# - use lightdm-greeter session greeter, points to the etc-alternatives managed
# greeter
# - hide users list by default, we don't want to expose them
# - use Debian specific session wrapper, to gain support for
# /etc/X11/Xsession.d scripts

[Seat:*]
greeter-session=lightdm-greeter
greeter-hide-users=true
session-wrapper=/etc/X11/Xsession

That last line is invoking the whole X11 session script set, regardless of whether we're running an X11 or Wayland session.
Some of that stuff might in fact be useful but I think we should make an edited version for Wayland. For now, I've disabled it with this in /usr/share/lightdm/lightdm.conf.d/50_bunsen.conf:

session-wrapper=lightdm-session

Debian doesn't ship a lightdm-session so I also needed this little script "lightdm-session" somewhere in PATH:

#!/bin/sh

exec "$@"

The Wayland sesson actually boots OK while still running the Debian xsession stuff, but I felt it was an unnecessary complication at this point.

hhh · 2024-08-27 18:52:34

Hey, sounds promising!

johnraff · 2024-08-28 06:58:41

What I'm guessing is happening here:

Lightdm's greeter (we're using lightdm-gtk-greeter) runs on X11 and starts on VT (virtual terminal) 7, but to launch a Wayland session it needs to switch to a fresh one on VT 8. Presumably changing from X to Wayland on the same VT is too hard.

So the login happens on VT 7, but if you select a Wayland session from the list it will move to VT 8 then start the session. If you choose a session that runs on X it will stay on VT 7.

The issue is that switching VT takes quite some time (~200ms in the above bug report) but the session is launched right away, which gives plenty of scope for a race condition. It looks as if the new VT isn't ready in time for the compositor when it tries to start up - so the extra 'sleep 1' gives it breathing space. Eventually we might use a loop based on what was posted there to check for '/sys/devices/virtual/tty/tty0/active' instead of a fixed 1 second:

if [ -n "$XDG_VTNR" ] ; then
    echo "Waiting for VT $XDG_VTNR:"
    for ((i=0;i<100;i++)) ; do
      CURRENT="$(</sys/devices/virtual/tty/tty0/active)" 
      echo  "  $(date +%s.%N) using $CURRENT"
      if [[ "$CURRENT" = "tty$XDG_VTNR" ]]; then
          break
      fi
      sleep 0.01
    done 
fi

Of course checking every 10ms might be over-zealous, and all that echoing is unnecessary.

So if there's no VT switch involved, the issue shouldn't appear, as when launching Wayland from a wayland-based greeter. it might be interesting to look at the reverse case though - what happens when launching an X11 session from eg nwg-hello?

micko01 · 2024-08-28 07:24:05

johnraff wrote:

So if there's no VT switch involved, the issue shouldn't appear, as when launching Wayland from a wayland-based greeter. it might be interesting to look at the reverse case though - what happens when launching an X11 session from eg nwg-hello?

ps -ef |grep labwc # or grep Xorg

Well, this answers that. Ran command on labwc, logged out, logged in to xfce session, ran command. Still using greetd/nwg-hello/cage.

mick@dellhome:~$ ps -ef |grep labwc
mick        1328    1261  0 13:26 tty7     00:01:45 labwc
mick@dellhome:~$ ps -ef |grep Xorg
mick       20572   20571  1 17:14 tty7     00:00:00 /usr/lib/xorg/Xorg -nolisten tcp :0 vt7 -keeptty -auth /tmp/serverauth.eBee0TtjgL

johnraff · 2024-08-29 07:39:27

^Interesting. So greetd sees no need to switch VT. Could it be because in this setup the DM is completely shut down? I think that's what cage might do once its work is finished.

By contrast, lightdm remains in the background even after the graphical session has been launched. Maybe something about the ability to launch multiple sessions (if lightdm can do that)?
Also, note that the tty is unknown - Wayland launched from lightdm:

john@trixie-tester:~$ ps -ef | grep labwc
john        1764    1758  0 15:50 ?        00:00:01 labwc --startup /usr/lib/bunsen/configs/bunsen-autostart

But is recognized as vt7 when running X:

john@trixie-tester:~$ ps -ef | grep Xorg
root        1934     594  1 16:14 tty7     00:00:00 /usr/lib/xorg/Xorg :0  -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

Also lightdm is running X as root, which isn't really wonderful...

On a different VM using greetd and friends instead of lightdm, launching Wayland - pretty much the same as @micko01:

john@trixie-tester:~$ ps -ef | grep labwc
john        1391    1379  0 14:27 tty7     00:00:09 labwc --startup /usr/lib/bunsen/configs/bunsen-autostart

X11 session:

john@trixie-tester:~$ ps -ef | grep Xorg
john        1879    1878  1 16:29 tty7     00:00:00 /usr/lib/xorg/Xorg -nolisten tcp :0 vt7 -keeptty -auth /tmp/serverauth.U30vstkwDC

---
Anyway, since adding that 1s sleep, there's been much less lightdm/Wayland weirdness.

johnraff · 2024-12-27 07:15:04

Alternative way of setting the 1s delay for LightDM on wayland:
https://github.com/canonical/lightdm/is … -497987787
(last 2 sentences)

Lightdm on Debian starts its Wayland sessions exactly like regular X11 sessions by calling the script /etc/Xsession which itself executes everything in /etc/Xsession.d/* and eventually calls the program specified in the session file. In practice, that means that I do not need to care about services such as dbus and ssh-agent in my ~/.wayland-session script. However, be aware that every Xsession script that relies on X11 will fail (hopefully in a non fatal way) since XWayland is not yet started at that time.
That also means that an alternative location for the sleep command could be a custom script in /etc/Xsession.d/* . That script could identify Wayland sessions by testing $XDG_SESSION_TYPE=="wayland"

If doing it that way, we should probably also add a test for whether LightDM is actually being used or not.

xfce4-session recently pushed a commit to work around the same issue:
https://gitlab.xfce.org/xfce/xfce4-sess … 8f2f155205

Last edited by johnraff (2024-12-27 07:29:28)

hhh · 2024-12-27 23:59:36

Most recent version of Xfce is almost fully Wayland enabled, right? I don't know how much of that is included in Trixie...

https://packages.debian.org/trixie/xfce4

PackRat · 2024-12-28 00:33:01

hhh wrote:

Most recent version of Xfce is almost fully Wayland enabled, right? I don't know how much of that is included in Trixie...
https://packages.debian.org/trixie/xfce4

The window manager and the system tray don't work at all in Wayland. Everything else is pretty smooth. Xfce4-terminal, thunar, xfce4-notifyd, and the taskbar all work. Those packages should be in Trixie. Team Xfce seems to be pretty active, there may be some fixes coming through before Trixie hits freeze.

johnraff · 2024-12-28 04:56:28

PackRat wrote:

Team Xfce seems to be pretty active, there may be some fixes coming through before Trixie hits freeze.

That lightdm fix that got committed in November went into xfce4-session 4.19.4 - and 4.20.0 is already in Trixie
https://gitlab.xfce.org/xfce/xfce4-sess … aster/NEWS
https://packages.debian.org/search?keyw … ection=all

And plenty of Wayland mentions in the recent activity of this package:
https://gitlab.xfce.org/xfce/xfce4-session/activity

Last edited by johnraff (2024-12-28 04:57:28)

johnraff · 2024-12-30 07:30:10

johnraff wrote:

Another thing I found was /usr/share/lightdm/lightdm.conf.d/01_debian.conf:
# Debian specific defaults
#
# - use lightdm-greeter session greeter, points to the etc-alternatives managed
# greeter
# - hide users list by default, we don't want to expose them
# - use Debian specific session wrapper, to gain support for
# /etc/X11/Xsession.d scripts

[Seat:*]
greeter-session=lightdm-greeter
greeter-hide-users=true
session-wrapper=/etc/X11/Xsession
That last line is invoking the whole X11 session script set, regardless of whether we're running an X11 or Wayland session.
Some of that stuff might in fact be useful but I think we should make an edited version for Wayland. For now, I've disabled it...
The Wayland sesson actually boots OK while still running the Debian xsession stuff, but I felt it was an unnecessary complication at this point.

In fact, some of the things being started from /etc/X11/Xsession.d are still useful in Wayland, and so far I haven't found any of the X-specific things like xrdb doing any damage - they just seem to leave a message in .Xsession-errors like "server not found" and exit. (Yes, .Xsession-errors will still be written to under Wayland if those Xsession scripts are run.)

So maybe for now we can continue letting LightDM set session-wrapper=/etc/X11/Xsession even in Wayland.

But keep our eyes open for possible issues down the road.

manyroads · 2024-12-30 13:33:09

FWIW

I have been using lightdm & slick-greeter for both and I have no major issues in over a year.

johnraff · 2024-12-31 00:59:54

^Thanks for the input!

How do you start the Wayland session? A .desktop file in /usr/share/wayland-sessions? If so, what does it run?

I'm eager to learn how other setups handle this.

napcok · 2024-12-31 08:38:58

I just started playing with Labwc on Mabox (Arch/Manjaro based). LightDM and /usr/share/wayland-sessions.
Take a look at https://github.com/Mabox-Linux/mabox-labwc - very basic currently.

Looks like 2025 will be the year of Labwc
Happy New Year!

johnraff · 2024-12-31 09:38:35

^@napcok thanks for that.
You don't seem to be using the Debian scripts under /etc/X11/Xsession.d - are you launching dbus etc some other way?

EDIT forget that, I wasn't thinking clearly. You said you're using LightDM, so if you're on Debian then that Debian LightDM 'session-wrapper=/etc/X11/Xsession' config snippet will call Xsession, just the same as with BunsenLabs.

...and all the best for 2025!

Last edited by johnraff (2024-12-31 12:19:44)

#1 2024-08-11 07:35:22

Display Managers for starting X11 and Wayland sessions

#2 2024-08-25 09:40:40

Re: Display Managers for starting X11 and Wayland sessions

#3 2024-08-25 15:04:03

Re: Display Managers for starting X11 and Wayland sessions

#4 2024-08-26 06:21:14

Re: Display Managers for starting X11 and Wayland sessions

#5 2024-08-26 07:41:45

Re: Display Managers for starting X11 and Wayland sessions

#6 2024-08-26 08:08:19

Re: Display Managers for starting X11 and Wayland sessions

#7 2024-08-27 06:16:50

Re: Display Managers for starting X11 and Wayland sessions

#8 2024-08-27 18:52:34

Re: Display Managers for starting X11 and Wayland sessions

#9 2024-08-28 06:58:41

Re: Display Managers for starting X11 and Wayland sessions

#10 2024-08-28 07:24:05

Re: Display Managers for starting X11 and Wayland sessions

#11 2024-08-29 07:39:27

Re: Display Managers for starting X11 and Wayland sessions

#12 2024-12-27 07:15:04

Re: Display Managers for starting X11 and Wayland sessions

#13 2024-12-27 23:59:36

Re: Display Managers for starting X11 and Wayland sessions

#14 2024-12-28 00:33:01

Re: Display Managers for starting X11 and Wayland sessions

#15 2024-12-28 04:56:28

Re: Display Managers for starting X11 and Wayland sessions

#16 2024-12-30 07:30:10

Re: Display Managers for starting X11 and Wayland sessions

#17 2024-12-30 13:33:09

Re: Display Managers for starting X11 and Wayland sessions

#18 2024-12-31 00:59:54

Re: Display Managers for starting X11 and Wayland sessions

#19 2024-12-31 08:38:58

Re: Display Managers for starting X11 and Wayland sessions

#20 2024-12-31 09:38:35

Re: Display Managers for starting X11 and Wayland sessions

Board footer