X window system
- Details
- Last Updated: Saturday, 10 October 2020 00:35
- Published: Wednesday, 06 November 2019 02:50
- Hits: 3726
X window system (X11 or X, but not X windows) is a windowing system for bitmap displays. X provides basic framework for a GUI env: drawing and moving windows on the display device and interacting with mouse and keyboard. It originated at MIT in 1984. XFree86 is the implementation of X that was used on all Linux computers until mid 2000. However due to change in it's license terms, a fork was created and development moved on to X.org. The first version, X11R6.7.0, was forked from XFree86 version 4.4 RC2. X.org foundation leads this project as of today, and almost all Linux OS have moved on to X.org. It's available as open source under MIT license.
Official website: https://www.x.org/wiki/
Older defunct website for xfree86 (not supported anymore, so do not use this website): http://www.xfree86.org/
good intro here: http://linuxdocs.org/HOWTOs/XWindow-Overview-HOWTO/index.html
other detailed link here: http://www.linux-tutorial.info/modules.php?name=MContent&pageid=98
X uses client/server model. Usually, the local computer runs X server program. X server interactes with hardware, it takes i/p from mouse/keyboard and displays on the monitor. Programs such as Xterm, browser, etc are called X clients. X server communicates with various client programs. The server accepts requests for graphical output (windows) and sends back user input (from keyboard, mouse, or touchscreen). X clients don't interact with hardware directly. This way X clients need not worry about h/w, they just follow the protocol to interact with X server, and the X server handles the actual process of interacting with h/w.
X provides the library, Xlib, which handles all low-level client-server communication tasks. The client has to invoke functions contained within Xlib to get work done.
Windows manager (WM):
A window manager is a "meta-client", whose most basic mission is to manage other clients. The WM program decides where to place windows, gives mechanisms for users to control the windows' appearance, position and size, and usually provides "decorations" like window titles, frames and buttons, that give us control over the windows themselves. X window system provides policy but not implementation of that policy. This is handled by window managers. The most basic WM is twm, ad other more fancy ones are fluxbox, Xfce4, etc. These WM have toolkits or widget library. Using Xlib functions directly is pretty tedious, so libraries were developed thru which we could control widgets like menus, buttons, scroll bars, canvas, etc, much more easily. One of the earliest toolkits developed was Motif. However, Motif wasn't free, so alternatives were developed. One such very popular alternative was Gtk (aka GNU tool kit, or GIMP tool kit). Another very popular toolkit used in KDE was Qt.
Desktop Environment (DE):
Since there are hundreds of different toolkits and they all have different looks and behaviour, applications developed using different toolkits will look dihttps://www.computerhope.com/unix/startx.htmff even when lauched on same computer. Even the way of launching pgms vary from one wm to another(i.e on some we may have to type cmd, while some may have gui to launch, etc). DE provides a set of facilities and guidelines aiming to standardizing all this stuff. Under Linux, 2 most popular DE are KDE and GNOME. KDE has kwm as it's WM (which is mandated by KDE), but GNOME allows any WM (although it's preferred WM is sawfish). GNOME uses the Gtk toolkit, and provides a set of higher-level functions and facilities through the gnome-libs set of libraries. The whole idea of a desktop environment is consistency, so all apps developed for one DE, would look and feel the same (i.e scrolling, left/right clicks, etc). However, we are completely free to run apps developed for KDE on GNOME or vice versa, they would just look different compared to other apps.
GUI startup:
Assuming we have GNOME DE, this is what happens on powerup. As explained in Linux installation, after powerup and succesful login, xinit is called for GUI desktops. Even the login i/f may be GUI (instead of text login i/f as found in older versions of Linux) which is managed by Display manager (dm). Here, dm starts the X server. When a Linux system starts X, the X server comes up and initializes the graphic device, waiting for requests from clients. First a program called gnome-session starts, and sets up the working session. A session includes things such as applications I always open, their on-screen positions, and such. Next, the panel gets started. The panel appears at the bottom (usually) and it's sort of a dashboard for the windowing environment. It will let us launch programs, see which ones are running, and otherwise control the working environment. Next, the window manager comes up. Since we're using GNOME, it could be any of several different window managers, but in this case we'll assume we're running Sawfish. Finally, the file manager comes up (gmc or Nautilus). The file manager handles presentation of the desktop icons (the ones that appear directly on the desktop). At this point my GNOME environment is ready to work.
Files:
X server executable is at /usr/bin/X. This is the original X server executable from MIT, but due to license issues, Xorg was forked from X, and it's executable is at /usr/bin/Xorg. Xorg is what is run as X Window system server executable, X is just for compatibility, and it eventually passes cmds to Xorg. (on my centOS system, X is just a softlink to Xorg). However, we never call Xorg executable directly to start X window system server, instead we call a script "startx".
startx => On a text only terminal, X server doesn't start automatically. The wrapper script "startx" can be typed on the text terminal to start X server. The startx script is a front end to xinit that provides a somewhat nicer user interface for running a single session of the X Window System. More details here: https://www.computerhope.com/unix/startx.htm
DISPLAY environment variable:
X server and X client need not be running on same computer. They can be on two computers. X client interacts with X server using TCP protocol via Port 6000 or higher, when they are on diff m/c. An env variable "DISPLAY" is used by X client to to find out where the X display server is (so that the client can interact with he user) and which screen it should use by default (on displays with multiple monitors). X client just sends it's display data to X server, and then X server displays it based on what display is connected to it, and what display the X client has asked it to use.
X server manages the display. A display consists (simplified) of:
- a keyboard,
- a mouse
- and a screen.
DISPLAY environment var indicates to graphical clients which display server (I/O devices) to connect to. It can be set to aanything desired by user.
The display var is of the form
where:
hostname is the name of the computer where the X display server runs. An omitted hostname means the localhost. So, if we provide a name/addr here, that means X server is located at this IP addr.
D is a Display number (usually 0). It can be varied if there are multiple displays connected to one computer. TCP port used for Display 0 is 6000, Display 1 is 6001 and so on. The phrase "display" is usually used to refer to collection of monitors that share a common keyboard and pointer. Most workstations tend to only have one keyboard, and therefore, only one display with display number 0. Display number is required. When we connect via vnc to a remote m/c, it allows us to open connections to separate multiple displays as mc1.abc.com:0, mc1.abc.com:1, and so on. So, if 5 users are going to connect to a m/c via vnc, vnc can open connections to same m/c with 5 different displays, so that all 5 users can have their own display, even though all their pgms are running on same m/c on same cpu. These are virtual displays and Linux gui is displayed on each of these virtual displays independently.
S is the screen number. A display can actually have multiple screens. The phrase "screen" refers to physical monitors that share the same keyboard and mouse. So, on a system with 2 monitors, screen can take 2 values 0 or 1. Usually there's only one screen though where 0 is the default.
ex: echo $DISPLAY => returns :0 on my m/c by default. This means display is set to localhost, display 0, and screen 0 (since screen is omitted, it defaults to 0). Any X client, before connecting to X server, reads this var, and figures out where X display server is, that it's supposed to connect to. Here, it says it is connecting to X server on local computer. It connects to X server on local m/c, and asks it to display the data it's sending to display number 0.
We can set DISPLAY var to any value we want, and in that shell, X clients launched will talk to X server indicated by the var.
In BASH shell, we set any env var using export:
ex: export DISPLAY=abc.com:0.0 => This makes any X client connect to X server on abc.com. This communication b/w X client and X server will be made over TCP on port 6000. Running a X client as "firefox" will connect to X server on computer named abc.com. Display and Screen used are 0. So, firefox window will end up showing on display connected to X server on abc.com. However, most of the times, computer abc.com won't allow just any computer to connect to it's X display server. So, we'll get an error as "Error: cannot open display: abc.com:0.0".
In Csh, we set any env var using setenv:
ex: setenv DISPLAY abc.com:0.0
Many Xclients allow them to specify Xserver to connect to via cmdline.
ex: xterm -display :0 => this opens new xterm window on local X server, display 0. Basically, xterm opens locally on same display as where you ran this cmd.
ex: xterm -display :1 => This will error out: "Can't open display: :1". This is because there is no display 1
Virtual display:
The question that comes to mind is how do we get multiple displays on a given computer. These multiple displays are called "virtual display".. Any Linux OS has 6 virtual display from 0 to 5. It's explained below under tty section,
TTY:
If we set multi-user.target (look in systemctl section for more details) as default target, then system will start in CLI. (cmd line i/f) Any Linux system starts multiple TTY sessions at boot up. Each TTY session can be thought of a copy of OS running. Most Linux OS install 7 TTY session by default. CentOS has 6 tty, while Linux Mint has 7. TTY stands for Tele Type, an old piece of equipment which allowed typing, which would appear on typed paper and then on pressing <ENTER>that was sent to computer and then the response would be typed back on the same piece of paper. On modern computers, cmd environment (whether CLI or GUI,) is called a TTY or specifically a PTTY (Pseudo TTY). A TTY session is the environment you are in while interacting with your computer. We use mouse, keyboard to enter inputs, but we can use virtual terminals (i.e "xterm" etc) to enter inputs (which eventually get their inputs from mouse/keyboard) and send it to processes that need it. That psuedo terminal that sends cmds to processes constitutes a TTY session.
So, these 7 (or 6 for some distro) different TTY session can be used to log into by 7 different users at same time. They are useful during debug too. These 7 TTY sessions are rep by device special files /dev/tty1 thru /dev/tty7. Of these 7 sessions (or 6 in CentOS), all but one start in CLI mode. In Linux Mint, the 7th session is the default session that is presented to the user as login screen. It can be CLI or GUI depending on whether we are in multi-user target or graphical target. These 7 TTY sessions can be entered by pressing Ctrl + Alt + F1 (for 1st tty) to Ctrl + Alt + F7 (for 7th tty). In CentOS, the first tty session (tty1) is the default session, and it has only 6 tty sessions from tty1 thru tty6. On any Linux distro, one of these many tty will be the default terminal (GUI or CLI), while remaining ones will be CLI terminal. Ctrl + Alt +F1 takes to tty1 session, while Ctrl + Alt + F7 takes to tty7 session. Which of these is default depends on OS distro.
We login to default CLI/GUI TTY session. However, we can login to other CLI TTY sessions too. We just have to press "Ctrl+Alt+F2" to login to 2nd tty session from the current session. Similarly for other sessions. In these 5 or 6 CLI TTY sessions, we login by providing username and passowrd. Then we can use it the same way as would use any shell terminal from within GUI (the same way as we use xterm within GUI). We can logout by typing "exit". From these 5 or 6 CLI terminals, we can enter into GUI windows by typing "startx". We can get out of GUI mode by logging out from GUI mode. That will bring us back to Command line.
tty => this cmd prints the current terminal session. i.e /dev/tty4 etc for 4th CLI terminal (most likely the one on Ctrl + Alt +F4). For GUI sessions, it shows /dev/pts/1, /dev/pts2, etc for multiple terminals opened within GUI. pts means psuedo terminal. Whatever CLI this gui session started from shows the dev/tty number when typed on cmd line before GUI gets invoked.
Unix supports 'device files', which aren't really files at all, but file-like access points to hardware devices. A 'character' device is one which is interfaced byte-by-byte (as opposed to buffered IO). /dev/tty is a character device file, it doesn't contain anything but can be read from and written to.