Routing of input events to windows has turned out to also be extremely important for a display subsystem in practice. It wasn’t just X11 that did this, it was a

Routing of input events to windows has turned out to also be extremely important for a display subsystem in practice. It wasn’t just X11 that did this, it was also the NeXT window server, and Sun’s NeWS, and SGI’s pre-X window system, and the original VAXstation window system on VMS, as well as how both modern macOS and modern iOS and iOS-derived platforms work. In any of these cases there may be one or more daemons behind the scenes handling the “raw” input—possibly even in cooperation with kernel-level pre-processing code, to ensure low latencey—but most event delivery to applications is associated with windows, with options to get lower-level access if needed. One of the things that helps many of the systems described above with latency is kernel participation, whether by pushing much of the preprocessing of events down to the drivers so there’s little for userspace to do, or by implementing kernel-level zero-copy IPC (e.g. use of Mach messages by NeXT and Apple). If human interface IPC happens entirely in userspace and requires multiple context switches to get an event from device to a display change, you’ll wind up with hitches and delays unless there’s some sort of scheduler hinting that ensures each stage in the pipeline runs immediately after the last. This is, of course, why there was a lot of desire by Wayland advocates for kernel dbus support, but they went at the problem backwards: “Let’s take DBus, and make it fast by putting it in-kernel,” *without* first trying to make it as fast as possible without kernel support, *and* without trying to figure out the minimal feature set for kernel-level IPC that would be needed to support it (which may not look like DBus).