-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
X sessions don't launch Xorg #15
Comments
Could you post such an example X session file or name such a DE? I'm using ReGreet with Xfce, which launches an X server. |
xfce is indeed an interesting one. Assuming the debian package, the xfce session actually launches
That just launches the window manager, which requires X to already be running, and for the xinit scripts to be sourced. I'm taking the debian packages here because debian seems like it'd be the best source for de-facto standard behavior, but the same was true at some point in the past for at least the awesomewm and herbstluftwm packages across various versions of gentoo, Arch and NixOS - I've been fighting this battle far too long ;) |
Hmm, so the intended behaviour indeed is to start the X server and then an X session. I'll try to get this done. |
here is an example where it fails:
|
As a hint, #16 intends to solve this, but struggles with internal inconsistencies of the Xorg spec. Personally I've resorted to just using the sample gtk greeter because it's a bit quicker, and I've come to believe that the desktop file spec is so broken it's not worth using over hand-rolled scripts. |
@hariseldon78 Could you try #16 to see if it works? |
sure, i'll try it tonight |
sorry for my rust ignorance: when i try to compile i get this error:
|
Are you using Rust 1.640+ to compile it? |
ok, it turns out i was using an ancient version of 2019 🤦 |
Check that you're using the correct X init file. Since this calls |
a workaround would be to set the XSERVERRC variable in the .desktop file for your Xorg session/wm to point to a custom file for startx that starts the desired environment for example:
/home/winter/.xinit/openboxinitrc just has whatever you want launched by startx (openbox-session in my case) |
@TLATER Can you share how you run your X11 sessions? By gtk greeter, do you mean the one by kenny? I wish to run herbstluftwm with ReGreet. I am using Arch Linux. The desktop entry for herbstluftwm shows the following: ~$ cat /usr/share/xsessions/herbstluftwm.desktop
[Desktop Entry]
Encoding=UTF-8
Name=herbstluftwm
Comment=Manual tiling window manager
Exec=herbstluftwm --locked
Type=Application It seems like tuigreet does something to properly run X11 sessions. See their |
Admitting that I am a total xorg noob: I'm having an hard time starting i3 on greetd+regreet on archlinux.
|
It depends on how exactly your distro packages the xinit scripts, which is what makes this so hard to fix. I couldn't figure out a clean behavior that will do what is expected on all systems. Hence I went with the more practical solution of using gtkgreet (yes, the one by kenny) and just writing scripts that do what I expected them to do. They basically just ran #16 would also get most of the way there, since it basically does just that, it's just not a proper drop-in replacement for gdm & co., so its actual behavior on various distros (presumably non-Arch since that's what @rharish101 seems to use) may vary. Personally I've completely migrated away from X11-based window managers since, because frankly this was all too messy to maintain. Wayland of course is its own can of worms since there's no standardization around session scripts at all (yet, though I guess systemd technically offers one), but at least the ecosystem isn't pretending there is one. |
@TLATER Guess I'll make a Some interesting things for my current SDDM display manager is that it runs during the startup, as per Apr 13 19:07:32 archsys sddm-greeter[1104]: Reading from "/usr/share/xsessions/herbstluftwm.desktop"
Apr 13 19:07:32 archsys sddm[1049]: Message received from greeter: Login
Apr 13 19:07:32 archsys sddm[1049]: Reading from "/usr/share/xsessions/herbstluftwm.desktop"
Apr 13 19:07:32 archsys sddm[1049]: Session "/usr/share/xsessions/herbstluftwm.desktop" selected, command: "herbstluftwm --locked" for VT 2
# ...SNIP...
Apr 13 19:07:32 archsys sddm-helper[1228]: Starting X11 session: "" "/usr/share/sddm/scripts/Xsession \"herbstluftwm --locked\"" So it seems to use the script called The script is as follows: #! /bin/sh
# Xsession - run as user
# Copyright (C) 2016 Pier Luigi Fiorini <[email protected]>
# This file is extracted from kde-workspace (kdm/kfrontend/genkdmconf.c)
# Copyright (C) 2001-2005 Oswald Buddenhagen <[email protected]>
# Note that the respective logout scripts are not sourced.
case $SHELL in
*/bash)
[ -z "$BASH" ] && exec $SHELL --login $0 "$@"
shopt -q login_shell || exec $SHELL --login $0 "$@"
set +o posix
;;
*/zsh)
[ -z "$ZSH_NAME" ] && exec $SHELL --login $0 "$@"
[[ -o login ]] || exec $SHELL --login $0 "$@"
emulate -R sh
;;
*/csh|*/tcsh)
# [t]cshrc is always sourced automatically.
# Note that sourcing csh.login after .cshrc is non-standard.
xsess_tmp=`mktemp /tmp/xsess-env-XXXXXX`
$SHELL -c "if (-f /etc/csh.login) source /etc/csh.login; if (-f ~/.login) source ~/.login; /bin/sh -c 'export -p' >! $xsess_tmp"
. $xsess_tmp
rm -f $xsess_tmp
;;
*/fish)
[ -f /etc/profile ] && . /etc/profile
[ -f $HOME/.profile ] && . $HOME/.profile
xsess_tmp=`mktemp /tmp/xsess-env-XXXXXX`
$SHELL --login -c "/bin/sh -c 'export -p' > $xsess_tmp"
. $xsess_tmp
rm -f $xsess_tmp
;;
*) # Plain sh, ksh, and anything we do not know.
[ -f /etc/profile ] && . /etc/profile
[ -f $HOME/.profile ] && . $HOME/.profile
;;
esac
[ -f /etc/xprofile ] && . /etc/xprofile
[ -f /usr/local/etc/xprofile ] && . /usr/local/etc/xprofile
[ -f $HOME/.xprofile ] && . $HOME/.xprofile
# run all system xinitrc shell scripts.
if [ -d /etc/X11/xinit/xinitrc.d ]; then
for i in /etc/X11/xinit/xinitrc.d/* ; do
if [ -x "$i" ]; then
. "$i"
fi
done
fi
# Load Xsession scripts
# OPTIONFILE, USERXSESSION, USERXSESSIONRC and ALTUSERXSESSION are required
# by the scripts to work
xsessionddir="/etc/X11/Xsession.d"
OPTIONFILE=/etc/X11/Xsession.options
USERXSESSION=$HOME/.xsession
USERXSESSIONRC=$HOME/.xsessionrc
ALTUSERXSESSION=$HOME/.Xsession
if [ -d "$xsessionddir" ]; then
for i in `ls $xsessionddir`; do
script="$xsessionddir/$i"
echo "Loading X session script $script"
if [ -r "$script" -a -f "$script" ] && expr "$i" : '^[[:alnum:]_-]\{1,\}$' > /dev/null; then
. "$script"
fi
done
fi
if [ -d /etc/X11/Xresources ]; then
for i in /etc/X11/Xresources/*; do
[ -f $i ] && xrdb -merge $i
done
elif [ -f /etc/X11/Xresources ]; then
xrdb -merge /etc/X11/Xresources
fi
[ -f $HOME/.Xresources ] && xrdb -merge $HOME/.Xresources
if [ -f "$USERXSESSIONRC" ]; then
. "$USERXSESSIONRC"
fi
if [ -f "$USERXSESSION" ]; then
. "$USERXSESSION"
fi
if [ -z "$*" ]; then
exec xmessage -center -buttons OK:0 -default OK "Sorry, $DESKTOP_SESSION is no valid session."
else
exec $@
fi |
I have made instructions on making greetd greeters work with X11 sessions here: |
Thank you for the contribution @RayZ0rr ! I will try in the future in case I would give xorg another shot with regreet |
Forgive me if I misunderstand something myself here, but aiui, the X session commands defined in
/usr/share/xsession
expect to be executed in an already running X server. regreet does not launch an X server before executing those scripts, and therefore does not seem to be able to launch X sessions defined in xsession files written for traditional display managers.Is this correct, and intended? Can this be clarified in the readme?
Just trying to understand what exactly regreet intends to support, absolutely do not fault you for not fully implementing this de-facto "standard". Having spent the better part of three hours trying to figure out why my X sessions aren't starting and going down the rabbit hole of Xsession scripts again, the entire thing seems fragile. No wonder display managers have always been a pain to configure.
The text was updated successfully, but these errors were encountered: