wrong desktop environment detected when starting x11 with startx

[perrin4869]

This issue was introduced in https://github.com/netbrain/zwift/pull/132 It is now using XDG_SESSION_TYPE to detect the running window manager type, but this is not a reliable method. For example, in my current x11 session, XDG_SESSION_TYPE is set to tty. I imagine this is because I boot into tty, and use startx to start x11. In this case, the necessary XAUTHORITY environment variables and volumes will not be properly passed to the container and zwift will not launch. Probably reverting to the previous method will give a more reliable result.

[sHedC]

Interesting, google told me it was a reliable way.

What are your env settings please.

[perrin4869]

$ env
BROWSER=firefox
COLORTERM=truecolor
DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus-VODONbLV9J,guid=0c0a092177b760ab4c073d64664c4490
DBUS_SESSION_BUS_PID=3240
DBUS_SESSION_BUS_WINDOWID=4194305
DISPLAY=:0
EDITOR=nvim
FILE=ranger
FZF_ALT_C_COMMAND=fd --type directories . /home/perrin4869
FZF_CTRL_T_COMMAND=fd --type file
FZF_DEFAULT_COMMAND=fd --type file
GDK_USE_XFT=1
GLFW_IM_MODULE=ibus
GNOME_KEYRING_CONTROL=/home/perrin4869/.cache/keyring-8SC2N2
GOROOT=/usr/lib64/go1.22.1/go
GPG_TTY=not a tty
GTK_IM_MODULE=fcitx
G_BROKEN_FILENAMES=1
G_FILENAME_ENCODING=@locale
HOME=/home/perrin4869
HOSTNAME=landau.julian.dotcore.co.il
IM=fcitx
INPUTRC=/etc/inputrc
JAVA_HOME=/home/perrin4869/graalvm-community-openjdk-22.0.1+8.1
KDEDIRS=/usr
KEYTIMEOUT=1
LANG=en_US.UTF-8
LC_COLLATE=C
LD_LIBRARY_PATH=/usr/lib64/zulu-openjdk17/lib/server:/usr/lib64/zulu-openjdk17/lib/server:/usr/lib64/zulu-openjdk17/lib/server
LESSOPEN=|lesspipe.sh %s
LOGNAME=perrin4869
LSCOLORS=Gxfxcxdxbxegedabagacad
LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.bat=01;32:*.btm=01;32:*.cmd=01;32:*.com=01;32:*.dll=01;32:*.exe=01;32:*.7z=01;31:*.ace=01;31:*.arj=01;31:*.bz2=01;31:*.cpio=01;31:*.deb=01;31:*.dz=01;31:*.gz=01;31:*.jar=01;31:*.lha=01;31:*.lz=01;31:*.lzh=01;31:*.lzma=01;31:*.rar=01;31:*.rpm=01;31:*.rz=01;31:*.tar=01;31:*.taz=01;31:*.tb2=01;31:*.tbz2=01;31:*.tbz=01;31:*.tgz=01;31:*.tlz=01;31:*.trz=01;31:*.txz=01;31:*.tz=01;31:*.tz2=01;31:*.tzst=01;31:*.xz=01;31:*.z=01;31:*.zip=01;31:*.zoo=01;31:*.zst=01;31:*.aac=01;35:*.anx=01;35:*.asf=01;35:*.au=01;35:*.axa=01;35:*.axv=01;35:*.avi=01;35:*.bmp=01;35:*.divx=01;35:*.flac=01;35:*.flv=01;35:*.gif=01;35:*.ico=01;35:*.jpg=01;35:*.jpeg=01;35:*.m2a=01;35:*.m2t=01;35:*.m2v=01;35:*.m4a=01;35:*.m4p=01;35:*.m4v=01;35:*.mid=01;35:*.midi=01;35:*.mka=01;35:*.mkv=01;35:*.mov=01;35:*.mp3=01;35:*.mp4=01;35:*.mp4v=01;35:*.mpc=01;35:*.mpeg=01;35:*.mpg=01;35:*.nuv=01;35:*.oga=01;35:*.ogv=01;35:*.ogx=01;35:*.ogg=01;35:*.opus=01;35:*.pbm=01;35:*.pgm=01;35:*.png=01;35:*.ppm=01;35:*.qt=01;35:*.ra=01;35:*.ram=01;35:*.rm=01;35:*.spx=01;35:*.svg=01;35:*.svgz=01;35:*.tga=01;35:*.tif=01;35:*.tiff=01;35:*.vob=01;35:*.wav=01;35:*.webm=01;35:*.webp=01;35:*.wma=01;35:*.wmv=01;35:*.xbm=01;35:*.xcf=01;35:*.xpm=01;35:*.xspf=01;35:*.xwd=01;35:*.xvid=01;35:
LS_OPTIONS=-F -b -T 0 --color=auto
MAIL=/var/mail/perrin4869
MANPATH=:/usr/lib64/zulu-openjdk17/man:/usr/lib64/zulu-openjdk17/man:/usr/lib64/zulu-openjdk17/man
MINICOM=-c on
NODE_PATH=/usr/lib64/node_modules
OLDPWD=/home/perrin4869
P9K_TTY=old
PAGER=less
PATH=/home/perrin4869/act/bin:/home/perrin4869/go/bin:/home/perrin4869/graalvm-community-openjdk-22.0.1+8.1/bin:/home/perrin4869/.local/bin:/home/perrin4869/.luarocks/bin:/usr/lib64/go1.22.1/go/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/lib64/libexec/kf5:/usr/lib64/qt5/bin:/usr/lib64/qt6/bin:/usr/lib64/zulu-openjdk17/bin:/home/perrin4869/android_sdk/platform-tools:/usr/sbin:/sbin
PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/local/share/pkgconfig:/usr/lib64/pkgconfig:/usr/share/pkgconfig:/usr/local/lib64/pkgconfig:/usr/local/share/pkgconfig:/usr/local/lib64/pkgconfig:/usr/local/share/pkgconfig
POWERLINE_COMMAND=powerline
PS1=%n@%m:%~%# 
PS2=> 
PWD=/home/perrin4869
QT5DIR=/usr/lib64/qt5
QT6DIR=/usr/lib64/qt6
QT_IM_MODULE=fcitx
SCALA_HOME=/usr/lib64/scala
SHELL=/bin/zsh
SHLVL=4
SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh
T1LIB_CONFIG=/usr/share/t1lib/t1lib.config
TERM=xterm-256color
TERMINAL=wezterm
TERM_PROGRAM=tmux
TERM_PROGRAM_VERSION=3.4
TMUX=/tmp/tmux-1000/default,3741,0
TMUX_PANE=%14
USER=perrin4869
VDPAU_LOG=0
WEZTERM_CONFIG_DIR=/home/perrin4869/.config/wezterm
WEZTERM_CONFIG_FILE=/home/perrin4869/.config/wezterm/wezterm.lua
WEZTERM_EXECUTABLE=/usr/bin/wezterm-gui
WEZTERM_EXECUTABLE_DIR=/usr/bin
WEZTERM_PANE=0
WEZTERM_UNIX_SOCKET=/run/user/1000/wezterm/gui-sock-3558
WINDOWPATH=1
XAUTHORITY=/home/perrin4869/.Xauthority
XDG_CONFIG_DIRS=/etc/xdg:/etc/kde/xdg:/etc/kde/xdg:/etc/kde/xdg
XDG_RUNTIME_DIR=/run/user/1000
XDG_SEAT=seat0
XDG_SESSION_CLASS=user
XDG_SESSION_ID=1
XDG_SESSION_TYPE=tty
XDG_VTNR=1
XMODIFIERS=@im=fcitx
ZSH=/home/perrin4869/.oh-my-zsh
ZSH_TMUX_CONFIG=/home/perrin4869/.tmux.conf
ZSH_TMUX_TERM=tmux-256color
_=/usr/bin/env
_P9K_SSH_TTY=/dev/pts/10
_P9K_TTY=/dev/pts/10
_ZSH_TMUX_FIXED_CONFIG=/home/perrin4869/.oh-my-zsh/plugins/tmux/tmux.extra.conf
P9K_SSH=0

