> You could do that but such an X server would not really be any practically different from Wayland.
Not quite -- the X server would still provide all the device-independent IPC, input, and screen multiplexing facilities and APIs. Dealing with input isolation could be addressed with an extension.
So I think this answers my question -- Wayland isn't anything special. It sounds like I'd get a lot of mileage out of taking wlroots and adding back in all the device-independent X11 protocols as a Wayland extension. This would basically be the "X server with only DRI3" I described.
In Wayland those tasks have been split out into libraries. The details of the protocol IPC is handled by libwayland, the input is handled by libinput. Screen multiplexing is specific to the compositor and not really something you can farm out to a library, which is the same as composited X where the compositor process takes over the entire screen and handles all the rendering.
It would be interesting if someone combined an X server with a Wayland server like you described, but I don't think it would be useful. A lot of your legacy applications would still be broken, for example no old clients or window managers are rendering using DRI3. If you want to design an extension for client isolation, the problem there isn't that X doesn't have that but that the existing methods don't really work well. My suggestion there would be to talk to any desktop environments to find out what their requirements are, if they haven't already committed to switching to Wayland already. (i.e. GNOME and KDE already have their solution for this in Wayland) It may be that an additional X extension is unnecessary for what the other desktops require.
So? I never said I cared about the portability of low-level rendering software. It's not like anyone cares that Xenocara and the aperture driver only work on OpenBSD, for example.
> Screen multiplexing is specific to the compositor and not really something you can farm out to a library, which is the same as composited X where the compositor process takes over the entire screen and handles all the rendering.
Hold up. Isn't screen multiplexing and compositing exactly what libwayland gives a program the power to do? You'd build and run a compositor (like Sway, or like Kwin), and it fulfills compositing, screen multiplexing, and so on, as well as IPC, window management, hotkeys, screenshots, etc.
At least with X, these were separate programs you could mix and match.
> It would be interesting if someone combined an X server with a Wayland server like you described, but I don't think it would be useful.
I'd find it useful. I don't care if no one else does, since I'm writing this for myself.
> A lot of your legacy applications would still be broken, for example no old clients or window managers are rendering using DRI3.
I'd add the necessary compatibility code for the programs I need to run. I'd add them in a way that, if others wanted to fork my code, they could easily restore their own legacy code paths.
> If you want to design an extension for client isolation, the problem there isn't that X doesn't have that but that the existing methods don't really work well.
Sounds like a problem with the particular extension, not X11.
> My suggestion there would be to talk to any desktop environments to find out what their requirements are,
Don't care. I'm not doing this for them. I don't use any of them, and they're all dead to me at this point. I'm doing this to keep my minimalist X11 window manager and X11 clients, and to satisfy my intellectual curiosity.
Libwayland is a small library carrying the implementation of the wire protocol, and a few other bits like a simple event loop for servers and a library that can load X cursors. The point with that is that you're bringing your own compositing and multiplexing anyway. From there it's optional if implementations want to put in additional features for IPC, window management, hotkeys, screenshots, etc, and they can choose if they want to put that in the server or put it in a separate program. So you can still mix and match on some level anyway, it's not quite the same though.
I had exactly the same idea as you a few years ago to build something like that and I thought it would be useful too, and I thought about it for a while and realized that it doesn't really give you any of the benefits of Wayland or the benefits of X11. The point with wayland is already that it strips the unnecessary bits out and maintains a legacy code path with XWayland, and the point with X is that it's always going to keep the legacy code running anyway, so you don't gain much by combining them. If you have a minimalist window manager that's only a few thousand lines of code, and you want to get the benefits of Wayland, it's much easier to just port that using wlroots or something than it would be to rewrite the whole X server. That's just my experience.
>Sounds like a problem with the particular extension, not X11.
Since this is an issue with Xorg lacking the right extensions it's basically the same thing.
Allow me to qualify: ON LINUX! Sorry if that wasn't blindingly obvious when I said I was totally on-board with a DRI3-only X server.
> The point with that is that you're bringing your own compositing and multiplexing anyway.
I did not have to do this in the X server world. I did not have to worry about inter-compositor compatibility, because there was only one compositor implementation. Wayland has made me have to do extra work for absolutely no gain. This has got to be the fifth time I've explained this on this comment thread. I don't know how much clearer I can be.
> From there it's optional if implementations want to put in additional features for IPC, window management, hotkeys, screenshots, etc, and they can choose if they want to put that in the server or put it in a separate program. So you can still mix and match on some level anyway, it's not quite the same though.
I'm glad you've understood that N different window managers will now have N different ways of doing this, whereas before, N different window managers only had 1 way of doing this. It's nowhere near close to the same -- now in order to do one thing reliably, I have to implement it N different ways.
It's infuriating that none of the Wayland fans seem to see this as a problem. It's almost as if they're the ones who won't be suffering the consequences of their bad architectural decisions!
You do have to bring your own multiplexing in the X world if you were implementing an X compositor. Maybe that's unfortunate to you that the focus changed to X compositors, but Wayland didn't change the fact that this work has to be done by some willing party to get that to work.
I wouldn't call myself a "Wayland fan" but what you are saying isn't really a problem, the different window managers can choose to implement it just one way. They don't have to do it N different ways, of course they will do it differently if they have a valid reason to. From an application developer perspective you shouldn't have to deal with this problem, I'm sorry if you are a toolkit developer and this has caused you pain, but in my experience nearly all of the bits that you would need to have to do a native port to Wayland aren't specific to any window manager.
Not holding my breath. Just because you have a standard doesn't mean all implementations behave the same. In fact, they usually don't, which is the problem.
> but what you are saying isn't really a problem
Thank you for proving my point about being in a position where you don't have to suffer the consequences of your bad architectural decisions.