Organizing the Carbon BunsenLabs sessions for Wayland and X11

johnraff · 2024-08-21 07:17:33

^Of course Greg Wooledge there was talking about the "traditional Unix setup" that starts from a TTY login. When a Display Manager is involved, startx and friends no longer have to come into the picture. Different DMs have their different routes to an X session, for example some source ~/.profile, but LightDM ignores that and uses ~/.xsessionrc instead.

Before LightDM, CrunchBang used to use Slim, which sourced .profile. From what I read, .xsessionrc is the "correct" place for X sessions, and .profile for TTY sessions, but many DMs still seem to source .profile.

There doesn't seem to be a cast-iron guaranteed default way to set envvars that will work in all circumstances.

johnraff · 2024-08-21 08:22:26

micko01 wrote:

First create a cage wrapper, called cage-run and made executable and put in /usr/local/bin
#!/bin/sh
. /etc/default/keyboard
export XKB_DEFAULT_LAYOUT=$XKBLAYOUT
exec cage "$@"
In /etc/greetd/greetd.conf I changed the 'command' line:
command = "cage-run -s nwg-hello"

You've given me an idea! Why not just export the keyboard envvars at that point, and there's no need to write them anywhere, as long as they're propagated from cage to labwc. I'm out of time again but I'll try it tomorrow.

johnraff · 2024-08-22 07:33:12

johnraff wrote:

micko01 wrote:
First create a cage wrapper, called cage-run and made executable and put in /usr/local/bin
#!/bin/sh
. /etc/default/keyboard
export XKB_DEFAULT_LAYOUT=$XKBLAYOUT
exec cage "$@"
In /etc/greetd/greetd.conf I changed the 'command' line:
command = "cage-run -s nwg-hello"
You've given me an idea! Why not just export the keyboard envvars at that point, and there's no need to write them anywhere, as long as they're propagated from cage to labwc. I'm out of time again but I'll try it tomorrow.

OK cage-run works nicely for setting the keyboard layout inside cage - and that's an important plus already - but the envvar isn't propagated beyond cage into the user session. This is what I half-expected to be honest.

But even so, a similar bit of code near the beginning of bunsenlabs-session should set the keyboard layout without having to write to a file. Let me try now...

johnraff · 2024-08-22 10:00:02

Seems to work, but I need to figure something out with Wayland clipboard because I'm not going to copy the code out by hand.

EDIT: I forgot, just ssh into the VM and no clipboard is needed.

This, near the top of /usr/bin/bunsenlabs-session around line 36, after the session type has been determined:

# Export keyboard layout from /etc/default/keyboard
if [ "$W" = 'true' ]; then
    . /etc/default/keyboard
    [ -n "$XKBMODEL" ] && export XKB_DEFAULT_MODEL=$XKBMODEL
    [ -n "$XKBLAYOUT" ] && export XKB_DEFAULT_LAYOUT=$XKBLAYOUT
    [ -n "$XKBVARIANT" ] && export XKB_DEFAULT_VARIANT=$XKBVARIANT
    [ -n "$XKBOPTIONS" ] && export XKB_DEFAULT_OPTIONS=$XKBOPTIONS
    [ -n "$XKBRULES" ] && export XKB_DEFAULT_RULES=$XKBRULES
fi

I wanted to use a for loop going over MODEL LAYOUT etc but it's tricky enough in bash and likely impossible in sh, so just tested each variable separately.
Only needed on Wayland because on X11 /etc/default/keyboard is already being parsed (somewhere).
Goes straight into the environment, but anything coming later - labwc or user environment files - can overwrite it.

I think that should fit user expectations of system behaviour fairly well. Whatever they set when installing will be respected, but if they want to change the keyboard layout, any of the expected places should work, including editing /etc/default/keyboard directly of course.

Your more sophisticated original script should still have its place in settings utilities though.

Last edited by johnraff (2024-08-23 00:19:34)

micko01 · 2024-08-24 03:58:07

^ variables in a loop offers no real advantage, and there's only 5 of any use in wayland. I like what you've got.

johnraff · 2024-11-12 05:32:49

johnraff wrote:

johnraff wrote:
...I got a double cursor and various other minor bugs.
2) I often - but not always - got a double cursor on Wayland. Logging in through lightdm after a fresh reboot it wasn't there, but just now after running 'bunsenlabs-wayland-session' from a TTY it was. Second time, everything was fine. The situation is more complicated because I'm on a qemu VM. When it's happening, one of the two cursors stays in the VM and the other one slides easily over the border into the host machine. On top of a terminal, one of them turns into a cursor. Perhaps that second one is supposed to be suppressed by qemu when the cursor is inside the VM?
...
EDIT 241108 I think issue 2) is related to qemu not LightDM. It definitely looks as if the host cursor is not being switched off when moving into the guest, so there are two. Sometimes. The double-cursor effect sometimes appears in a nwg-hello window too, so it's definitely not LightDM only.

I think this might be because spice-vdagent - which is what does the seamless cursor transitions accross the VM window boundaries - doesn't (yet?) handle Wayland.