hm... I don't know about wayland, but probably the only reliable way to detect x11 server is to check for the x11 socket

$ file /tmp/.X11-unix/X0
/tmp/.X11-unix/X0: socket

does this socket exist when running XWayland?

[sHedC]

Will check, will find some fallback way to test.

[sHedC]

Can you run this please:

loginctl show-session $(awk '/tty/ {print $1}' <(loginctl)) -p Type | awk -F= '{print $2}'

[perrin4869]

$ loginctl show-session $(awk '/tty/ {print $1}' <(loginctl)) -p Type | awk -F= '{print $2}'
tty

$ loginctl
SESSION  UID USER       SEAT  TTY  STATE  IDLE SINCE
      1 1000 perrin4869 seat0 tty1 active yes  -

1 sessions listed.

$ loginctl show-session 1
Id=1
User=1000
Name=perrin4869
Timestamp=Tue 2024-05-21 15:51:57 JST
TimestampMonotonic=69388032
VTNr=1
Seat=seat0
TTY=tty1
Remote=no
Service=login
Leader=2450
Audit=1
Type=tty
Class=user
Active=yes
State=active
IdleHint=yes
IdleSinceHint=1716274312000000
IdleSinceHintMonotonic=0
LockedHint=no

[sHedC]

ok worth a try :)

[sHedC]

