Question about the future of Xorg

[Dave Henderson]

On 6/9/25 10:52, Carsten Haitzler wrote:
> On Mon, 9 Jun 2025 08:48:10 -0500 Vasily <vasil_tik at yahoo.com> said:
> My personal opinion is that there are some issues need to be solved before
> wayland compositor can substitute X11. So I think X11 will work for us
> another 5 -10 years.
> oh absolutely. wl needs maturing - a lot. there is much work to do. there also
> is no reason you couldn't also take xorg and "strip it down and divide it up".
> you could solve a lot of security and boundary issues by e.g. disabling any
> xrandr "write" access (modification) to any client by the wm. first client in
> wins (wm) and it's in charge. this stops any random client form messing with
> screen layout. we could start limiting access to xinput and xinput devices,
> limit what events you can listen to on windows that are not your own (unless
> you are the wm), and so on - it'd break some functionality in x - but it'd
> start solving problems. you could tackle it from this angle or from "build
> wayland" angles. either way it'll result in something breaking and some
> transition mess etc. etc.
>
> now my issues with wayland are indeed that it has yet to fully mature. there
> have been some not so great decisions that are seemingly heading in the right
> direction now. there are other things that are core issues. IMHO wlroots is a
> stab at some of that but IMHO there should have been much more done earlier on
> here and in ways that are more render-agnostic.
>

I agree with the "strip it down and divide it up".  X11 does already 
have some of the "divide it up" using extensions, but this should be 
applied to the guts.  I've seen numerous people say over the years that 
X11 still has a lot of legacy aspects to it and I always wondered why 
all that didn't get pulled from the code base (or again moved into an 
extension if still "desired").  I understand that some obscure app may 
no longer work, but that would be a fraction of a percent of users.  The 
benefit to the community would be greater than the encountered headache 
for that small subset of users (which could just continue using the last 
working version of X11 with their app(s)).

In addition to the stripping of outdated/unnecessary code, it would 
reduce the size of the X system and reduce malicious attack vectors to 
gain access to a device.  Honestly, I'd try to either make X work 
without running as root, or make the "core" part of X as small as 
possible to address this issue.  As a by-product of stripping out this 
code, it should speed up the system, even if marginally...


This is just a list of things provided so far in this thread that could 
be reworked, removed, or moved to an extension:

   (Lyude Paul <lyude at redhat.com>)

- heavy round trips in its protocol

- the fact that most modern compositing on X is just extension on 
extension on top of the actual X11 server which no longer does half of 
the things it's supposed to handle

- ability to draw its own widgets

- has font rendering

- has a  HAL for video drivers and input drivers

   (Carsten Haitzler <raster at rasterman.com>)

- isolate all the core 2d rendering in xorg into a "legacy" module to 
keep it "out of sight"

- most of the rest of x's problems are the protocol and what is assumed 
to be allowed by clients or not (like being able to send fake input to 
any app or read input events on any window anywhere - even not your own 
etc.)

- rendering model can evolve too with a wayland-like explicit buffer 
"send" model to the compositor in x

- some issues like latency will always be an issue as long as you have 
to bounce messages through many processes

- you could solve a lot of security and boundary issues by e.g. 
disabling any xrandr "write" access (modification) to any client by the wm

- limiting access to xinput and xinput devices

- limit what events you can listen to on windows that are not your own 
(unless you are the wm)