3 ms·

You asked if other X servers are used, there are other X servers that are widely used outside Linux (Xquartz, Xwin, etc) which would break if the clients requir

You asked if other X servers are used, there are other X servers that are widely used outside Linux (Xquartz, Xwin, etc) which would break if the clients required DRI3. 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.

jude- 6y ago
> You asked if other X servers are used, 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!
- cycloptic 6y ago
  If you're talking about making something that is Linux only, that also would be a no-go for X clients that expect to run on other operating systems. They would still want to maintain the old code path, so it wouldn't help much. 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.
  - jude- 6y ago
    > the different window managers can choose to implement it just one way. They don't have to do it N different ways, 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.

jude- 6y ago

> You asked if other X servers are used, 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!

cycloptic 6y ago
If you're talking about making something that is Linux only, that also would be a no-go for X clients that expect to run on other operating systems. They would still want to maintain the old code path, so it wouldn't help much. 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.
- jude- 6y ago
  > the different window managers can choose to implement it just one way. They don't have to do it N different ways, 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.