2

When people discuss the X window system, they mostly focus on the display side, i.e. how it is a networked system that handles and coordinates the graphical output of different applications in the form of windows. Recently, I've had to configure my keyboard layout using XKB (X keyboard extension) and I've learnt that the X window system is also responsible for handling input from the keyboard (and perhaps the mouse too). In my mind, I can imagine the window display and the keyboard/mouse input as being quite orthogonal from each other. But I imagine I must be wrong.

From a design or historical perspective, why does the X window system handle both graphical output and also user input from the keyboard/mouse?

Improve this question
5
  • 1
    TL;DL Because the X Windows Manager is the only part of the system that knows which windows are iconified, hidden, on top, have focus (for keyboard input), and where they are (for mouse clicks and drags). All needed to direct events at the owning processes.
    – Paul_Pedant
    Mar 14, 2021 at 12:00
  • 1
    I don't understand why this is a bad question. When you work without an X server on the tty, you are also able to use the keyboard. So making the keyboard configurable through the X window system, i.e. through XKB, rather than through a lower-level mechanism, seem to me more like a design option than anything else. Hence my question.
    – mgarort
    Mar 14, 2021 at 12:37
  • The keyboard works with whatever "owns" it as a device, starting with the bootstrap, then with single-user mode. When you get into a windowing system, the keyboard needs to be mediated to pair with the process owning the currently active window. Hence, the WM needs to own the input devices.
    – Paul_Pedant
    Mar 14, 2021 at 12:52
  • 1
    It isn’t a bad question. It is a perfectly valid one. Especially from a Unix design philosophies standpoint, where integrating parts that don’t need integrating is a big design anti-pattern that came from the commercial (Microsoft/Apple) world. … OpenGL doesn’t have an input part either. But DirectX does. … The integration of input into it was bad design in any case.
    – Evi1M4chine
    Aug 2 at 13:35
  • @Paul_Pedant: And that has nothing to do with input. That’s the controller and the model for the windowing component. The controller (in MVC parlance) can just as well be controlled from a script for automation, or usually a separate program that handles input (say an input daemon / server in microkernel parlance).
    – Evi1M4chine
    Aug 2 at 13:38

1 Answer 1

Reset to default
2

What use do you have from an application, with which you cannot interact via keyboard/mouse?

XWindows environment is often call XServer. That means that when you run an application, the application is a client requesting display (and keyboard/mouse) services from an XServer. Usually, the XServer is located on the same computer, where the application runs, but this is not a requirement. You can easily execute an application on one computer requesting display services via network from another computer running XServer. In that case, it is mandatory that XServer handles keyboard and mouse, because application is displayed on XServer while the application with program logic runs on the client computer. It would not be OK, if XServer provided only display, while keyboard/mouse would be handled elswehere. So XServer providing display always means implicitly, that it also provides input (keyboard, mouse,...).

Improve this answer
1
  • There are countless reasons to use programs with no keyboard/mouse input. Kiosks, displays, TVs, status windows (like say a clock), render output windows, etc. One does not need to justify one’s reasons.
    – Evi1M4chine
    Aug 2 at 13:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .