Organizing the Carbon BunsenLabs sessions for Wayland and X11

johnraff · 2024-08-05 04:53:01

Xresources

LightDM, and probably most X Display Managers, loads the content of ~/.Xresources during bootup, but under Wayland this doesn't happen, so our customization of the urxvt window, for example, is lost. (Various other settings are in ~/.Xresources.)

The nwg-hello DM that we are trying out atm also fails to load ~/.Xresources, even when starting an X11 session. In fact RedHat decided long ago that loading Xresources was too time-consuming: https://bugzilla.redhat.com/show_bug.cgi?id=1225384

The upshot is that the BL session will need to do this for itself, in one of the sourced config files, or in /usr/bin/bunsenlabs-session itself:

xrdb -load ~/.Xresources

Remains just to decide where would be the cleanest place, and least confusing for users...

johnraff · 2024-08-05 08:35:15

keyboard layout

This is something else debian-installer sorts out right at the start, and it records the data in /etc/default/keyboard.
On X11, installed systems refer to that file and the keyboard is correctly set up. Unfortunately Wayland seems to have no knowlege of this information, and users have to set it up all over again - unless they're lucky enough to be using the default US keyboard.
For example, my /etc/default/keyboard:

# KEYBOARD CONFIGURATION FILE

# Consult the keyboard(5) manual page.

XKBMODEL="pc105"
XKBLAYOUT="jp"
XKBVARIANT=""
XKBOPTIONS="compose:caps"

BACKSPACE="guess"

Some Wayland compositors also have very similar-looking environment variables you can set, eg:
https://github.com/cage-kiosk/cage/wiki … -variables

The following environment variables can be used to configure behavior of libraries that Cage uses. Effectively, these environment variables configure the Cage session.
XKB environment variables
XKB_DEFAULT_RULES
XKB_DEFAULT_MODEL
XKB_DEFAULT_LAYOUT
XKB_DEFAULT_VARIANT
XKB_DEFAULT_OPTIONS

It's the usual "it's up to the compositor" story you hear from Wayland. I guess with such a new project it's unreasonable to expect them to get together with Debian to set up some kind of common framework...

Anyway, since labwc and cage both seem to support those envvars, it shouldn't be beyond our ingenuity to migrate the contents of /etc/default/keyboard into environment variables for the BL Wayland session.

...except for BACKSPACE maybe?

Last edited by johnraff (2024-08-05 08:44:52)

PackRat · 2024-08-05 17:22:59

johnraff wrote:

Xresources
The upshot is that the BL session will need to do this for itself, in one of the sourced config files, or in /usr/bin/bunsenlabs-session itself:
xrdb -load ~/.Xresources
Remains just to decide where would be the cleanest place, and least confusing for users...

Appears to already be in /usr/bin/bunsenlabs-session

usr_resources="$HOME/.Xresources"

....

    # Merge ~/.Xresources
    # (usually done by /etc/X11/Xsession.d/30x11-common_xresources)
    test -r "$usr_resources" && xrdb -merge "$usr_resources" || echo "$0: cannot merge $usr_resources" >&2

johnraff · 2024-08-06 05:31:51

^Oh yes, it is!
Although that bit of code is only run on the very first boot, at the moment.
It'll need a little rearrangement...

micko01 · 2024-08-13 08:15:42

I wrote a little script that should load keyboard settings at startup (if it is executed at startup ) for labwc.

#!/bin/bash

