Screen-locking for Xorg and Wayland

johnraff · 2025-08-11 09:08:15

This was raised by @micko01 some time ago, and we were discussing it on GitHub: https://github.com/BunsenLabs/bunsen-exit/pull/6 and https://github.com/BunsenLabs/bunsen-exit/issues/7 but I sort of lost sight of it for a while.

Now picked up again.

Topic mainly for @micko01 but of course anyone is welcome to join in.

Micko I'm sorry I overwrote your commits to bl-lock because of that decision to centre locking in bl-exit.

Ultimately, because bunsen-exit is a smaller package than bunsen-utilities, and more of a "core" package, it seemed better to configure the screen locking in bunsen-exit (command 'bl-exit --lock') and have bl-lock call it.
At the same time, we want local sysadmins to be able to set a different lock command in a config file, and separately for Xorg and Wayland.
Finally, to handle the lock commands as arrays as far as possible, so that spaces in arguments (eg filenames) can be handled properly.

The story so far is now on Github:
https://github.com/BunsenLabs/bunsen-ex … in/bl-exit
https://github.com/BunsenLabs/bunsen-ex … -exit.conf
https://github.com/BunsenLabs/bunsen-ut … in/bl-lock

This still isn't perfect but it's usable.
Unfortunately it's very difficult to store arrays in simple config files, although not impossible if we decided it was needed. At the moment the lock commands in bl-exit.conf cannot hold spaces because they're stored and read out as simple strings (although the bl-exit script itself handles them as arrays, so the default commands set directly in the script are OK).
The lock command exported to the yad dialog window also cannot be an array (that had me baffled for a day). Arrays cannot be exported in bash. Eventually I stored the command in a temporary file - not elegant but it works.
Lock commands are stored for both Xorg and Wayland, and the final choice made just before the dialog is shown.

Distinguishing between Xorg and Wayland sessions is tricky, but for now:
$WAYLAND_DISPLAY > Wayland
or
$DISPLAY > Xorg
It must be done in this order because with xwayland running (it usually is) both those variables are set.

wlr-randr looked like a good test, but it's too eager for some situations and reports a Wayland server even if there's one running on a different VT. I haven't tested what happens if there are both X and Wayland servers running.

Anyway it's all a bit gnarly, but seems to do the job.

But just yesterday, I came across xss-lock...

Last edited by johnraff (2025-08-12 01:38:38)

johnraff · 2025-08-11 09:21:29

...xss-lock looks like a handy utility for bringing screenlockers into the general desktop environment. On Xorg it's less of a problem for BL because our screenlocker, lightlocker, already responds to loginctl calls and instructions from the power manager. On Wayland, though, 'loginctl lock-session $XDG_SESSION_ID' is usually ignored. Now there's hope. Run this in a terminal:

xss-lock -- gtklock -d &

and in a different terminal:

loginctl lock-session $XDG_SESSION_ID

and gtklock starts up!

I haven't done any more testing (volunteers?) but it looks good. Maybe users can put that xss-lock line in their startup script and there'll be no need for configuring lock commands for bl-exit. Maybe even Wayland screen locking will be triggered by various system events too, just like on Xorg?

Light-locker is getting old, so some time in the future if we want to use a different locker on BL Xorg too xss-lock might do it for us.

https://wiki.archlinux.org/title/Session_lock
https://wiki.archlinux.org/title/List_o … en_lockers

hhh · 2025-08-11 17:29:07

johnraff wrote:

I haven't done any more testing (volunteers?) but it looks good.

Gonna need a little more info how to test.

1) Install boron.

2) ?

3) Profit!

johnraff · 2025-08-12 01:18:44

hhh wrote:

johnraff wrote:
I haven't done any more testing (volunteers?) but it looks good.
Gonna need a little more info how to test.
1) Install boron.
2) ?
3) Profit!

1) Install trixie - any flavour will probably do
2) Remove light-locker if it's installed, install xss-lock.
3) Read man xss-lock or xss-lock --help.
4) Install some screen locker that doesn't respond to 'loginctl lock-session $XDG_SESSION_ID' (a lot of the simpler ones).
4a) Confirm that the locker you installed is able to lock the screen if called directly.
5) Do the test decribed above ( 'xss-lock -- <mylocker> &' in a terminal) and see if loginctl now works.
6) Try adding that xss-lock line to your autostart and see if it still works.
7) Try on a Wayland session too...
8) See if xfce4-power-manager is able to lock the screen...

hhh · 2025-08-13 20:00:59

