4 ms·

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

by 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.
    - jude- 6y ago
      > AFAIK DRI3 is also Linux-only and is not supported on any X server outside of Linux. 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.

by jude- 6y ago

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.
  - jude- 6y ago
    > AFAIK DRI3 is also Linux-only and is not supported on any X server outside of Linux. 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.