Created attachment 1711901 [details] xterm in X11 (incorrect font) Description of problem: Non-CSD titlebars are using an incorrect font in X11. Steps to Reproduce: 1. Open any application that is not using client-side-decorations 2. Observe the font used Actual results: Incorrect font in the titlebar Expected results: Cantarell used in the titlebars Additional info: Attaching screenshots of xterm (an app I installed that _definitely_ does not use CSD) in both X11 and Wayland
Created attachment 1711902 [details] xterm in Wayland (correct font: Cantarell)
gsd-xsettings is not running; it looks like this is a regression due to that. When I run /usr/libexec/gsd-xsettings and launch a new terminal, it has the correct font in the titlebar.
The most likely explanation is that GNOME_SETUP_DISPLAY is set incorrectly. But, that is weird, because gnome-session should be unsetting the variable. So, either unsetting is failing, or mutter is uploading some incorrect value. To narrow it down further, the following would be interesting: * systemctl --user show-environment |grep DISPLAY To check whether GNOME_SETUP_DISPLAY is set (it really should *not* be in an X11 session) * Try again after a reboot, wait more than 10s between logging out and logging back in, or run "loginctl kill-user X" to make sure the systemd user instance is gone. Then try again, things will be fine then if we are leaking GNOME_SETUP_DISPLAY from a wayland session to a non-wayland one. Moving to gnome-session for now.
It appears *something* is wiping the DISPLAY environment variable from systemd after the shell starts. That seems really … odd i.e. Garrett reported the following environment in the running session, which completely lacks $DISPLAY: HOME=/home/garrett LANG=en_US.UTF-8 LOGNAME=garrett PATH=/home/garrett/.local/bin:/home/garrett/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin SHELL=/bin/bash USER=garrett XDG_RUNTIME_DIR=/run/user/1000 XDG_DATA_DIRS=/home/garrett/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DESKTOP_SESSION=gnome-xorg EDITOR=/usr/bin/nano GDMSESSION=gnome-xorg GDM_LANG=en_US.UTF-8 HISTCONTROL=ignoredups HISTSIZE=1000 HOSTNAME=fedora LESSOPEN=$'||/usr/bin/lesspipe.sh %s' MAIL=/var/spool/mail/garrett PWD=/home/garrett QT_IM_MODULE=ibus SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/1891,unix/unix:/tmp/.ICE-unix/1891 SHLVL=0 SSH_AGENT_PID=1818 SSH_AUTH_SOCK=/run/user/1000/keyring/ssh USERNAME=garrett WINDOWPATH=2 XDG_CURRENT_DESKTOP=GNOME XDG_MENU_PREFIX=gnome- XDG_SESSION_CLASS=user XDG_SESSION_DESKTOP=gnome-xorg XDG_SESSION_TYPE=x11 XMODIFIERS=@im=ibus
*** Bug 1870305 has been marked as a duplicate of this bug. ***
OK, the reason is simple … We pull in both: * org.gnome.Shell * org.gnome.Shell The wayland service has an ExecCondition= to unset some environment variables. And ExecStopPost= is executed even when the ExecCondition= fails. So all we need to do is to add a check to skip execution in that case.
OK, patch to fix this is submitted upstream.
*** Bug 1870847 has been marked as a duplicate of this bug. ***
*** Bug 1871166 has been marked as a duplicate of this bug. ***
I went ahead and backported Benjamin's fix to gnome-shell-3.37.90-2.fc34 and gnome-shell-3.37.90-2.fc33