^ Nice. Let's get some feedback.

It's complicated, being WM/DE and even X/Wayland independent.

johnraff · 2025-08-16 07:05:10

According to my own testing on Wayland and X11 sessions of Carbon VM, this works.
The same command 'loginctl lock-session $XDG_SESSION_ID' will lock the screen on both!

Simple instructions to confirm: this assumes you have a Debian Trixie system with both X11 and Wayland sessions available (or else two separate systems I guess).

sudo apt remove light-locker
sudo apt install gtklock # needed for Wayland locking
# very simple X11 locking is provided by slock which BL systems should have from the suckless-tools package
sudo apt install xss-lock # used on both X11 and Wayland sessions

Now add this bit of code to ~/config/bunsen/autostart

xss-lock -- slock &

and this to ~/config/bunsen/autostart-wayland:

xss-lock -- gtklock -d &

Now you should be able to trigger a screen lock with the same command in either session:

loginctl lock-session $XDG_SESSION_ID

Users can set their screenlocker of choice in autostart or autostart-wayland by editing the command which follows 'xss-lock --'

So @micko01 does that mean that bl-exit will no longer need to have user-configured screenlock commands?
Or else set 'loginctl lock-session $XDG_SESSION_ID' as the default but leave the configurability just in case?

This doesn't mean we have to remove light-locker from our default Carbon X11 session btw - that was just to confirm xss-lock would work on both sessions - we can use xss-lock on Wayland only for now if we want because light-locker already has its own connection with loginctl.

As for xfce4-power-manager, it doesn't so far recognize xss-lock as an available screen-locker (eg if you set a lock screen time under "System"). I don't know if anything can be done there. (BTW the Wayland x-p-m looks very minimal atm.)

johnraff · 2025-08-18 09:49:00

johnraff wrote:

As for xfce4-power-manager, it doesn't so far recognize xss-lock as an available screen-locker (eg if you set a lock screen time under "System"). I don't know if anything can be done there.

It can be fixed.
Users can add a setting with xfconf-query:

xfconf-query --create -c xfce4-session -p /general/LockCommand -t string -s 'bl-exit --lock'

This means that when xfce4-power-manager wants a lock its call is sent to 'bl-exit --lock', which can be configured by BL users to whatever locking app they want.

Devs can enable this in the default settings we put in bunsen-configs by adding bunsen-configs/skel/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml containing:

<?xml version="1.1" encoding="UTF-8"?>

<channel name="xfce4-session" version="1.0">
  <property name="shutdown" type="empty">
    <property name="LockScreen" type="bool" value="true"/>
  </property>
  <property name="general" type="empty">
    <property name="LockCommand" type="string" value="bl-exit --lock"/>
  </property>
</channel>

After a logout this has the same effect as running that xconf-query command. That xml file will get installed to the user's ~/.config/xfce4/xfconf/xfce-perchannel-xml/

A question remaining is what happens if User hasn't installed bunsen-exit? They'll need to run xfconf-query with a different command to get locking from xfce to work, but I'd imagine people installing bunsen-configs but not bunsen-exit would be rather few anyway. We can help by making bunsen-exit a Recommends (if not a hard Depends) of bunsen-configs.

Another question that occurred to me today - if xfce allows regular users to set their screenlocking options without using root, is there any reason for us to put bl-exit.conf in /etc where only root can edit it? Maybe better to have a user file ~/.config/bl-exit/bl-exit.conf for bl-exit options? (Right now those options are what dialog buttons to show, and what custom screenlocker command to use for X11 and Wayland.)

johnraff · 2025-08-18 09:52:03

BTW while light-locker still seems OK on X11, it hasn't had an upstream upgrade since 2017, and Xfce are dropping it in Trixie.
https://xfce.org/about/tour

So some day we might want to start using xss-lock + some other locker in X11 sessions as well as in Wayland.

johnraff · 2025-08-19 06:25:51

I'm a bit uncomfortable with configuring the screenlocker app(s) in bunsen-configs while the locking goes via bl-exit.

Maybe if there was a mechanism where other packages than bunsen-configs could install things to skel/? But even then in this case it would involve editing an existing autostart file, not adding a new file. Surely a pair (X11 & Wayland) of BL autostart.d directories would be a complication too far...

Maybe tying bunsen-exit to bunsen-configs with an apt dependency would be enough? At least for now.

greenjeans · 2025-08-20 01:20:45

Very little to add here as I am unfamiliar with the BL protocols in this matter, but just wanted to say I have used i3lock for screenlocking for years and it's simple and fast and very configurable, and works fine with xss-lock.

