On Tue, Nov 27, 2018 at 10:32:24AM -0600, David Wright wrote: > > Question 2.1: Why .xsession is not read and .xsessionrc is read? > > Don't know. But you haven't posted how you start X.
He said he used "xdm and kdm", if I recall correctly. Sounds like he is switching things around randomly and frequently, instead of focusing on one setup and describing it in detail. > I use startx myself. Same. > But AIUI Debian has put a lot of effort into > making it possible for X server sessions to end up in the same > configuration whether they were started from a VC or a DM. Your using > .xsessionrc sounds as if you might be working around some other > "misconfiguration" that's happened to work until now. It might even > have been like that since the "Great X Reorganisation" back in the > days of slink. My understanding is .xsessionrc was created in order to give users a modicum of control over their own lives if they happen to use GNOME. Since normally a gdm3/GNOME session will ignore everything in the user's .xsession file, Debian created this other file that can be used with GNOME. Or with sddm/KDE, or lightdm, or xdm, or whatever other bizarre display managers may appear in the future and screw everything up even more. I documented everything I could figure out about .xsessionrc and friends at <https://wiki.debian.org/Xsession>. There are definitely holes in my knowledge when it comes to Desktop Environments (GNOME, KDE, and their ilk), because I do not use them. The more I learn about them, the less I want to be anywhere near one. Ever. If the OP, or anyone else, wants help understanding how their X startup works, we need a few concrete pieces of information before we can even begin: 1) What version of Debian are you using? 2) How do you log in to your computer? If it's a display manager (graphical login), which one is it? If you need help figuring this out, see below. 3) How do you start X? (Do you explicitly type a command, or is it started automatically by your graphical login?) Figuring out which display manager you are using: This is freakin' hard. Way harder than it needs to be, in my opinion, but I don't have any specific suggestions for how to remedy this, short of the display managers individually choosing to identify themselves in some way on the screen. There are two ways I can think of to approach the situation. The first is to ask the Debian package manager which display manager(s) are installed. This basically means you need to know the names of ALL of the common display manager packages, so you can ask for them all. As a shortcut, however, we can take advantage of the fact that most of them end with the letters "dm", or with the letters "dm" followed by a single digit. Thus: # dpkg -l \*dm \*dm\[0-9] Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==============-============-============-================================= un gdm3 <none> <none> (no description available) ii kde-config-sdd 4:5.8.4-1 amd64 KCM module for SDDM un mdadm <none> <none> (no description available) ii sddm 0.14.0-4+deb amd64 modern display manager for X11 On this system, it looks like sddm is installed. So that's probably the display manager that's in use. The second approach is to log out of your X session so that the display manager is actually running. Then login on the text console (by pressing Ctrl-Alt-F2), or by ssh-ing into the computer, and ask the system which display manager processes are running. Again, this requires that you have some knowledge of the *names* of these processes, so you know what to look/ask for. # ps -ef | grep gdm root 32374 32342 0 12:01 pts/0 00:00:00 grep gdm Nope. # ps -ef | grep lightdm root 32376 32342 0 12:01 pts/0 00:00:00 grep lightdm Nope. # ps -ef | grep sddm root 603 1 0 Nov02 ? 00:00:00 /usr/bin/sddm root 683 603 0 Nov02 tty7 00:38:45 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/sddm/{2b3b5bd9-8457-4fd5-b80d-b4c78b6bbc85} -background none -noreset -displayfd 18 vt7 root 1155 603 0 Nov02 ? 00:00:00 /usr/lib/x86_64-linux-gnu/sddm/sddm-helper --socket /tmp/sddm-authe24f9403-2eb8-4029-a8c8-83969060da79 --id 2 --start /usr/bin/sddm-greeter --socket /tmp/sddm-:0-nWnvBg --theme /usr/share/sddm/themes/debian-theme --user sddm --greeter sddm 1157 1 0 Nov02 ? 00:00:00 /lib/systemd/systemd --user sddm 1158 1157 0 Nov02 ? 00:00:00 (sd-pam) sddm 1160 1155 0 Nov02 ? 01:40:22 /usr/bin/sddm-greeter --socket /tmp/sddm-:0-nWnvBg --theme /usr/share/sddm/themes/debian-theme sddm 1168 1 0 Nov02 ? 00:00:00 dbus-launch --autolaunch 5942ce2e232449d09bfb1b98b5b26d87 --binary-syntax --close-stderr sddm 1169 1 0 Nov02 ? 00:00:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session root 32378 32342 0 12:01 pts/0 00:00:00 grep sddm Bingo! Looks like sddm is in use. Of course, a third method would be to know what each display manager actually *looks* like on the screen, so that you can identify it visually. If you can do that, great. I don't expect it to be a realistic choice for most people.