Exploring the operating principle and Startup Process of X Window System (nios.org)

Exploring the operating principle and Startup Process of X Window System

Xfree86 and startx started TWM for the first time in Debian. After gnome was installed, startx started the gnome environment. Why? What files were modified when gnome was installed and how the X environment got up? I was trying to find out these questions and start to study this question. I did not expect to learn many other things. ^_^ this article mainly describes the basic operating principle of X Window System and Its startup process, and common cross-network running X Window System.

1) basic operating principles
X Window System adopts the C/S structure, but it is different from the common C/S structure. In a common C/S structure, the provider is a server, that is, a server (such as an HTTP service or an FTP service). A service is called a client, that is, a client. In X Window System, the client is the party that executes the program and executes various x programs on it, while the server is the party that displays the window in which the client runs the program.
The composition of X Window System can be divided into three parts: X server, X client, and X protocol. X server controls input and output, maintains fonts, colors, and other related resources. It accepts input information from the input device and transmits it to X client. X client also outputs the information returned after processing the information to the output device (the display we see). The information transmitted by X server to X client is called an event, which is mainly information about keyboard and mouse input and window status. The information that X client sends to X server is called request, which requires X server to create a window, change the window size and position, or draw and output text on the window. X client is mainly used to complete application computing and does not accept user input. All input information is input to X server, the X server then sends the event to the X client (similar to the Windows message mechanism, the system receives the user's input information and then transmits the message to the window, it is then processed by the message processing process in the window ). After the X client processes the received event, if it needs to output the event to the screen or change the screen appearance, it sends a request to X server, which is responsible for display.
Generally, X Server and X client run on the same computer, but they can also be on different computers on different networks. In X Window System, X client is not related to hardware. It does not care about the graphics card, the monitor, and the keyboard and mouse. These are only related to X server. After xfree86 is installed, we usually run xf86config or xf86cfg to configure only the X server. It can be said that the X server is configured, and the X client program can be run without configuration (for example: xeyes-display xserver: 0: the large eyes are displayed on the screen 0 (displaynumber is 0) on the xserver ).
X protocol is the communication protocol between X Server and X client. X protocol supports common network communication protocols. I can only test TCP/IP. We can see that X server listens on TCP port 6000. Then the X protocol is located above the transport layer. Should it belong to the application layer ?.
Let's summarize the running process:
(1) You can use the mouse and keyboard to issue operation commands to X server.
(2) X server uses event to transmit user operation information to X client
(3) X client program operations
(4) X client uses request to return the result to be displayed
(5) X server displays the result on the screen

2) Startup Process
Generally, the startx command is used to access X from the console. Start with startx analysis. First, man startx and man xinit can see how staratx and xinit are used:
Startx [[client] Options...] [-- [server] Options...]
Xinit [[client] Options] [-- [server] [display] Options]
The preceding [client] and [server] are called client programs and server programs respectively. The man manual must start with/or.
Next, let's take a look at the startx script, which is a Chinese annotation. This script is obtained after X-window-system-core is installed. It is all xfree86, in Linux of Different releases, the script should be similar:

Code:

#! /Bin/shuserclientrc = $ home /. xinitrc # user client definition file userserverrc = $ home /. xserverrc # user server definition file sysclientrc =/usr/x11r6/lib/X11/xinit/xinitrc # system clientsysserverrc =/usr/x11r6/lib/X11/xinit/xserverrc # System serverdefaultclient =/usr/x11r6/bin/xterm # Default Client Program defaultserver =/usr/x11r6/bin/X # default server program defaultclientargs = "" # The following defines the client and the server Parameter Variable defaserverserverargs = "" clientargs = "" serverargs = "" # If the user client file exists Use the client defined in the user file. Otherwise, use the clientif [-F $ userclientrc] defined by the system; then defaultclientargs = $ userclientrcelif [-F $ sysclientrc]; then defaultclientargs = $ sysclientrcfi # If the user Server File exists, use the server defined in the user file; otherwise, use the serverif [-F $ userserverrc] defined by the system; then defaserverserverargs = $ userserverrcelif [-F $ sysserverrc]; then defaserverserverargs = $ sysserverrcfi # The following cyclically processes the client and server parameters whoseargs = "client" while [X "$1 "! = X]; do # If the first parameter is null, exit the loop case "$1" in # ''required to prevent CPP from treating "/*" as a C comment. /''' * | /. /''' *) # If $1 is/* or. /* Format (the xinit program requires that the client program and server program in its parameters must use/or. /, otherwise it will be considered as a parameter of the Client Program and the server program. For details, see man xinit) If ["$ whoseargs" = "client"]; then # If the current client parameter is being processed if [X "$ clientargs" = x]; then # If clientargs is empty, assign $1 to the client variable, that is, the [client] parameter client = "$1" elseclientargs = "$ clientargs $1 "# Otherwise, the clientargs value is $ clientargs $1, that is, the options parameter fielse in the # startx usage # method # Above # The parameters currently processing the server, the Code is the same as if [X "$ serverargs" = x]; thenserver = "$1" elseserverargs = "$ serverargs $1" Fifi ;;--) # If $1 is --, the server parameters are processed. -- The whoseargs = "server ";;*) if ["$ whoseargs" = "client"]; then # The clientargs = "$ clientargs $1" else # The parameter processed to the server program # display must be the first server argument # The screen number must be the first s The parameters of the erver program are in the form of X (X is a number). From the difference between startx and xinit, we can see that xinit has a [display], this [display] is filtered out. Try these two Commands: xinit/usr/bin/X11/xeyes-display localhost: 1 --/usr/bin/X11/X: 1-DPI 70 & xinit/usr/bin/X11/xeyes-display localhost: 1 --/usr/bin/X11/X-DPI 70: 1 & you can see the result of not using the screen number as the first server parameter if [X "$ serverargs" = x] & expr "$1 ":': [0-9] [0-9] * $ '>/dev/null 2> & 1; thendisplay = "$1" else # serverargs = "$ serverargs $1" Fifi ;; esac shift # Move all parameters left once done # process client argumentsif [X "$ client" = x]; Then # If the client program is empty # If no client arguments either, use RC file instead if [X "$ clientargs" = x]; then # And clientargs are empty, assign $ defaultclientargs to the client program client = "$ defaultclientargs" elseclient = $ defaultclient # use the default client program Fifi # process server arguments to process server parameters, same as if [X "$ server" = x]; then # If no server arguments or display either, use RC file instead if [X "$ serverargs" = x-a x "$ display" = x]; Thenserver = "$ defaultserverargs" elseserver = $ defaultserver Fifi #............ Omit authorization code several xinit $ client $ clientargs -- $ server $ display $ serverargs # submit the processed parameters to the xinit program for processing #............

From the code above, we can conclude that startx mainly sets the location of X client and X server, processes relevant parameters, and finally submits the parameters to xinit for processing. We can see that startx sets the position of X client to search for $ home/first /. xinitrc, then/etc/X11/xinit/xinitrc; set the location of X server to search for $ home/first /. xserverrc, And then/etc/X11/xinit/xserverrc. This explains why the. xinitrc and. xserverrc files in the user directory have a higher priority when X Window is started. So when we use the startx command to start X, if the user directory contains the. xinitrc and. xserverrc files, it is actually equivalent to the command xinit $ home/. xinitrc -- $ home/. xserverrc. If the user directory does not exist, the two files are equivalent to xinit/usr/x11r6/lib/X11/xinit/xinitrc --/usr/x11r6/lib/X11/xinit/xserver. And so on.
As for xinit, start X server based on the parameters passed by startx, and then start X client based on xinitrc.
The above is the Startup Process of X Window System. startx is only responsible for passing some parameters. The real X startup is implemented by xinit. In fact, it can be divided into start X Server and start X client. The. xinitrc (X client) and. xserverrc (X Server) files are constructed in the user directory. Write/usr/bin/X11/X: 1 in. xserverrc .. Write/usr/bin/X11/xeyes-display localhost: 1 in xinitrc. This is the simplest X Server + X client, but the screen number is changed from the default 0 to 1. Here X server is the/usr/bin/X11/X program, X client is the/usr/bin/X11/xeyes program.
To sum up the startx Startup Process for the ordering machine:
(1) startx sets the location of X client and X server, processes parameters, and CALLS xinit
(2) xinit starts X Server Based on the passed parameters, and then calls X client
(3) set related resources based on xinitrc, and start X client programs such as window manager, input method, and other applications.

But I have not figured out how gnome got up! Of course, gnome belongs to X client. See step (3) of the above startup process.
Here are two cases. The first is to use the xinitrc file of the system. View the/etc/X11/xinit/xinitrc file (My sarge files X-window-system-core and gnome-core), which only contains. /etc/X11/xsession in one sentence. Next, let's look at the script/etc/X11/xsession. Let's just look at the key part. The last part is:

Code:

Sessionfiles = $ (run_parts $ syssessiondir) If [-n "$ sessionfiles"]; then for sessionfile in $ sessionfiles; do. $ sessionfile donefiexit 0 [Code] And then check run_parts (), which is located in the middle of this file: [Code] run_parts () {# Until run-parts -- noexec is implemented if [-z "$1"]; then internal_errormsg "run_parts () called without an argument. "Fi if [! -D "$1"]; then internal_errormsg "run_parts () called, but/" $1/"does not exist or is"/"not a directory. "fi for F in $ (ls $1); do if expr" $ F ": '[[: alnum:] _-]/+ $ '>/dev/null 2> & 1; then if [-F "$1/$ F"]; then ECHO "$1/$ F" fi done}

Run_parts () obtains the file name in the $ syssessiondir directory and assigns it to $ sessionfiles, and then runs the files in the directory cyclically. Check the directory, that is,/etc/X11/xsession. d directory, You can see several files starting with a number. In fact, these values indicate the priority of these files to be run. A smaller number has a higher priority because the run_parts () is to use the LS command to display the files in this directory, so the front number is small when LS is displayed in front, so is

Code:

for SESSIONFILE in $SESSIONFILES; do . $SESSIONFILE done

This for loop is also executed first. The/etc/X11/xsession. d directory contains the 55gnome-session_gnomerc file, which mentions the startup variable. Then run:
Xdkui @ Debian:/etc/X11/xsession. d $ grep startup *
The 50xfree86-common_determine-startup file is displayed. There are

Code:

if [ -z "$STARTUP" ]; then if [ -x /usr/bin/x-session-manager ]; then STARTUP=x-session-manager elif [ -x /usr/bin/x-window-manager ]; then STARTUP=x-window-manager elif [ -x /usr/bin/x-terminal-emulator ]; then STARTUP=x-terminal-emulator fifi

That is, set the startup program. In fact, set the startup variable. If none of the above programs are found, an error will be reported and exited, that is, the X environment is not started. Run again
Xdkui @ Debian:/etc/X11/xsession. d $ grep startup *
See the 99xfree86-common_start file with the lowest priority, which has only one sentence:
Exec $ startup
Okay. Now we start our X client, and finally we are done. To sum up the START process of the first method, simply put, it is to sequentially search for/usr/bin/X-session-manager, X-window-manager, /usr/bin/X-terminal-emulator. If yes, start it, that is, X client. If none of them exist, the system reports an error and exits. View the/usr/bin/X-session-manager file and you can see that it is a symbolic connection. It is finally connected to/usr/bin/gnome-session, that is, gnome. As for the possibility that we will set the startup input method and other programs when starting gnome, it will be subject to gnome-session management and will no longer be analyzed. You can try to point/usr/bin/X-session-manager to the xfce4-session (if installed) and startx will start the xfce4 environment. Probably the RedHat switchdesk tool is to change the connection implementation ?. Or delete/usr/bin/X-session-manager, and then startx, only start the window manager pointed to by/usr/bin/X-window-manager, I am blackbox.

The second case is the xinitrc File $ home/. xinitrc in the user directory. Compare hiweed-debian-desktop_0.55_i386, there is a $ home/. xinitrc file with the exec xfce4-session in it. Therefore, its X client can be said that the most important X-session-manger is started from $ home/. xinitrc. It will not go through the execution process in the first case above.

I finally figured out the Startup Process of gnome (or X-session-manger). Let's talk about something else. The xinit program starts X Server and X client at the same time, which is also available on a single machine. If the two computers on the network are client and server, xinit will be powerless. In this case, you have to simply start X manually. The following is a simple "Manual" command to start X Server and X client: run the command in cui mode:
Xdkui @ Debian :~ $ X: 1 &
A gray full screen and a mouse pointer are displayed, Which is X Server, and the screen number is 1. The following code constructs the X client and press CTRL + ALT + F1 to return to the Cui (CTRL + ALT + F7 corresponds to the first X Server started on the machine, and CTRL + ALT + F8 corresponds to the second one, some people say that X Server with F7 corresponding to screen number 0 is actually incorrect. If the first screen number is 1 and the second screen number is 0, F7 corresponds to 1 screen, f8 corresponds to 0 screens), run the command: xdkui @ Debian :~ $ Xeyes-display localhost: 1 &
Press CTRL + ALT + F7 to see that our X client is xeyes. Return to Cui and run
Xdkui @ Debian :~ $ X &
Enable an X Server with screen number 0 and run it again under Cui
Xdkui @ Debian :~ $ Xterm &
At this time, CTRL + ALT + F7 corresponds to screen number 1; F8 corresponds to screen number 0, and its X client is xterm. First, exit the two above X servers. In the following complex example, start our gnome manually. First
Xdkui @ Debian :~ $ X &
Then
Xdkui @ Debian :~ $ Gnome-session
As you can see, X started with startx is the same. At this time, X server is the program X, and X client is the gnome-session and its window manager. It seems that xinit is not very useful (?? ), A simple script can be implemented. I originally wanted to disassemble xinit for analysis, but I was too lazy to do it. ^_^ this is the local location. For the situation that X Server and X client are located on different hosts, see the third part of this article.
I personally think it is very important to understand the relationship between X Server and X client for X Window System. Generally, the X server is very simple, that is, the/usr/bin/X11/X program. The X client has a wide variety of tricks, from the advanced CDE, gnome, Kde, to the low-level ones, only TWM, window maker, blackbox and other Window managers, and then to the most simple only xterm, rxvt, xeyes and other single X programs. It is precisely because of the various combinations of X client that our X Window System looks diversified. This may also be one of the biggest selling points of X Window System. ^_^

3) run X Window System across networks
Generally, the X server is not installed in Linux, FreeBSD, Solaris, and so on, and many do not even have a monitor. In this way, you can install a simple X client in these systems and remotely display it in the X server that the administrators are sitting on. Our lab uses FreeBSD as the gateway to provide WWW and FTP services. Generally, an X server is started on the Administrator's local machine, and then the gateway runs the X client program on the local display through SSH or telnet, of course, XDMCP (X Display Manager Control Protocol) is also available ), as mentioned in man xsession,/etc/X11/xsession is generally called by startx (my/etc/X11/xinit/xinitrc calls the xsession script) or Display Manager, however, some Display Manager only calls xsession instead of xinitrc. Therefore, the GUI can be started normally in either startx or Display Manager mode. It is best to put the program started by X client in the xsession file. To remotely run the X client program, you must set the display environment variable to the Host Name: screen number (for example, 192.168.1.2: 0 indicates that X server is the screen 0 on the host 192.168.1.2 ); or add the-display parameter to the X client program. Due to the restrictions, only the TCP/IP network environment is tested. X server is 192.168.1.2, and X client is 192.168.1.1.
1) Windows X Server
A) Use SSH or telnet
There are many types of X server software under windows, I use X-win32 here. Running the X-win32 program in Windows is equivalent to an X server on the local machine. Remotely log on to Debian (I use VMware to simulate the network environment and directly enter the virtual machine to execute _ ^) and run:
Xdkui @ xclient :~ $ Export display = 192.168.1.2: 0
Xdkui @ xclient :~ $ Xterm &
In this case, we can see xterm in X server in windows. As for the program that X client runs, we can see what you need, File Manager, resource viewer, and so on. Of course, here the X-win32 needs to set up the authorization, as if the default is to prohibit access control, that is, any X client can use this X server.
B) XDMCP Mode
Common display managers include xdm, TPD, and KDM. Here, we use the gastribucket. You need to modify the configuration file/etc/X11/TPD. conf of the target instance and modify enable = true in the [XDMCP] segment so that you can remotely log on to the instance and run the target instance in the X client.
Create an xdmcp session in the X-win32, query the method, and fill in the IP address as the address of the machine that is running the gmt1. Connection, you can see the login interface, the following needless to say, enjoy it
2) Linux and Linux Interconnection
A) SSH or telnet
Start an X Server locally in Linux. Pay attention to the authorization issue. Create a file/etc/x0.hosts and enter ip192.168.1.1 of X client. x0.hosts indicates the X client address that is allowed to be connected to the local 0th screens, the x1.hosts file is the X client address that is allowed to be connected to the local 1st screens, and so on, which is contained in man xserver. Run
Xdkui @ xserver :~ $ X &
Do not add the-nolisten parameter when running the program. Otherwise, the program will not listen on the network.
In this case, CTRL + ALT + F7 is X Server, and CTRL + ALT + F1 is returned. You can also SSH to X client.
Then log on to the X client and run
Xdkui @ xclient :~ $ Xterm-display 192.168.1.2: 0
You can see xterm in the local X server. If so, you can also display gnome-session locally. You can also perform this test in VMware in Linux. You need to use your wrist. For more information, see.
B) XDMCP Mode
Run the Command run ). You can see the logon interface.
I did a test in VMware in Linux. Let's talk about the wrist. Run startx & start GUI normally under the Cui of CTRL + ALT + F1. Then CTRL + ALT + F7 is the gnome started by X Server and X client, then run VMware here to open the Debian Virtual Machine and run the target machine. Return to CTRL + ALT + F1 and run X: 1-query 192.168.1.1. You can see the logon interface. At this time, CTRL + ALT + F7 is my 0 screen, and the virtual machine is running in it. CTRL + ALT + F8 is the first screen, and you can log on to X client in the remote GUI. This is equivalent to two local X servers.

X Window System is designed in amazing ways, and its usage is even more dazzling. Admire .........

PS: This article is based on the "X Window thorough research" published by People's post and telecommunications. A small part of it is the original saying. If you are interested, you can check it, but there are only 2 ~ Chapter 3 is worth reading. It can be finished in less than an hour, but it helps to understand X Window System. With so many words, I hope to help anyone who wants to know more. Otherwise, I will be able to work hard. My younger brother's level is limited. please correct me if there is any error. ^_^