johnraff · 2025-08-20 02:00:39

^Yes i3lock seems to be quite popular. Let's add it to the commented-out option lines in autostart{,-wayland} or bl-exit.conf.

So what I think we want to aim for is to have screen locking working out of the box on both X11 and Wayland, while making it easy for users to switch to their own choice of locker.

johnraff · 2025-08-20 02:08:08

johnraff wrote:

Maybe if there was a mechanism where other packages than bunsen-configs could install things to skel/? But even then in this case it would involve editing an existing autostart file, not adding a new file.

Of course there is an existing mechanism for packages to add to users' autostart - they drop a .desktop file in /etc/xdg/autostart. So in theory bl-exit could install a file there which started xss-lock... but that would still leave the problem of how the user would configure which locker they want xss-lock to trigger.

So maybe just staying with a line in the user's autostart file is the way to go, combined with a CAPITAL LETTER comment that that is the place to set their screenlocker. And a comment in the carbon release notes?

johnraff · 2025-08-31 07:27:34

OK after thinking a bit more, what about this setup?

1) bunsen-exit installs /etc/xdg/autostart/xss-lock-bunsen.desktop whose exec line is:

xss-lock -- bl-exit --lock

This keeps the xss-lock line out of users' autostart files, and instead of setting the chosen screenlocker in the xss-lock command, go back to setting it in bl-exit. It remains to actually test this, but I'm optimistic.
EDIT: looks OK.

1a) Make xss-lock a Depends Recommends of bunsen-exit. It's not a big package.
EDIT: Depends is too strict - some people might not want to use xss-lock, and everything else will still work without it.

2) In bl-exit, for the --lock option, don't use the original loginctl command, even for Xorg, but go straight to checking for X11 or Wayland session and calling the chosen screenlocker directly. (Why not loginctl lock-session? Because that would trigger the xss-lock command again and go into an endless loop.)

3) Configuration of screenlocker apps: hard-code X and W apps in bl-exit itself, but only fall back on those after checking first ~/.config/bunsen-exit/bl-exit.conf and if that's missing, /etc/bunsen-exit/bl-exit.conf. Users who want to change the configs can copy /etc/bunsen-exit/bl-exit.conf to ~/.config/bunsen-exit/bl-exit.conf and edit it there.

So 'bl-exit --lock' is the centre everything comes back to where the screenlocker is set and activated.
Any app that wants to lock the screen can call that.
And if bunsen-exit is removed, there should be no messy broken configs left over.
Side-benefit: no direct need for loginctl.

Does this all seem to make sense?

EDIT: more subtle stuff about auto-locking on inactivity etc can be checked over later...

Last edited by johnraff (2025-09-01 08:00:14)

micko01 · 2025-08-31 08:11:48

^Seems to make sense.

I've been off on holiday but will get back into things soon.

johnraff · 2025-08-31 09:49:51

^Hope you had a good time!

Just did a bit more checking and confirmed that xss-lock can be launched from a .desktop file and if set to run bl-exit --lock then whether on X11 or Wayland the dbus locking call ends up running 'bl-exit --lock'. So I'm optimistic.

johnraff · 2025-09-01 07:58:45

Maybe the final tweak - if we have .desktop files launching light-locker (for xorg sessions) and xss-lock (for wayland) then both daemons will run and they're going to clash.

Although light-locker might have some issues that cause us to drop it eventually, for now it still looks like the nicest screenlocker for xorg sessions using lightDM. They have partly fixed the clash issue for us, because even with /etc/xdg/autostart/light-locker.desktop installed, the light-locker daemon won't start up on Wayland sessions, which is just what we want (l-l doesn't work on Wayland).
EDIT: this is because it crashes with a segfault if run on Wayland, which isn't exactly elegant - better would be some mechanism by which light-locker isn't even started on Wayland.

For xss-lock, instead of running it directly from /etc/xdg/autostart/bl-xss-lock.desktop, we can make a little wrapper script bl-xss-lock:

#!/bin/sh

# launch unique instance of xss-lock,
# only if light-locker is not running

pkill -x xss-lock # may be remaining from wayland session

sleep 1 # allow time for light-locker to start

pgrep -x light-locker >/dev/null && exit 0

exec xss-lock -- bl-exit --lock

and run that from /etc/xdg/autostart/bl-xss-lock.desktop:

[Desktop Entry]
Version=1.0
Name=bl-xss-lock
Comment=Start unique instance of xss-lock for bl-exit --lock, only if light-locker is not running.
TryExec=xss-lock
Exec=bl-xss-lock
Terminal=false
Type=Application
Categories=
GenericName=
Hidden=false

That way, the light-locker daemon is running on Xorg, and xss-lock on Wayland. If light-locker is ever uninstalled, then xss-lock will run on both sessions.

EDIT:
A cleaner way to make sure light-locker doesn't try to run on Wayland is to make another little wrapper script, bl-light-locker:

#!/bin/sh

# inhibit light-locker from starting on a Wayland session, where it will segfault

[ "$BUNSEN_SESSION_TYPE" = wayland ] && exit 0

exec light-locker

And call it from ~/.config/autostart/light-locker.desktop (which will override /etc/xdg/autostart/light-locker.desktop):

[Desktop Entry]
Type=Application
Name=Screen Locker
Name[ca]=Bloquejador de pantalla
Name[cs]=Uzamykač obrazovky
Name[da]=Skærmlås
Name[de]=Bildschirmsperre
Name[en_GB]=Screen Locker
Name[es]=Bloqueador de pantalla
Name[fa]=قفل صفحه
Name[fi]=Näytön lukitusohjelma
Name[fr]=Verrouilleur d'écran
Name[gl]=Bloqueado da pantalla
Name[gu]=સ્ક્રીન લૉકર
Name[hi]=परदा अबरोधक
Name[hu]=Képernyőzár
Name[it]=Blocca schermo
Name[ja]=スクリーンのロック
Name[kk]=Экран блоктаушысы
Name[lt]=Ekrano užrakinimas
Name[nb]=Skjermlås
Name[nl]=Schermvergrendeling
Name[or]=ପରଦା ଅବରୋଧକ
Name[pl]=Blokada ekranu
Name[pt]=Bloqueio de Ecrã
Name[pt_BR]=Bloqueio de Tela
Name[ru]=Блокировщик экрана
Name[sk]=Uzamykač obrazovky
Name[tr]=Ekran Kilitleyici
Name[zh_CN]=屏幕锁
Name[zh_TW]=螢幕鎖定
Comment=Launch screen locker program
Comment[ca]=Obre el programa de bloqueig de la pantalla
Comment[cs]=Spustit Uzamykač obrazovky
Comment[da]=Start program for skærmlås
Comment[de]=Bildschirmsperre starten
Comment[en_GB]=Launch screen locker program
Comment[es]=Abrir el programa de bloqueo de pantalla
Comment[fi]=Käynnistä näytön lukitusohjelma
Comment[fr]=Lancer le verrouilleur d'écran
Comment[gl]=Iniciar o programa de bloqueo da pantalla
Comment[gu]=સ્ક્રીન લૉકર પ્રક્રિયાને શરુ કરો
Comment[hi]=परदा अबरोधक प्रोग्राम आरम्भ करें
Comment[hu]=Képernyőzár program indítása
Comment[it]=Lancia il programma blocca schermo
Comment[ja]=スクリーンロックのプログラムを実行する
Comment[kk]=Экранды блоктау бағдарламасын жөнелту
Comment[lt]=Paleisti ekrano užrakinimo programą
Comment[nb]=Kjør skjermlåsningsprogram
Comment[nl]=Schermvergrendelingsprogramma starten
Comment[or]=ପରଦା ଅବରୋଧକ ଆରମ୍ଭ କରନ୍ତୁ
Comment[pl]=Uruchamia program blokady ekranu
Comment[pt]=Lançar o programa de bloqueio do ecrã
Comment[pt_BR]=Iniciar o programa de bloqueio de tela
Comment[ru]=Запустить программу блокировки экрана
Comment[sk]=Spúšťa program na uzamknutie obrazovky
Comment[tr]=Ekran kilitleyici programını başlat
Comment[zh_CN]=启动屏幕锁程序
Comment[zh_TW]=啟動螢幕鎖定程式
Icon=preferences-desktop-screensaver
TryExec=light-locker
Exec=bl-light-locker
NoDisplay=true
NotShowIn=GNOME;Unity;

Those extra files can be shipped with bunsen-exit. The user light-locker.desktop file can be installed to /usr/share/bunsen/skel where bl-user-setup should add it to users' HOME next time they login.

Last edited by johnraff (2025-09-03 07:16:01)

johnraff · 2025-09-04 02:57:04

beginning to see why screenlocking has been such a longstanding issue in Linux