An easy clue is to move the cursor out of the VM window and see if a copy is left behind at the boundary. With spice-vdagent installed on a guest using Xorg the cursor moves smoothly across the boundary.

johnraff · 2024-12-31 09:34:52

^Another possible cause of the double cursor is input grabbing:
https://wiki.archlinux.org/title/Waylan … VM_windows

In contrast to Xorg, Wayland does not allow exclusive input device grabbing, also known as active or explicit grab (e.g. keyboard, mouse), instead, it depends on the Wayland compositor to pass keyboard shortcuts and confine the pointer device to the application window.
...
The mouse pointer will not be restricted to the application's window which might cause a parallax effect where the location of the mouse pointer inside the window of the virtual machine or remote desktop is displaced from the host's mouse pointer.
...
Wayland solves this by adding protocol extensions for Wayland and Xwayland. Support for these extensions is needed to be added to the Wayland compositors.
...
Supporting Wayland compositors:
Mutter, GNOME's compositor since release 3.28
wlroots supports relative-pointer and pointer-constraints
Kwin

Labwc is based on wlroots, but installing wayland-protocols didn't fix the issue.

micko01 · 2024-12-31 10:37:25

^wayland-protocols is a build dependency of labwc

Anyway, labwc is at 0.8.2 now and 0.8.1 has finally trickled down from experimental to unstable(sid) so hopefully will land in trixie soon.

IDK if it will fix your issue but strange that I have never seen it. I'm using labwc as the host too which may make a difference, although qemu is running as Xwayland (if I use SDL_VIDEODRIVER=wayland it uses a native window but makes no difference). I use qemu from CLI and it uses the SDL2 window.

johnraff · 2024-12-31 12:14:14

What triggers it, I've found, is if you take the mouse pointer outside the VM window. At that point it leaves a copy of itself at the boundary, and when you come back inside the VM there are two pointers. Inside a terminal there's one bar cursor and one pointer. It does seem like what the Arch wiki is describing. But after login, until you take the pointer outside the VM everything's fine.

johnraff · 2025-01-01 08:47:56

johnraff wrote:

I think this might be because spice-vdagent - which is what does the seamless cursor transitions across the VM window boundaries - doesn't (yet?) handle Wayland.

Issue persists even after removing spice-vdagent and rebooting the VM, which seems to rule that out.

johnraff · 2025-01-01 09:18:36

micko01 wrote:

Anyway, labwc is at 0.8.2 now and 0.8.1 has finally trickled down from experimental to unstable(sid) so hopefully will land in trixie soon.
IDK if it will fix your issue...

Just grabbed labwc 0.8.2 from Sid and it installed OK on Trixie, pulling in a couple of new dependencies.

And it fixed the double-cursor issue.

micko01 · 2025-02-25 08:18:05

This is interesting:

~$ apt policy lightdm
lightdm:
  Installed: 1.32.0-6+b1
  Candidate: 1.32.0-6+b1
  Version table:
     1.32.0+git240823-6.1~bl1 100
        100 https://01micko.github.io/debian carbon-trixie/main amd64 Packages
 *** 1.32.0-6+b1 650
        650 http://mirror.aarnet.edu.au/debian trixie/main amd64 Packages
        600 http://mirror.aarnet.edu.au/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status

So debian's version is installed on my main box (replacing greetd/nwg-hello - dragged in from bunsen-configs) and labwc boots fine!

xfce-session --wayland not so! (looks like a known issue). BTW, I'm not starting labwc through bunsen-labs session yet (through lightdm, though I could from cli) .