Can you try these, seems specific for ssh access and slakware by the looks maybe others:

ps aux | grep [w]ayland ps aux | grep [X]

Lastly if we have $DISPLAY its X11 or XWayland but would prefer to know which and X11-unit is there for XWayland and X11.

[perrin4869]

 ~ ps aux | grep "[X]"
perrin4+  2226  0.0  0.0   4128  2304 pts/3    S+   16:58   0:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox [X]
perrin4+  3195  0.0  0.0   4100  2676 tty1     S+   May21   0:00 xinit /home/perrin4869/.xinitrc -- /usr/bin/X :0 vt1 -keeptty -auth /home/perrin4869/.serverauth.3181
root      3196  5.4  0.4 2329152 269696 tty1   Rl   May21  81:51 /usr/libexec/Xorg :0 vt1 -keeptty -auth /home/perrin4869/.serverauth.3181
 ~ ps aux | grep "[w]ayland"

hm... If I understand correctly, XWayland provides a compatibility layer for X on Wayland, therefore it would be virtually indistinguishable from real X for clients?

I think that to solve the issue, the approach should be something along the lines of:

1. detect if wayland is available
2. if it is, then decide whether to use native wayland or xwayland
3. if it is not available, then check for X availablity

[sHedC]

• detect if wayland is available
• if it is, then decide whether to use native wayland or xwayland
• if it is not available, then check for X availablity

Actually Wayland and XWayland are always there, the difference at the moment is using the wine experimental wayland which doesn't work right now because OpenGL is not properly impleneted yet.

There are some very small differences which is why I want to check one vs the other.

So I think maybe: 1) Update to check x11/ wayland using loginctl (or the environment variable) 2) if not wayland/ x11 then use ps aux to check for wayland, if blank use ps aux to check for x

I will update and submit, should be a small change

[perrin4869]

I really don't think any approach should rely on loginctl because it may point to a tty login...

[sHedC]

Nope actually thougth about that a second after I commented, I will stick with XDG first check for wayland/ x11. If anything else then will check using the ps aux and finally check DISPLAY and if there assume x11.

Would rather extend than replace as I know in most cases the XDG is working.

[perrin4869]

that would not work either, because I can login via a tty and then run a wayland server. In that case XDG would report tty, ad you would assume there is an x11 server running, but in reality I'd be running a wayland server...

the reason XDG works for most cases is because users usually login to a graphical interface, but it's not a reliable way to detect a desktop environment...

[sHedC]

Um no because if a wayland server was running it would show something in ps aux | grep [w]ayland right. Only one way to find out :)

Also I am only relying on XDG as an initial check as it returns wayland/ x11/ tty or isn't there, so if wayland find if x11 fine if anything else then check running processes;

1) XDG returns wayland 2) XDG returns x11 3) Check running wayland process 4) Check running x processes 5) check DISPLAY assume x as fall back (allows for remote displays over ssh)

so idea is this (needs a bit of tidying).

########################################
###### OS and WM Manager Settings ######
if [  "$XDG_SESSION_TYPE" == "wayland" ]; then
    # System is using wayland or xwayland.
    if [ -z $WINE_EXPERIMENTAL_WAYLAND ]; then
        WINDOW_MANAGER="XWayland"
    else
        WINDOW_MANAGER="Wayland"
    fi

    # ZWIFT_UID does not work on XWayland, show warning
    if [ $ZWIFT_UID -ne $(id -u) ]; then
        msgbox warning "XWayland does not support ZWIFT_UID different to your id of $(id -u), may not start." 5
    fi
elif [ "$XDG_SESSION_TYPE" == "x11" ]; then
    WINDOW_MANAGER="XOrg"
    unset WINE_EXPERIMENTAL_WAYLAND
else
    # Fall back look for running processes.
    if [ ! -z $(ps aux | grep [w]ayland) ]; then
        # System is using wayland or xwayland.
        if [ -z $WINE_EXPERIMENTAL_WAYLAND ]; then
            WINDOW_MANAGER="XWayland"
        else
            WINDOW_MANAGER="Wayland"
        fi
    elif [ ! -z $(ps aux | grep [w]ayland) ]; then
        WINDOW_MANAGER="XOrg"
        unset WINE_EXPERIMENTAL_WAYLAND
    elif [ ! -z $DISPLAY ]; then
        msgbox warning "Assuming x11 on $DISPLAY"
        WINDOW_MANAGER="XOrg"
        unset WINE_EXPERIMENTAL_WAYLAND
    fi
fi

[sHedC]

I know possibly overkill but there are differences between X11 and Xwayland so really need to know which, its why this started as things work on X but not on Xwayland.

[netbrain]

I asked chatgpt for an apporach to determine x,wayland and xwayland and this is what he spit out.

