0

Recently I faced for the first time the "X Window Server" concept. After reading a lot about it and struggling to understand most of its core concepts - mostly because I was born in the "modern computing era", having never touched a "real terminal" or "PCs not powerful enough to run an X Client" - I got confused about something:

Why is X Server a server rather than a library with a set of predefined functions?

I could learn a lot from some questions previously asked here, especially these ones:

I understood that X Server was initially designed to also support communication through networks, as some old computers weren't powerful enough to run graphical elements. Is this the only reason X Server was designed to act as a server? To receive "requests" through a network and respond with "graphical elements"?

Is there any other reason X Server acts as a server even locally? Probably I'm missing some detail and that's exactly what I'm trying to understand to "connect" everything I learned so far.

If possible, could you guys also give me a real example of how terminals used to communicate to X Window Servers in the past? All I can imagine is a building full of terminal computers (running nothing other than a black terminal screen) and with only a single computer capable of running graphical interfaces. Did people use to share this computer to communicate with the terminal ones to perform heavy tasks?

Thank you!

  • Terminals did not "communicate to X Window Servers", they *were* X Servers. The applications in the big computer in the basement were the *X clients* - and yes, to run an X application you don't need a local X Server, only the X libraries and the address of a (possibly remote) X Server where the actual display will be sent to. – telcoM Apr 09 '20 at 14:07
  • So the X Servers are the computers that actually display a graphic element (e.g. a colored rectangle), and the X Clients are the ones that receive an input (e.g. a keyboard key press or mouse press)? – Stanley Sathler Apr 09 '20 at 15:07
  • Yes, the X Server is the processor with the local display, keyboard and mouse. An X client receives user input through the X Server, does something useful, and sends text, bitmap images and/or drawing commands to the X Server's display. – telcoM Apr 09 '20 at 15:18
  • In a network scenario, I can imagine a personal and cheap computer connected to a powerful one through a TCP connection. No modern applications or "application-level" protocol - no HTTP, no "Image Viewer" programs. Not even a desktop environment. The personal computer receives a user command and sends it to the powerful one. The powerful computer computes that heavy task and returns a "drawing command" (e.g. _"draw a white rectangle"_) to the personal computer. The personal computer, through the X Server, draws that rectangle. Is this right? – Stanley Sathler Apr 09 '20 at 15:29
  • That's exactly it. – telcoM Apr 09 '20 at 15:31
  • In a non-network, local, scenario (e.g. in a Linux running in my personal computer), I suppose the X Server is a single process running. What would be X Clients? When I click on a folder, the kernel receives the mouse click "event". What does it do? Does it send to the Desktop Environment, who calculates where the mouse is (and thus, where it clicked onto) to know if it must launch a new window, and then ask the X Server to draw a "rectangle with a few other things" (the window)? – Stanley Sathler Apr 09 '20 at 15:34
  • The mouse click event goes from the kernel to the X Server. It checks which window is under the mouse pointer, and passes the click event to the application that drew that window only. It will also provide the coordinates of the click event relative to the origin point of that particular window, so the application will not need to care where on the display the window is, and if it's covered by other windows or not. The Desktop Environment is one of those X Client applications. And yes, the rest of your description is correct. – telcoM Apr 09 '20 at 15:50
  • You have it completely backwards -- the terminals are/were the X _servers_ (because they "serve" the display), and it was the X11 _clients_ which were running on headless servers and other heavy rusting gear. The paradigm did NOT change at all, the protocol(s) changed in the "modern era" (and NOT for the better): a web browser running google maps or similar acts as a "display server" for google's or somebody else's "application". –  Apr 09 '20 at 21:14
  • That would be awesome if those who down-voted the question could clarify WHY they did it, so we can all learn. :) – Stanley Sathler Jun 07 '20 at 11:07

2 Answers2

1

You seem to have a big misunderstanding with regard to terminals.

There were text terminals, and there were X11 terminals. The X11 terminals ran an X-server. This was also called a thin client.

You may also have a work station, running an X-server. It would connect to a process server. A powerful machine in the basement.

Other advantages are:

  • It is just a process (with access to the graphics hardware, keyboard, and pointing device), but just a process. This has advantages. You can have one with no access to graphics hardware, keyboard, and pointing device. It could also be a VNC server, making an X11-vnc bridge. It could be used for testing (have a robot process control it, in place of a human).
  • It is a separate process: I upgraded my computer to multi-code. It uses these cores, with no changes needed in the software (up to a few cores).
  • If you have multiple monitors, keyboards, and mice, then architecturally it is easy to make them into separate seats (terminals).
  • It makes implementing switch-user, easy.
  • Not giving other processes, access to hardware. As you would with the library approach, is more secure (Note X11 does have some security problems, that could be resolved with a re-design).
  • The window-manager is also a separate process. This allows the choice of Desktop Environments. So a process for X11-server, one for the window-manager, one for the display-manager (login service), one for this and that. It makes it flexible, you can change your desktop environment without even logging out.
ctrl-alt-delor
  • 27,473
  • 9
  • 58
  • 102
  • So having X Server as a separated server (and thus an isolated process) was a design decision in order to provide a _"single source-of-truth"_ (a bridge that can act as an intermediate between many different processes), _security_ (acting as an "API" to avoid several different processes talking directly to the hardware) and _flexibility / modularity_ (by not forcing many clients to have to react to any hardware update)? – Stanley Sathler Apr 09 '20 at 15:15
  • Possibly not "intermediary" because the client processes don't participate in the discussion beyond stating their demands. For example, if some process' window gets focus, no other window gets input for its process, and (for older hardware) the window colour mapping gets hijacked. More like "arbitrator". – Paul_Pedant Apr 09 '20 at 15:38
  • Thank you! So is it why we have Desktop Environments? I mean, each process can require something to the X Server and, as X Server is an innocent and good-heart man, it receives every request without never denying it. If many different processes are requesting the X Server at the same time, it becomes a race where the latest process to request X Server always gains control. Is this right? – Stanley Sathler Apr 09 '20 at 15:50
  • We have Desktop Environments (independent), because The X11 people decided that the window manager would also be separate. So a process for X11-server, one for the window-manager, one for the display-manager (login service), one for this and that. It makes it flexible, you can change your desktop without even logging out. – ctrl-alt-delor Apr 09 '20 at 18:40
  • 1
    No there is no race, each client talks over a separate stream. Operations are relative to a window (and usually not the root window). – ctrl-alt-delor Apr 09 '20 at 18:42
  • 1
    Generally, the user retains control of which process she interacts with. This can be by clicking for focus in a particular window, or a keystroke combination that is reserved for the windowing system (like cycling through the available windows). Processes are free to continue processing, including drawing on canvases that are partly covered by active windows etc. Long time since I wrote an X client, but I seem to remember your process can elect to be told to redraw patches that have been revealed by window actions, or can have a window image cached that is redraw in full. – Paul_Pedant Apr 09 '20 at 20:37
0

It is a server because it provides and coordinates a display service on a single piece of hardware (conceptually a work station) that may have multiple keyboards, other input devices, and multiple displays.

Multiple processes can connect to it, either locally or remotely, and negotiate for screen space, input focus, colour map slots, and other resources. The processes cannot negotiate with each other directly, or reconcile their disparate demands. The X windows server provides the service that makes all the client processes believe that they have access to all the functionality of the workstation.

ctrl-alt-delor
  • 27,473
  • 9
  • 58
  • 102
Paul_Pedant
  • 8,228
  • 2
  • 18
  • 26