A recent thread on nixers got me thinking about the Xserver. We often interract with it either through startx or a display manager. How many ways can we actually send parameters to the X server, actually how many ways do we have to start an X session.

The first one is through the display manager, this is specific to each one and I'll take the case of lightdm.
lightdm.conf allows to pass parameters to the Xserver via the xserver-command = directive.

For example:


An obvious way to pass parameters to the Xserver is through its configuration files. For example, Xorg has a bunch in /etc/X11.

From man 5 xorg.conf:

Now what if you are using startx(1).


Anything after the -- will be considered arguments to the Xserver, if not starting with / or ./

So you can do the following:

startx executes by default the server found in $HOME/.xserverrc or the one in the xinit directory, usually these days /etc/X11/xinit/xserverrc.

Similarly, if you are using xinit(1).


Anything after the -- will be considered arguments to the Xserver, executing by default xserverrc, just like startx.

So why use startx at all, you might ask.

startx is a wrapper over xinit to make it easier to start a session, though...


So what does it do?

It gets the next available display by looping in /tmp/.X{digit}-lock and /tmp/.X11-unix/X{digit}, and the tty number by executing tty(1).

It also sets features for xauth if enabled, like setting the .Xauthority environment variable, creating an authentication cookie (mcookie) and registering it using xauth(1). And cleans the allocated vt (deallocvt) and xauth session if needed. But the Xauth isn't mandatory.

In the end you get a line like this to open a session on display :1 and TTY 2:



So you can definitely pass your arguments to the Xserver there.


But what if we go further and run Xorg ourselves, what do we need xinit for anyway. Let's go all the way.

From the Arch Wiki:

Quote:The Xorg(1) command is usually not run directly, instead the X server is started with either a display manager or xinit.

It was quite hard to find a way to run the Xorg(1) Xserver directly from the TTY without xinit and without messing up everything. But you can do it in the same way you would launch a Xephyr Xserver or Xvfb Xserver or others — Same o' same o'.

The following starts an Xorg Xserver on display :1 and TTY 2, and runs the session over it (xinitrc script).

The sleep is sort of mandatory if you want to start Xorg in the background. (EDIT: or you can wait for the process like sx does or similar to what vain's version does capturing USR1 does the trick)

So many layers of indirection, startx calls xinit, xinit calls the Xserver.

That's it folks, I hope you enjoy this little escapade.
And comment with your own thoughts and ways to start X.

I always liked this, a friend made some time back.
https://github.com/Earnestly/sx

Wow really interesting stuff, I had no idea startx and xinit were basically wrappers! Does this mean that display managers are doing the same thing behind the scenes without calling xinit?

(06-09-2020, 04:34 PM)octahedral Wrote: Does this mean that display managers are doing the same thing behind the scenes without calling xinit?

Display managers do quite a lot more, like managing sessions login (consolekit/login1/etc), seats (useful in a multiseat system, I haven't actually encountered any real use for this, I don't know of any software using login1 to query the seat and use that value), checking if they are running inside X already to use Xephyr as the Xserver (not sure if this has any usage either), they can connect to remote X servers, they may communicate with the Xserver using XDMCP (X Display Manager Control Protocol) if an XDMCP server is running and configured (not usually by default on user machines, also maybe only useful in Citrix-like/remote-desktop environment and mostly deprecated), or via VNC aka running with Xvnc (also not usually by default on user machines), they can have a nice UI to login along with a plymouth (on Linux) splashscreen/bootsplash, set the xsession environment related stuff (like startx and others), etc.
I think maybe TeamViewer actually uses the remote desktop features of display managers, probably vnc. I ran wireshark but there's a wireguard VPN session going on, so I can't know what's actually happening, and ss doesn't show the display manager listening either. Filtering by "vnc || xdmcp || x11" on any interfaces shows nada, but it's definitely UDP packets as I can see the IP of the other machine. Maybe someone can correct me on this, it's probably doing something on the unix-socket level or dbus. EDIT: Actually, I've found that it uses multiseat feature of the displaymanager, SeatNew and others are emitted by /org/freedesktop/login1 bus, so that's it.

But basically, when it's local, which is the case 99% of the time today, it does the same as xinit but with the advantage of handling the login and having a nice UI, see lightdm for example.



Also, display managers aren't limited to X11, they can support Wayland sessions too.

Might be of interrest to: https://github.com/dylanaraps/bin/blob/master/x

If I had 4 PCs running X Windows, what’s the best way to logon to all 4 using one single sign-on?

(07-09-2020, 11:30 AM)illusive Wrote: If I had 4 PCs running X Windows, what’s the best way to logon to all 4 using one single sign-on?

I'm really not sure but I think you would have to use something like PAM or SSSD, if available on your platform, maybe along with a centralized authentication mechanism like Kerberos or LDAP.
I don't think any of the display managers currently support this out of the box.

If you're referring to graphical sessions, you'd have to launch each one on a different display and tty, so 4 in total. Which can be done with a simple script, maybe something using Xvnc and a swapping of display on every line.

I'm sure others might have more ideas about this than me though.

Someone on reddit mentioned something interesting, instead of using local sockets, or steams pipes, or named, pipes, etc. You can use shared memory instead.

Quote:You really want to use -extension MIT-SHM and start without root.
Actually you want to sandbox it and ideally not use it at all.

It has the advantage of being more secure.

To use it you first have to check if you have the extension in your current Xserver implementation:

Then like the -maxcients 2048 arguments we tried to pass, you'll also have to plug it in the Xserver start line.
However, it plays badly with some aplications, so keep that in mind.

(07-09-2020, 07:31 AM)z3bra Wrote: Might be of interrest to: https://github.com/dylanaraps/bin/blob/master/x

Really cool find, I haven't used signals much and have never seen a trap inside a subshell before.
I've been testing this script trying to figure out how it would be used. I was assuming that USR1 is used to reset sowm but then how is sowm run in the first place?

(08-09-2020, 10:00 PM)octahedral Wrote: I've been testing this script trying to figure out how it would be used. I was assuming that USR1 is used to reset sowm but then how is sowm run in the first place?

I think it's used to start it, and not reset it.
I wanted to combine both (start X then the WM) in the script above but I didn't want to bother watching for sessions files in /tmp/.X11/ or watch for the PID to know when X is done launching. I think starting the WM using a kill signal is pretty ingenious.

(06-09-2020, 02:16 AM)Halfwit Wrote: I always liked this, a friend made some time back.
https://github.com/Earnestly/sx

This looks clean and simple. I use it now. :) Well, a slightly modified version, so I can keep my ~/.xinitrc and ~/.xserverrc.


I wondered why startx is a shell script and xinit is a C program. Turns out, xinit actually acts as an X client for a brief moment in order to set the environment variable $WINDOWPATH. I have never heard of that and it only shows up in one manpage on my system: brlapi_tty. Indeed, setting this variable was added explicitly for braille support: https://bugs.freedesktop.org/show_bug.cgi?id=8013 . The first comment explains what it is:

Quote:a WINDOWPATH environment variable that contains the "window path"
of the X server, i.e. the list of VT or Xnest windows that lead to the actual
session. It might be useful for other uses too.

Well, I've never seen it being used, so maybe only braille support really needs it ...


And one other thing:
Can be seen in the source code of xorg-xinit: https://xorg.freedesktop.org/releases/in....1.tar.bz2 . It contains "startx.cpp" with all the ifdefs. The final "startx" script is generated through automake and friends.

(13-09-2020, 02:31 PM)vain Wrote: The final "startx" script is generated through automake and friends.

automake has friends?

/sarc