There's absolutely no reason to write an X server from scratch to add native compositing support.
You're also massively overstating the complexity of an X server. Writing X servers that are advanced enough to be usable is something a lot of individuals have done. It's nothing like matching a modern browser. Incidentally, if I were to try to do this today, I'd gut a proxy like Xephyr and make it rootless to support older clients, and make the main server itself only support the subset of the X protocol modern clients speak.
> You're also massively overstating the complexity of an X server. Writing X servers that are advanced enough to be usable is something a lot of individuals have done.
If so, why are we observing apparent shortage of developers to maintain the actual Xorg? I can't believe there are no people interested in maintaining it in the whole world. I thought it's so complex it just requires much more expertise and dedication than anybody is ready to invest.
Because Xorg is a huge beast with plenty of legacy, and it's also not a very fun project to hack on because it's largely maintenance of stuff people only care about when it breaks.
E.g. support for a bunch of backends of which most are not worth supporting if you want to implement a server from scratch, but which Xorg has been saddled with, as well as support for a bunch of legacy X functionality that nobody would bother implementing if implementing a server from scratch because most clients never use it.
E.g. a major source of complexity is supporting various X visuals that are irrelevant today when you can decide to only support truecolor natively. Another is support for a bunch of drawing primitives that you might as well just ditch all but the very simplest of, and support for legacy clients via a proxy like Xephyr. That said, most of those drawing primitives are also supported by any 2d canvas style library like Cairo or Skia that does client side 2d rendering, so if you want to implement them for an X server, just picking up one of those libraries would be time far better spent than implementing it yourself.
It'd certainly be a lot of work, and a lot more work to write an X server from scratch that is a complete replacement for e.g. Xorg - you'd need to support a number of X protocol extensions, but most clients backends will fall back on core functionality if extensions are not available (you'd definitely want to support some of them, like Xrender and SHM though, or your server would be largely unusable with modern clients).
At the same time, if someone wants to write a new X server, it'd be silly to do the work of writing their own backends when the could just grab wlroots and build an X server on top of that. "Modern X11" can be reduced to a relatively narrow superset of Wayland functionality if you defer most of the weirder legacy functionality that is rarely but very occasionally used to a proxy like XWayland, Xephyr or XPRA (all of which do, that said, rely on Xorg code) and make people use those for clients that need it.
Honestly, I think this is the most likely/viable future for X on Linux. It'd drastically reduce the amount of code to maintain and share that burden with other projects, and would make it far more viable to keep maintaining X support for those of us who wants (part of) it.
I really don't understand this line of thinking or what you are trying to accomplish. If you are dropping things from the X protocol to the point where it's only XInput2.2, SHM and DRI3, and then farming the rest out to Xephyr, then it's no longer X anymore. That is pretty much entirely what Wayland already is. So you might as well just build it as a Wayland server and call it a day.
I'm not doing this, it's a thought experiment. I'm happy to stay with X for a long time if necessary.
But what you list is not enough, though. There are enough extra bits that goes well beyond what Wayland provides today, like ability to write a standalone wm without having to build a whole compositor, for example, that you'd end up with something quite substantially unlike Wayland if you went down that route and looked at which pieces of X11+extensions people are actually using. It'd be far less than full on legacy X11, but far more than just Wayland.
It doesn't matter if it's not X. Nobody but extreme purists would care if it's not exactly X. What will matter is if you lose capabilities.
E.g currently my preferred wm (bspwm) doesn't have a Wayland alternative, so a Wayland compositor isn't a viable option for me without changing my workflow. Sway might be nice, but it's different and I have no compelling reason to put in the effort to make a switch until running Xorg starts becoming problematic. One day, maybe I'll feel compelled to switch but it won't be soon.
Even so, Xorg will hang around for decades in the form of XWayland because of old X apps people still use (e.g. none of the terminals I have installed on my system except for gnome-terminal supports Wayland).
I still see no purpose to do that, with a lot of hacking it would be also possible to make XWayland work with window managers. But that also would be pretty pointless to do because those other parts of the X protocol are also bad and need to be replaced, you might as well just rewrite the window manager.
If I wanted to spend time redoing my configuration, maybe, but I have better things to spend my time on. So in however many years it takes before getting Xorg running starts taking more effort than switching. I'm not expecting that to happen anytime soon.
> It doesn't really work fine though, there are numerous really old bugs that never got fixed. Here's a sample:
It works fine for me. I gave my reason for why I won't consider switching to some Wayland compositor. None of the bugs you list affect me, so your suggestion I look at a Wayland compositor which would require me to spend time changing my entire config only to be left running XWayland anyway because the terminals I use are X11 based.
It would be a massive waste of my time for no benefit whatsoever.
And this is why X will stay around for a long time: There are lots of us with dependencies like this and no reasons to change things until things starts breaking.
> I don't understand, you were just talking about spending significantly more time rewriting the X server...
Read again. I have not once suggested I'm planning on rewriting an X server. I pointed out doing so would have been a better choice than starting over from scratch, and that the choice to start over from scratch is the reason people are still sticking with X.
I guess you can consider yourself lucky that you're not affected by those bugs? Things are ostensibly already broken and have been for quite some time, some of those bugs are over 15 years old. If you only care about bugs that affect you then it's not even worth having a discussion about this, you can't expect everyone to wait to make changes until it's personally convenient for you. And if that's not what you meant then the other stuff is still there if you change your mind and decide to switch.
"I pointed out doing so would have been a better choice than starting over from scratch, and that the choice to start over from scratch is the reason people are still sticking with X."
I would urge you to look into how much work it would take to actually fix those bugs and push out incompatible server/libraries/etc to people and then come back and see if you'd like to revise this statement. Because that is what we are looking at here. Remember what you are asking here is for every toolkit and program to do a "if x12 then dostuff elseif x11 then do otherstuff" and weigh that versus "if wayland then dostuff elseif x11 then do otherstuff".
There are always bugs in complex software, so sure. I can also consider myself lucky that I'm not forced into using a Wayland compositor as it'd force me to change my workflows in all kinds of ways.
> If you only care about bugs that affect you then it's not even worth having a discussion about this, you can't expect everyone to wait to make changes until it's personally convenient for you
I'm not expecting anything other than to keep using the software which works for me. I'm not the one arguing for people to change setups that works for us. Use what works for you. If that's Wayland that's your choice. For me it's not - it involves putting effort into something that doesn't give me amy benefits. Nobody is arguing for you to do anything or not anything.
> I would urge you to look into how much work it would take to actually fix those bugs and push out incompatible server/libraries/etc to people and then come back and see if you'd like to revise this statement.
No, I wouldn't like to revise that statement, because none of the bugs are relevant for an updated protocol unless you choose to keep the things that are broken, since the "worst case" is to throw away and start over the same way Wayland did.
> Remember what you are asking here is for every toolkit and program to do a "if x12 then dostuff elseif x11 then do otherstuff" and weigh that versus "if wayland then dostuff elseif x11 then do otherstuff".
And it's obvious that the number of if x12 then dostuff would have been far smaller and/or amortized over longer time because you'd only need them in cases where you actually introduced a breaking change that couldn't be fixed by using functionality that would keep working the same on both.
Most modern X11 apps already don't use most of the functionality of X that is worth deprecating, and for many of those who do the solution would be to change to a request that'd be worth keeping, not to add an if x12. E.g. as I mentioned there are a number of different ways of rendering text with X. The most popular terminals are split roughly in two broad groups: Those who use the old server side rendering, and those who use XRender (a couple of outliers use OpenGL). Most of the ones I've looked at use Xlib etc. directly rather than toolkits, though some of the font stuff in Xlib is wrapping the server side functionality in ways that could be retargeted to use Freetype.
If you remove the former, then ~half of the terminals would need to get updated to use the latter method or forced to use a proxy (ditching most of them isn't really an option - many of the most feature-complete ones use X directly, and all of the ones I have looked at have users who swear by them and will keep using them until there is a feature complete replacement; many of them are decades old and their users still don't agree there's one worth switching to) or client-side reimplementation of the font rendering. But assuming you were to retain the XRender glyph rendering you wouldn't need to special case for this hypothetical x12, just upgrade apps to use XRender, and you could yank out all the font support in the server. Moving to Wayland on the other hand requires all of them to change
To date most of the terminals I've looked at haven't been updated with Wayland support, and many probably never will, making XWayland and so most of Xorg still hang around as long as they have users and someone cares. Given how long many of them have survived, I'm guessing you'll have to wait for their user bases to literally die out.
The X12 approach would have allowed starting to actually deploy the improvements stepwise more than a decade ago. Or more. E.g. the XFIXES extension happened in 2003 and was the first real attempt at some somewhat potentially breaking changes hidden behind an extension flag rather than a version change (and didn't allow the server to actually ditch the old code). Nothing other than politics stopped a more drastic approach.
This notion that there were technical barriers stopping an iteration of X is pure fiction.