if pgrep -x "Xwayland" > /dev/null; then
    echo "Xwayland"
elif pgrep -x "Xorg" > /dev/null; then
    echo "X11"
elif pgrep -x "weston" > /dev/null || pgrep -x "gnome-shell" > /dev/null; then
    echo "Wayland"
else
    echo "Unable to determine display server"
fi

Not sure if this is better or worse, but ill let you be the judge of that.

[sHedC]

also worth a go :)

[sHedC]

I will keep the XDG check as currently tested rather than replace but if that fails to find x11 or wayland then follow a backup plan. But lets see.

Getting on my bike but how are you running this I can spin it up and test before submitting (I have not spent a week instaling proxmod on my desktop not to find rediculous ways of using it :))

[sHedC]

will also try remote ssh and xforwarding

[perrin4869]

I would just check if the servers (sockets) are available and remove unreliable methods like checking the XDG session I don't use wayland yet so I can't test, but according to the docs, you should check for the WAYLAND_DISPLAY For X, it's a matter of checking the XAUTHORITY and DISPLAY, and the /tmp/.X11 sockets...

[perrin4869]

the problem with running ps to check availablity is that you can name any program x11 and run it... the only reliable method is checking if the servers are running...

[sHedC]

I would just check if the servers (sockets) are available and remove unreliable methods like checking the XDG session I don't use wayland yet so I can't test, but according to the docs, you should check for the WAYLAND_DISPLAY For X, it's a matter of checking the XAUTHORITY and DISPLAY, and the /tmp/.X11 sockets...

Won't remove the XDG check as already did that to fix other issues and do not want to risk breaking what already works, and not going to test on everything again. So I will use that first then fall back to checking for something else.

For X, it's a matter of checking the XAUTHORITY and DISPLAY, and the /tmp/.X11 sockets...

This is true also for Wayland too as XWayland is available, at least some of them are, and in this case giving the option to use the Wayland native in future would not work without knowing we are running wayland.

I will do something that works. But do not want to change current logic as several issues were closed based on these checks.

[perrin4869]

This is true also for Wayland too as XWayland is available, at least some of them are, and in this case giving the option to use the Wayland native in future would not work without knowing we are running wayland.

I know that this is true for Wayland too, that's why I've been saying from the beginning that you should first check if wayland is running lol

What was the issue that XDG check solved?

[sHedC]

This is true also for Wayland too as XWayland is available, at least some of them are, and in this case giving the option to use the Wayland native in future would not work without knowing we are running wayland.

I know that this is true for Wayland too, that's why I've been saying from the beginning that you should first check if wayland is running lol

What was the issue that XDG check solved?

Fedora 40 Wayland would not display under podman Hyperland would not display under Elementory OS and XFCE under X11 One on an X server not displaying properly either can't remember.

How about this in simplified form I know your point about XDG SESSION TYPE just really really don't want to risk breaking a startup script working for people.

I think this would also work for ssh but going to check and if XDG Session Type is not set or is not Wayland or X11 then it would use the DISPLAY environment vars.

I moved the unset WINE_EXPERIMENTAL_WAYLAND to later in the X11 part and move the Wayland checks after determining the session type.

########################################
###### OS and WM Manager Settings ######
case "$XDG_SESSION_TYPE" in
    "wayland")
        WINDOW_MANAGER="Wayland"
    ;;
    "x11")
        WINDOW_MANAGER="XOrg"
    ;;
    *)
        if [ ! -z $WAYLAND_DISPLAY ]; then
            WINDOW_MANAGER="Wayland"
        elif [ ! -z $DISPLAY ]
            WINDOW_MANAGER="Xorg"
        fi
    ;;
esac

# Verify which system we are using for wayland and some checks.
if [ "$WINDOW_MANAGER" = "Wayland" ];
    # System is using wayland or xwayland.
    if [ -z $WINE_EXPERIMENTAL_WAYLAND ]; then 
        WINDOW_MANAGER="XWayland"
    else
        WINDOW_MANAGER="Wayland"
    fi

    # ZWIFT_UID does not work on XWayland, show warning
    if [ $ZWIFT_UID -ne $(id -u) ]; then
        msgbox warning "XWayland does not support ZWIFT_UID different to your id of $(id -u), may not start." 5
    fi
fi

[perrin4869]

yeah, that looks like it should work, although I'm still wondering what problem the XORG check is solving there, but sure

[sHedC]

yeah, that looks like it should work, although I'm still wondering what problem the XORG check is solving there, but sure

Nothing that the second check should not do, its the "Should" in that statement that I don't want to risk :)

[perrin4869]

I know, but it's probably a good idea to know what problem it's solving lol

[sHedC]

I know, but it's probably a good idea to know what problem it's solving lol

Basically what the second check should do but without loading and testing every distro and windows manager I am not 100% sure.