pidof labwc >/dev/null 2>&1 || exit 0
[ -s /etc/default/keyboard ] || exit 0 # unlikely 
if [ -z "$XKB_DEFAULT_LAYOUT" ] && ! grep -q '^XKB_DEFAULT_LAYOUT' $HOME/.config/labwc/environment ; then

  XKB_VARS=`while read line; do 
    [ -z "$line" ] && continue
    case ${line} in
      '#'*)  continue;;
      *=\"\")  continue;;
      *MODEL*)m=${line/XKBMODEL/XKB_DEFAULT_MODEL}
        m=${m/\"/}
        m=${m/\"/}
        ;;
      *LAYOUT*)m=${line/XKBLAYOUT/XKB_DEFAULT_LAYOUT}
        m=${m/\"/}
        m=${m/\"/}
	;;
      *VARIANT*)m=${line/XKBVARIANT/XKB_DEFAULT_VARIANT}
        m=${m/\"/}
        m=${m/\"/}
	;;
      *OPTIONS*)m=${line/XKBOPTIONS/XKB_DEFAULT_OPTIONS}
        m=${m/\"/}
        m=${m/\"/}
	;;
      *)m=$line
        m=${m/\"/}
        m=${m/\"/}
	;;
    esac
    echo $m
done </etc/default/keyboard`
  echo -e "$XKB_VARS" >> $HOME/.config/labwc/environment
  echo "setting up keyboard"
  . $HOME/.config/labwc/environment # reload envars
else
  echo "keyboard already set"
fi
exit 0

Note that I used bactick `...` instead of parentheses $(...) only because Scite chokes on the syntax highlighting

EDIT - a no 'bashism' version, uses grep, sed and tr

#!/bin/sh

[ -n "$LABWC_PID" ] || exit 0
[ -s /etc/default/keyboard ] || exit 0 # unlikely 
if [ -z "$XKB_DEFAULT_LAYOUT" ] || ! grep -q '^XKB_DEFAULT_LAYOUT' $HOME/.config/labwc/environment ; then

  XKB_VARS=$(while read line; do 
    [ -z "$line" ] && continue
    case ${line} in
      '#'*)  continue;;
      *=\"\")  continue;;
      XKB*)m=$(echo $line | sed  's/XKB/XKB_DEFAULT_/' | tr -d '"')
        ;;
      *)m=$(echo $line | tr -d '"')
    ;;
    esac
    echo $m
done </etc/default/keyboard)
  echo "$XKB_VARS" >> $HOME/.config/labwc/environment
  echo "setting up keyboard"
  . $HOME/.config/labwc/environment # reload envars
else
  echo "keyboard already set"
fi
exit 0

I suppose it should go to the new file "environment-wayland". Not sure yet.

Last edited by micko01 (2024-08-16 06:46:06)

johnraff · 2024-08-16 05:40:29

micko01 wrote:

I wrote a little script...
I suppose it should go to the new file "environment-wayland". Not sure yet.

I think those "environment" files are best kept for setting environment variables, possibly with the help of a shell one-liner.

So where's the best place to run a script in the bunsenlabs session? I'm not sure yet either, but scripts that can be run after starting up the compositor/windowmanager can be started from ~/.config/bunsen/autostart{,-wayland} I guess.

Some things, though, need to be done before before starting the compositor...

Like... can the keyboard layout be changed by passing an envvar after the C/WM has started up? Needs testing.

hhh · 2024-08-16 06:12:44

Just wondering, do *.desktop files in ~/.autostart run before or after OB/BL autostart?

micko01 · 2024-08-16 06:35:09

@johnraff

I think my original idea of redirecting the keyboard variables to ~/.config/labwc/environment is the way to go. Each compositor will be different however.

Below is a snippet of labwc main.c (the main() function)

It illustrates when envars, configs and externals are loaded. I'll add comments to the relevant parts - indicated by :
/* ***** comment ********* */

	wlr_log_init(verbosity, NULL); /* *************  the start  ************ */ 

	die_on_detecting_suid();

	session_environment_init(); /* ************* envars loaded here ************ */ 

#if HAVE_NLS
	/* Initialize locale after setting env vars */
	setlocale(LC_ALL, "");
	bindtextdomain(GETTEXT_PACKAGE, LOCALEDIR);
	textdomain(GETTEXT_PACKAGE);