Sigh... since xfce have dropped light-locker in trixie, and there are subtle issues with black screens...
Let's try and switch to xfce4-screensaver which ought to work better with the new xfce4-power-manager.
(BTW xfce4-screensaver cleanly exits if it's on Wayland, so no need for a wrapper script there.)

Not yet fixed, and I'm going to install a default trixie xfce4 VM to see how it should work. Later, it might be a useful reference for wayland too. xfce4-screensaver doesn't work on wayland but the devs seem to be pushing hard for it, so maybe in a while it'll be a good option for an ambidextrous X11/Wayland Carbon BL.

Most stuff is already working OK, but the "lock screen when going to sleep" option is flaky.

http://dontsurfinthenude.blogspot.com/2 … e-and.html

https://forums.debian.net/viewtopic.php?t=161513
https://forum.xfce.org/viewtopic.php?id=17222
https://forum.maboxlinux.org/t/mabox-do … spend/1070
https://superuser.com/questions/1536856 … ccessfully

Last edited by johnraff (2025-09-04 08:41:20)

Head_on_a_Stick · 2025-09-04 06:08:17

^ Thanks for all your work on this, it is very useful for me.

Slightly off-topic but I use slock in deadbang and I've just noticed this in the man page:

man slock wrote:

To make sure a locked screen can not be bypassed by switching VTs or killing the X server with Ctrl+Alt+Backspace, it is recommended to disable both in xorg.conf(5) for maximum security:
Section "ServerFlags"
	Option "DontVTSwitch" "True"
	Option "DontZap"      "True"
EndSection

This is an interesting point, I might use that configuration.

johnraff · 2025-09-04 08:30:27

OK enough already. We need to get on with building the Carbon iso, so I'm going to package and upload bunsen-exit as it is now.

I've replaced light-locker with xfce4-screensaver. The login screen is not as nice-looking but you can have something on the screen to tell you the computer is alive. With luck, fewer of the mysterious black screens that light-locker used to throw up.

It seems to be working OK on Wayland too, using @micko01's suggested gtklock. Perhaps later there might be other improvements we can make...

johnraff · 2025-09-04 08:36:40

Head_on_a_Stick wrote:

I use slock in deadbang and I've just noticed this in the man page:
man slock wrote:
To make sure a locked screen can not be bypassed by switching VTs or killing the X server with Ctrl+Alt+Backspace, it is recommended to disable both in xorg.conf(5) for maximum security:
Section "ServerFlags"
	Option "DontVTSwitch" "True"
	Option "DontZap"      "True"
EndSection

Yes, I wondered about the TTY-switch bypass, but when you think about it, an attacker still has to log in with a password to do anything on the TTY, right? As for the Ctrl+Alt+Backspace... no login needed, but again with a killed X, what can an attacker do without a password?

Probably I'm forgetting something obvious...

#1 2025-08-11 09:08:15

Screen-locking for Xorg and Wayland

#2 2025-08-11 09:21:29

Re: Screen-locking for Xorg and Wayland

#3 2025-08-11 17:29:07

Re: Screen-locking for Xorg and Wayland

#4 2025-08-12 01:18:44

Re: Screen-locking for Xorg and Wayland

#5 2025-08-13 20:00:59

Re: Screen-locking for Xorg and Wayland

#6 2025-08-16 07:05:10

Re: Screen-locking for Xorg and Wayland

#7 2025-08-18 09:49:00

Re: Screen-locking for Xorg and Wayland

#8 2025-08-18 09:52:03

Re: Screen-locking for Xorg and Wayland

#9 2025-08-19 06:25:51

Re: Screen-locking for Xorg and Wayland

#10 2025-08-20 01:20:45

Re: Screen-locking for Xorg and Wayland

#11 2025-08-20 02:00:39

Re: Screen-locking for Xorg and Wayland

#12 2025-08-20 02:08:08

Re: Screen-locking for Xorg and Wayland

#13 2025-08-31 07:27:34

Re: Screen-locking for Xorg and Wayland

#14 2025-08-31 08:11:48

Re: Screen-locking for Xorg and Wayland

#15 2025-08-31 09:49:51

Re: Screen-locking for Xorg and Wayland

#16 2025-09-01 07:58:45

Re: Screen-locking for Xorg and Wayland

#17 2025-09-04 02:57:04

Re: Screen-locking for Xorg and Wayland

#18 2025-09-04 06:08:17

Re: Screen-locking for Xorg and Wayland

#19 2025-09-04 08:30:27

Re: Screen-locking for Xorg and Wayland

#20 2025-09-04 08:36:40

Re: Screen-locking for Xorg and Wayland

Board footer