2

I’d like to set an environment variable, for every users, when running Gnome under Wayland. The variable should not be set when running Gnome under X11. For concreteness, say I want to set the variable QT_QPA_PLATFORM to the value wayland when running Wayland.

I tried putting QT_QPA_PLATFORM=wayland in /usr/share/gdm/env.d/wayland-env (following the doc mentioned here) (hoping this would have an effect only under Wayland) but this seems to have no effect, even under Wayland: after rebooting, logging under Gnome / Wayland, opening a terminal: echo $QT_QPA_PLATFORM yields nothing.

I use a freshly installed Debian Bullseye.

2 Answers2

1

This should work under debian:

You can create a simple script that determines whether or not the machine is running under X11 or Wayland:

loginctl show-session "$XDG_SESSION_ID" -p Type --value

Can return either X11 or Wayland (It can also return tty)

Therefore:

if [[ $(loginctl show-session "$XDG_SESSION_ID" -p Type --value) = 'wayland' ]]; then
    export QT_QPA_PLATFORM=wayland
fi

You can also just check whether or not your session uses $DISPLAY or $WAYLAND_DISPLAY as one of its environment variables.

On bash, you can can place scripts you wish all users to execute after login in /etc/profile.d. Don't forget to make it executable and make sure it has an extension .sh.

0

I stumbled upon a discussion about systemd that lead me to a possible answer. (Sorry for answering my own question.)

Which files are executed under what conditions exactly at start is still unclear to me, but on my system at least, the file /etc/profile seems to be executed when starting Gnome (including when running Wayland). It executes in turn the files under /etc/profile.d/. Taking example on the file im-config_wayland.sh, I have created a file /etc/profile.d/wayland.sh that sets the environment variables I want conditionally, depending on whether Wayland is ran. Here is its content.

test "$XDG_SESSION_TYPE" = 'wayland' || return
export QT_QPA_PLATFORM=wayland

I suspect that more elegant solutions exist, for example, that would not set these variables when running non-graphical shells. But at least, this approach solves my concrete problem for now…