#endif

	rcxml_read(rc.config_file);  /* ************* config ************ */ 

	/*
	 * Set environment variable LABWC_PID to the pid of the compositor
	 * so that SIGHUP and SIGTERM can be sent to specific instances using
	 * `kill -s <signal> <pid>` rather than `killall -s <signal> labwc`
	 */
	char pid[32];
	snprintf(pid, sizeof(pid), "%d", getpid());
	if (setenv("LABWC_PID", pid, true) < 0) {
		wlr_log_errno(WLR_ERROR, "unable to set LABWC_PID");
	} else {
		wlr_log(WLR_DEBUG, "LABWC_PID=%s", pid);
	}

	if (!getenv("XDG_RUNTIME_DIR")) {
		wlr_log(WLR_ERROR, "XDG_RUNTIME_DIR is unset");
		exit(EXIT_FAILURE);
	}

	increase_nofile_limit();

	struct server server = { 0 };
	server_init(&server);
	server_start(&server);

	struct theme theme = { 0 };
	theme_init(&theme, &server, rc.theme_name);  /* ************* theme ************ */ 
	rc.theme = &theme;
	server.theme = &theme;

	menu_init(&server); /* ************* menu ************ */ 

	/* Delay startup of applications until the event loop is ready */
	struct idle_ctx idle_ctx = {
		.server = &server,
		.primary_client = primary_client,
		.startup_cmd = startup_cmd    /* ************* externals including our autostart ************ */ 
	};
	wl_event_loop_add_idle(server.wl_event_loop, idle_callback, &idle_ctx);

SO the upshot of that is that we can run my script (which re-reads the labwc environment) in autostart-wayland and it *should* work (needs testing of course).

Later on, I can test other compositors and whatever they need can be added to the 'case' statement.

Keyboard is probably the most important var to set up, no type no do anything!

I really need to get hold of a proper UK keyboard or something so I can test if it works properly.

micko01 · 2024-08-16 06:40:50

hhh wrote:

Just wondering, do *.desktop files in ~/.autostart run before or after OB/BL autostart?

bl-xdg-autostart is the very last call in ~/.config/bunsen/autostart so the answer is after

hhh · 2024-08-17 04:32:28

^ Good info!

johnraff · 2024-08-17 09:30:19

micko01 wrote:

I wrote a little script that should load keyboard settings at startup (if it is executed at startup ) for labwc.
...
Note that I used bactick `...` instead of parentheses $(...) only because Scite chokes on the syntax highlighting
EDIT - a no 'bashism' version, uses grep, sed and tr
I suppose it should go to the new file "environment-wayland". Not sure yet.

Thanks for this! We're going to need to parse /etc/default/keyboard to set at least a fallback keyboard layout.

Few small things:

*) I don't think the Wayland compositors can use BACKSPACE=guess (from my /e/d/k) so it's maybe safer not to output it?

*) I'd rather use $(...) than the deprecated backticks, regardless of scite's highlighting.

*) To remove all instances of " with bash, this is enough: ${m//\"/} instead of m=${m/\"/}; m=${m/\"/}

*) In your /bin/sh version you hit on a simpler way of processing the lines, just substituting XKB_DEFAULT_ for XKB so I tried doing that in the bash version too.

*) read -r is held to be good practice, as is quoting variable expansions, even if not really necessary.

*) $HOME/.config/labwc/environment is not necessarily where it's going to write to, so let's set it as a variable at the top, so it's easier to edit.

*) If the script should be run before launching labwc - quite possible I think - then the first pidof test will fail. Just drop it? Setting some envvars shouldn't be harmful, whatever compositor is running?

*) I'm not quite sure if we should be sourcing the environment file at this point or not. Maybe leave it up to whatever is starting the session? I just did a test with .profile after starting the session and sourcing it at that time wasn't enough to change the keyboard layout.

*) Why force exit 0?

Putting those together, I might suggest this slight rearrangement of the bash version:

#!/bin/bash

envvar_file=$HOME/.config/labwc/environment
#pidof labwc >/dev/null 2>&1 || exit 0
[ -s /etc/default/keyboard ] || exit 0 # unlikely
if [ -z "$XKB_DEFAULT_LAYOUT" ] && ! grep -q '^XKB_DEFAULT_LAYOUT' "$envvar_file" ; then

  XKB_VARS=$(while read -r line; do
    [ -z "$line" ] && continue
    case ${line} in
      '#'*)
        continue
      ;;
      *=\"\")
        continue
      ;;
      XKB*)
        m=${line/XKB/XKB_DEFAULT_}
        echo "${m//\"/}"
      ;;
    esac
  done </etc/default/keyboard)

  echo -e "$XKB_VARS" >> "$envvar_file"
  echo "setting up keyboard"
  . "$envvar_file" # reload envars
else
  echo "keyboard already set"
fi

#exit 0

Looking at the removal of quotes round key="value" I wondered if a regular expression to strip out just those quotes might make the code neater, but it didn't really. The execution time was about the same too. But anyway, just for fun:

#!/bin/bash

envvar_file=$HOME/.config/labwc/environment
#pidof labwc >/dev/null 2>&1 || exit 0
[ -s /etc/default/keyboard ] || exit 0 # unlikely
if [ -z "$XKB_DEFAULT_LAYOUT" ] && ! grep -q '^XKB_DEFAULT_LAYOUT' "$envvar_file" ; then
  regex='XKB([^=]*)=\"([^"]*)\"'

  XKB_VARS=$(while read -r line; do
    [ -z "$line" ] && continue
    case ${line} in
      *=\"\")
        continue
      ;;
      XKB*)
        :
      ;;
      *)
        continue
      ;;
    esac
    if [[ "$line" =~ $regex ]]
    then
      echo "XKB_DEFAULT_${BASH_REMATCH[1]}=${BASH_REMATCH[2]}"
    fi
  done </etc/default/keyboard)

  echo -e "$XKB_VARS" >> "$envvar_file"
  echo "setting up keyboard"
  . "$envvar_file" # reload envars
else
  echo "keyboard already set"
fi
#exit 0

johnraff · 2024-08-17 10:02:17

micko01 wrote:

I think my original idea of redirecting the keyboard variables to ~/.config/labwc/environment is the way to go. Each compositor will be different however.
...
SO the upshot of that is that we can run my script (which re-reads the labwc environment) in autostart-wayland and it *should* work (needs testing of course).
...
Keyboard is probably the most important var to set up, no type no do anything!

Definitely +10 on that last point. Having to search around for where an underbar or equals sign is can be infuriating!

The debian Installer asks the user what keyboard they want to use - at least during the install - and sets it in /etc/default/keyboard, so we ought to respect that, unless they've set a different layout somewhere else later on. So whatever envvars we set need to be easily overridden.

I've just done a bit of playing around on two Carbon VMs, each running X11 and Wayland variations, one logging in through lightdm and one through greetd>cage>nwg-hello.

In all cases ~/.config/bunsen/environment-wayland or ~/.config/bunsen/environment worked because it's sourced by the bunsenlabs session. So as long as we avoid overwiting a user's customization that might be the best place. Your script does have such a test.

Keyboard envvars exported in .profile are picked up by nwg-hello in both X11 and Wayland sessions (though unnecessary for X11).

nwg-hello's login screen does not pick up the keyboard layout from ~/.config/bunsen/environment-wayland or ~/.config/bunsen/environment but cage is supposed to read those envvars so we need to find how to send them.

Lightdm does not look at .profile, but reads .xsessionrc in both X11 and Wayland sessions.

Lightdm sets the keyboard layout correctly in the login screen, presumably from .xsessionrc (not tested yet).

So there is still some work to do.

micko01 · 2024-08-17 23:36:14

^^@johnraff thanks for your input. Here is my revised version of copy-layout which I put in ~/bin to test it out.

Note that ~/config/labwc/environment must have no keyboard XKB_DEFAULT* settings to work.

#!/bin/bash

[ -n "$LABWC_PID" ] || exit 0
envvar_file="$HOME/.config/labwc/environment"
[ -s /etc/default/keyboard ] || exit 0 # unlikely 
if [ -z "$XKB_DEFAULT_LAYOUT" ] || ! grep -q '^XKB_DEFAULT_LAYOUT' "$envvar_file"; then

  XKB_VARS=$(while read -r line; do 
    [ -z "$line" ] && continue
    case ${line} in
      '#'* |  *=\"\" |  BACKSPACE*)  continue ;;
      XKB*)
         m=${line/XKB/XKB_DEFAULT_}
         m="${m//\"/}"
       ;;
      *)
	;;
    esac
    echo $m
