4 ms·

> I tried to give a hint about the basic reason of trying to get out from under the weight of a huge code base that had become old and crufty while the very arc

by jude- 6y ago

> I tried to give a hint about the basic reason of trying to get out from under the weight of a huge code base that had become old and crufty while the very architecture it was designed around was becoming moot since things were shifting to client side rendering already. I can totally get behind doing a clean re-write of X.org (possibly in a memory-safe language this time around) in order to get rid of legacy cruft that's truly no longer used. They could take the opportunity to refactor the super-popular X extensions like GLX to have better "happy paths" in order to make the overall implementation cleaner and easier to maintain. This could even be done incrementally in order to avoid breaking existing clients. What I'm struggling to understand is what's so wrong with X11-the-protocol and the popular extensions that ditching everything was considered the best idea? Like, if the X11-to-Wayland transition were happening on the Web, it would be a lot like Google deciding to ditch HTML/CSS/Javascript in favor of something home-grown. Sure, that homegrown thing might actually be better, but it would really leave everyone else in a real lurch now, wouldn't it?

tux1968 6y ago
Well there were a lot of problems with the X protocol actually, having to do with latency and multi-threading support at the very least. So much so that Xcb was developed as a replacement protocol; so applications were already having to be refactored if they wanted to avoid such problems. But really, most applications do not deal with Xlib or Xcb _anyway_, they are programmed at the Gui toolkit level. So all that has to be done is add another backend to the few popular toolkits in use. But guess what, Wayland supports both Xcb and Xlib protocols through a virtual X server that transparently translates to Wayland if that's what you have your heart set on. But I have lost track of what the specific problem is you're actually trying to solve.
- jude- 6y ago
  XCB and Xlib are libraries that implement the client side of the X11 protocol. They are not themselves protocols. I'm trying to fix the problems with X11 that supposedly justify Wayland's existence, because I have reason to believe that fixing/extending X11 would be far less painful and far easier than throwing it all away. However, no one seems to be able to explain what is unfixable about X11. I assume in good faith that Wayland exists because there is something truly unfixable. I'd like to know what that is. Note that I'm talking about the protocol here. People here (yourself included) point out that X.org is old and hard to maintain. This may be true, but that is a problem with the reference implementation, not the X11 protocol. Thus it doesn't in my mind justify Wayland's existence (but it does justify writing a new reference implementation). EDIT: Here's an example -- what if someone wrote an X server that only allowed clients to render via DRI3, and by default prevented programs from receiving keyboard or mouse events intended for other programs? There would be a new protocol extension for setting and querying these blocking policies, so integrators could set more-secure default access controls without breaking compatibility. Isn't that basically what Wayland is aiming for -- client input is isolated and everything graphical happens through off-screen rendering to client-controlled GEM buffers?
  - cycloptic 6y ago
    You could do that but such an X server would not really be any practically different from Wayland. You would still complain that it broke your old clients, and newer clients would still have to maintain two code paths for the newer server and for the X servers that didn't support DRI3. (DRI3 is not supported when running X clients over the network for example)
    - jude- 6y ago
      Are there widely-used X servers that don't support DRI3? Genuine question -- it's been out since 2013. I realize that DRI3 doesn't work over the network (I also never complained about losing X11's network transparency). > 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.
      - cycloptic 6y ago
        AFAIK DRI3 is also Linux-only and is not supported on any X server outside of Linux. 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.

by jude- 6y ago

tux1968 6y ago

Well there were a lot of problems with the X protocol actually, having to do with latency and multi-threading support at the very least. So much so that Xcb was developed as a replacement protocol; so applications were already having to be refactored if they wanted to avoid such problems. But really, most applications do not deal with Xlib or Xcb _anyway_, they are programmed at the Gui toolkit level. So all that has to be done is add another backend to the few popular toolkits in use. But guess what, Wayland supports both Xcb and Xlib protocols through a virtual X server that transparently translates to Wayland if that's what you have your heart set on. But I have lost track of what the specific problem is you're actually trying to solve.

jude- 6y ago
XCB and Xlib are libraries that implement the client side of the X11 protocol. They are not themselves protocols. I'm trying to fix the problems with X11 that supposedly justify Wayland's existence, because I have reason to believe that fixing/extending X11 would be far less painful and far easier than throwing it all away. However, no one seems to be able to explain what is unfixable about X11. I assume in good faith that Wayland exists because there is something truly unfixable. I'd like to know what that is. Note that I'm talking about the protocol here. People here (yourself included) point out that X.org is old and hard to maintain. This may be true, but that is a problem with the reference implementation, not the X11 protocol. Thus it doesn't in my mind justify Wayland's existence (but it does justify writing a new reference implementation). EDIT: Here's an example -- what if someone wrote an X server that only allowed clients to render via DRI3, and by default prevented programs from receiving keyboard or mouse events intended for other programs? There would be a new protocol extension for setting and querying these blocking policies, so integrators could set more-secure default access controls without breaking compatibility. Isn't that basically what Wayland is aiming for -- client input is isolated and everything graphical happens through off-screen rendering to client-controlled GEM buffers?
- cycloptic 6y ago
  You could do that but such an X server would not really be any practically different from Wayland. You would still complain that it broke your old clients, and newer clients would still have to maintain two code paths for the newer server and for the X servers that didn't support DRI3. (DRI3 is not supported when running X clients over the network for example)
  - jude- 6y ago
    Are there widely-used X servers that don't support DRI3? Genuine question -- it's been out since 2013. I realize that DRI3 doesn't work over the network (I also never complained about losing X11's network transparency). > 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.
    - cycloptic 6y ago
      AFAIK DRI3 is also Linux-only and is not supported on any X server outside of Linux. 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.