So I tried on my troublesome HP laptop, updated everything and lo and behold it boots from lightdm! (debian's version - bunsen customisations are applied of course though bunsen-configs as per usual).

May be we can ditch all references to greetd/nwg-hello and just mention them somewhere for wayland purists.

johnraff · 2025-02-26 01:57:42

micko01 wrote:

May be we can ditch all references to greetd/nwg-hello and just mention them somewhere for wayland purists.

It looks as if lightdm from the regular Debian Trixie repo will be able to do the job.
(And we can drop the git build I made from your repo, since it's now superseded by the Debian version.)

We could still ship the configs we (mostly you) figured out for greetd+nwg-hello in place though - they're small files, won't do any harm, and might save someone some work...

---
Versions - I obviously made a mistake choosing the version number for that github build. The intention was that it would automatically be exceeded by the next Debian release of 1.32.0-6, but that didn't happen:

john@boron:~$ dpkg --compare-versions 1.32.0-6+b1 gt 1.32.0+git240823-6.1~bl1 && echo greater || echo 'not greater'
not greater
john@boron:~$ dpkg --compare-versions 1.32.0+git240823-6.1~bl1 gt 1.32.0-6+b1 && echo greater || echo 'not greater'
greater

It's really tricky.
I guess you @micko got the right version of lightdm because you hadn't previously installed 1.32.0+git240823-6.1~bl1 and the pin of 100 stopped 1.32.0-6+b1 from being upgraded? If you already had 1.32.0+git240823-6.1~bl1 it would have stayed there.

I need to think carefully in order to avoid this situation in future.

---

micko01 wrote:

BTW, I'm not starting labwc through bunsen-labs session yet.
So I tried on my troublesome HP laptop, updated everything and lo and behold it boots from lightdm! (debian's version - bunsen customisations are applied of course though bunsen-configs as per usual).

So is labwc being started with the 1s delay that we put in /usr/bin/bunsenlabs-session?
I think xfce-session is applying a similar delay (not plain 1s but actually looping over a check) and that seems to be necessary for a successful launch of labwc, even with lightdm 1.32.0-6

micko01 · 2025-02-26 02:56:40

johnraff wrote:

micko01 wrote:
May be we can ditch all references to greetd/nwg-hello and just mention them somewhere for wayland purists.
It looks as if lightdm from the regular Debian Trixie repo will be able to do the job.
(And we can drop the git build I made from your repo, since it's now superseded by the Debian version.)
We could still ship the configs we (mostly you) figured out for greetd+nwg-hello in place though - they're small files, won't do any harm, and might save someone some work...

Ok, we can leave the greetd/nwg-hello stuff there

johnraff wrote:

Versions - I obviously made a mistake choosing the version number for that github build. The intention was that it would automatically be exceeded by the next Debian release of 1.32.0-6, but that didn't happen:
john@boron:~$ dpkg --compare-versions 1.32.0-6+b1 gt 1.32.0+git240823-6.1~bl1 && echo greater || echo 'not greater'
not greater
john@boron:~$ dpkg --compare-versions 1.32.0+git240823-6.1~bl1 gt 1.32.0-6+b1 && echo greater || echo 'not greater'
greater
It's really tricky.
I guess you @micko got the right version of lightdm because you hadn't previously installed 1.32.0+git240823-6.1~bl1 and the pin of 100 stopped 1.32.0-6+b1 from being upgraded? If you already had 1.32.0+git240823-6.1~bl1 it would have stayed there.
I need to think carefully in order to avoid this situation in future.

Ah I see.

johnraff wrote:

micko01 wrote:
BTW, I'm not starting labwc through bunsen-labs session yet.
So I tried on my troublesome HP laptop, updated everything and lo and behold it boots from lightdm! (debian's version - bunsen customisations are applied of course though bunsen-configs as per usual).
So is labwc being started with the 1s delay that we put in /usr/bin/bunsenlabs-session?
I think xfce-session is applying a similar delay (not plain 1s but actually looping over a check) and that seems to be necessary for a successful launch of labwc, even with lightdm 1.32.0-6

As said I'm starting labwc directly from lightdm via it's /usr/share/wayland-sessions.desktop on my main PC and the HP lappy. Works without a delay so there seems there was a bug in lightdm previous versions.

As for trying to start xfce from /usr/share/wayland-sessions/xfce-wayland.desktop from lightdm this fails with the login loop, and a quick search found some others had this issue. (sorry can't chase down references atm - IRL time constraints).
startxfce4 --wayland works fine from TTY login. This is either an xfce bug or a debian bug. I'm not getting too concerned with it.

Normal X boot with bunsenlabs-session works just fine. (lightdm)
Normal X boot for xfce works fine. (lightdm)

ATM there is no symlink bunsenlabs-session-wayland -> bunsenlabs-session in my install or any bunsens* packages yest, nor the /usr/share/wayland-sessions/bunsenlabs-wayland.desktop file for a sessions manager. Probably should fix that soonish, but no rush.

So both my systems are pretty much carbon now.

More on the situation tonight if need be as I'm back to work shortly.

johnraff · 2025-02-26 04:46:25

micko01 wrote:

johnraff wrote:
So is labwc being started with the 1s delay that we put in /usr/bin/bunsenlabs-session?
I think xfce-session is applying a similar delay (not plain 1s but actually looping over a check) and that seems to be necessary for a successful launch of labwc, even with lightdm 1.32.0-6
As said I'm starting labwc directly from lightdm via it's /usr/share/wayland-sessions.desktop on my main PC and the HP lappy. Works without a delay so there seems there was a bug in lightdm previous versions.

I think 1.32.0+git240823-6.1~bl1 is pretty much the same as 1.32.0-6+b1 and that was showing the wayland boot failure without the 1s delay. I wonder if you haven't got something in /usr/share/lightdm/lightdm.conf.d that's setting a 'session-wrapper' script?

This is what went into xfce4-session 3 months ago: https://gitlab.xfce.org/xfce/xfce4-sess … equests/68
(Refers back to BL if you look carefully.)

#61 2024-08-21 07:17:33

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#62 2024-08-21 08:22:26

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#63 2024-08-22 07:33:12

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#64 2024-08-22 10:00:02

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#65 2024-08-24 03:58:07

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#66 2024-11-12 05:32:49

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#67 2024-12-31 09:34:52

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#68 2024-12-31 10:37:25

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#69 2024-12-31 12:14:14

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#70 2025-01-01 08:47:56

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#71 2025-01-01 09:18:36

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#72 2025-02-25 08:18:05

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#73 2025-02-26 01:57:42

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#74 2025-02-26 02:56:40

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#75 2025-02-26 04:46:25

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

Board footer