done </etc/default/keyboard)
  echo "$XKB_VARS" >> "$envvar_file"
  echo "setting up keyboard"
  labwc -r # reloading labwc config reloads labwc's internal envars too
else
  echo "keyboard already set"
fi

I put the following line at the bottom of my ~/config/labwc/autostart but of course in a real bunsen install it would go into ~/config/bunsen/autostart-wayland

# copy keyboard settings from debian's /etc/default/keyboard file
copy-layout

Works great!

Notes:

labwc must be running, so using the envar LABWC_PID to test, which labwc sets very early
IMHO labwc/environment is the correct place to set this. labwc-tweaks uses it to change keyboard and it works instantly
labwc -r also reloads the labwc environment
runs at log in and only runs once conditionally

If you still have your labwc qemu VM you can try it for yourself.

micko01 · 2024-08-17 23:56:31

@johnraff, cage should be simple to start with the correct keyboard layout. Try this:

# change layout code to suit
XKB_DEFAULT_LAYOUT=gb cage -d scite

micko01 · 2024-08-18 01:01:08

Well the cage/nwg-hello keyboard problem turns out to be rather simple.

I got a clue from the greetd wiki

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"

Now, I don't recommend this I changed my layout in /etc/default/keyboard to XKBLAYOUT=gb so I could test and sure enough I typed in ~!@ in the password field and the gb keyboard chars showed up ¬!". Of course I was still able to log in because my password is all alpha-numeric.

johnraff · 2024-08-18 06:26:46

Sorry Micko I've run out of time, but thanks for all that.
I'll do some testing (VMs are still available) and make some comments tomorrow.

micko01 · 2024-08-18 09:31:46

No need of apologies @johnraff

In the meantime I've built and uploaded labwc-tweaks-gtk_0.0.0-2_amd64.deb to my repo.

Why the version? Well there is no release and I made a mess of the -1 deb version. Tested from repo and installs and runs fine.

Last edited by micko01 (2024-08-18 09:37:55)

altman · 2024-08-18 11:15:08

Thx for the dev work out there, appreciated.

johnraff · 2024-08-20 06:36:19

Longish discussion on the Debian-User mailing list about setting environment variables:
https://lists.debian.org/debian-user/20 … 00153.html
As usual, Greg Wooledge has some useful things to say.

micko01 · 2024-08-20 07:59:13

^ interesting

In a traditional Unix setup, all of your environment variables would be
set in ~/.profile which is read by your login shell, which is spawned
by login(1) when you login on your terminal. Then you can run 'startx'
or whatever, which starts an X session which is a child of your login
shell, and therefore inherits all of the stuff that was set in .profile.
The X session launches a window manager, and the window manager can
launch terminals on demand. The terminals inherit the environment from
the WM, which inherited it from the X session, which inherited it from
the login shell.

By that rationale wayland skips a step (naturally; X = server + wm; wayland = server == compositor), so making any environment file run by the compositor equivalent to ~/.xsessionrc

#41 2024-08-05 04:53:01

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#42 2024-08-05 08:35:15

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#43 2024-08-05 17:22:59

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#44 2024-08-06 05:31:51

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#45 2024-08-13 08:15:42

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#46 2024-08-16 05:40:29

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#47 2024-08-16 06:12:44

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#48 2024-08-16 06:35:09

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#49 2024-08-16 06:40:50

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#50 2024-08-17 04:32:28

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#51 2024-08-17 09:30:19

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#52 2024-08-17 10:02:17

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#53 2024-08-17 23:36:14

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#54 2024-08-17 23:56:31

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#55 2024-08-18 01:01:08

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#56 2024-08-18 06:26:46

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#57 2024-08-18 09:31:46

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#58 2024-08-18 11:15:08

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#59 2024-08-20 06:36:19

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

#60 2024-08-20 07:59:13

Re: Organizing the Carbon BunsenLabs sessions for Wayland and X11

Board footer