> Have you wondered why the X.Org server still fails at doing simple things like inferring the DPI At least on my monitor X seems to have a good idea for the d

> Have you wondered why the X.Org server still fails at doing simple things like inferring the DPI At least on my monitor X seems to have a good idea for the display size: dimensions: 1920x1080 pixels (508x285 millimeters) This should be all information any software needs to calculate DPI. "Dpi" is configured to 96 for backwards compatibility, but if any program actually needs that information it can query it. > and supporting retina displays without extra configuration? "Retina displays" is just a marketing term for displays that have high pixel density and supporting those is really a thing for the applications (they need to be able to handle scaling so that they appear at the same size as in a normal or low pixel density display). Unless the display server works with device independent units and doesn't deal with any pixel content whatsoever, you always need application support for that. > Or why you need external window compositors? (assume you mean desktop compositors like Compiz, etc) Because it is an optional feature introduced much later than X's inception, cannot work on every single hardware that can run X and after all since X has a mantra of providing mechanism instead of policy, it only provided enough functionality to implement compositors without forcing them or dictated a single way of what sort of functionality they'd provide (which at the time ended up with a multitude of different compositors with various effects and other functionality). It is also an optional feature which in my eyes is a great thing as i don't like the input lag they add even to simple desktop interactions like moving windows around (even with Wayland where the entire thing is designed with desktop composition in mind).