4 ms·

> Nothing is thrown away -> xserver is there for exactly this reason. Adding the extension for a system with bad abstraction is not too wise, but if you wanted

by jude- 6y ago

> Nothing is thrown away -> xserver is there for exactly this reason. Adding the extension for a system with bad abstraction is not too wise, but if you wanted to understand it, you would have done so already based on the video. I did watch the video, and while I was convinced that the X.org reference implementation was crusty, I was not convinced that there was anything inherently wrong with X11-the-protocol. Like, if there existed an X extension whose responsibility was just to get clients set up with their own video buffers that it could composite for them, then it sounds like it would address 90% of Wayland's value proposition. Is there a particular point in the video you want me to pay extra attention to that clarifies this? > Why would it be lost? There is a core protocol that absolutely specifies it. I read through the stable interface definitions in the wayland-protocols repo [1], and did not see anything related to controlling which programs get to see which events. Is this still in development (or unstable)? If so, is there an ETA at which point I can expect every correct Wayland compositor to faithfully implement it? > And when you had only one player in the whole game.. which is pretty contradictory to your last sentence. That's because the X server implements the mechanisms, not policies, for multiplexing the screen and input devices. In the service of this, it provides tools to enumerate, identify, query, modify, and extend properties of windows, as well as route messages between them. There was never a compelling need for multiple competing incompatible X servers because X is the narrow waist (i.e. an unopinionated digital commons) shared by software that competed on policy. > I didn’t address these things because basically everything has a solution under wayland nowadays. Please have a look at the wayland-protocol repo and see for yourself the state of it. Also, wayland is a display manager, just because the X server was a monolith, it had no place to eg. manage clipboard. Actually, Wayland is the one that fulfills the UNIX philosophy of do one thing (although I don’t find the UNIX philosophy a good thing in every case) I read through the unstable interface definitions, and see that Wayland is indeed trying to implement not only the same kinds IPC facilities and input device multiplexing that X provided, but also is trying to impose stronger opinions on what types of windows exist and how they behave (e.g. Wayland has a notion of pop-ups, text inputs, and so on). So if Wayland's goal is to avoid being as "monolithic" as X, it appears to be failing. Also, putting core functionality that everyone must implement the same way into extensions just so they can call Wayland "just a protocol" or "just a display manager" is disingenuous. They might as well just say that they're part of the core protocol. > No, you just use wlroots that implemented the “crap-ton” of extensions for you already, and be on your way. Does the wlroots project define what extensions are standard and required for a piece of software to call itself a Wayland compositor? No? Then "just use wlroots" isn't addressing the problem of making sure these compositors are compliant to a set of common, useful standards. Like, maybe wlroots should be the standard-definer, just as X was? What happens with window managers built with a compositor that is not wlroots? Anyway, I don't want to waste your time. If you can't help me understand why Wayland could not have been implemented as an X extension (including why isolating client input could not also have been implemented as an X extension), then I don't think we're going to get anywhere in this thread. [1] I was looking here: https://github.com/wayland-project/wayland-protocols https://github.com/wayland-project/wayland-protocols

cycloptic 6y ago
There are X extensions for shared memory buffers. Client isolation for X could also have been implemented as some kind of extension. With both of those you could solve some issues but it still wouldn't be the same as redesigning the core protocol. If you are expecting every Wayland server to implement things exactly the same way, that will probably not happen, the point with having different implementations is that they can choose which parts they want. It's currently not looking like there will be any one standard-definer, you can build a monolithic implementation if you want but you don't have to. Yes this might cause some fragmentation but realistically, has X really helped there? The huge proliferation of clones and forks of various X window managers that are incompatible in various ways is another kind of fragmentation.
- jude- 6y ago
  > There are X extensions for shared memory buffers. Client isolation for X could also have been implemented as some kind of extension. With both of those you could solve some issues but it still wouldn't be the same as redesigning the core protocol. So why redesign the core protocol if the selling points of Wayland can be had without going through all that hassle? What are the true selling points of transitioning to Wayland, if they can be had for far less work? > Yes this might cause some fragmentation but realistically, has X really helped there? The huge proliferation of clones and forks of various X window managers that are incompatible in various ways is another kind of fragmentation. There was only ever one dominant X server implementation for the past 30 years (XFree86, then X.org), so yes, I'd say it helped a lot to keep the video/input multiplexing system out of the hands of window manager and desktop environment developers. This ensured that your graphical programs would always work, regardless of what desktop environment or window manager you used, because they all spoke the same protocol and relied on the same reference implementation. A proliferation of Wayland compositors would take all of that away.
  - cycloptic 6y ago
    The basic idea of Wayland is that it is a simplification and streamlining of a display server protocol. The work of designing that core protocol is already done and doesn't need to be done again, the original developer likely did it because they found it interesting or useful to work on in some way. The situation isn't that much better in X, the window manager and desktop environment can break clients in other subtle ways that have nothing to do with the X server. There's no guarantee that graphical programs would always work if your setup does something strange.

by jude- 6y ago

cycloptic 6y ago

There are X extensions for shared memory buffers. Client isolation for X could also have been implemented as some kind of extension. With both of those you could solve some issues but it still wouldn't be the same as redesigning the core protocol. If you are expecting every Wayland server to implement things exactly the same way, that will probably not happen, the point with having different implementations is that they can choose which parts they want. It's currently not looking like there will be any one standard-definer, you can build a monolithic implementation if you want but you don't have to. Yes this might cause some fragmentation but realistically, has X really helped there? The huge proliferation of clones and forks of various X window managers that are incompatible in various ways is another kind of fragmentation.

jude- 6y ago
> There are X extensions for shared memory buffers. Client isolation for X could also have been implemented as some kind of extension. With both of those you could solve some issues but it still wouldn't be the same as redesigning the core protocol. So why redesign the core protocol if the selling points of Wayland can be had without going through all that hassle? What are the true selling points of transitioning to Wayland, if they can be had for far less work? > Yes this might cause some fragmentation but realistically, has X really helped there? The huge proliferation of clones and forks of various X window managers that are incompatible in various ways is another kind of fragmentation. There was only ever one dominant X server implementation for the past 30 years (XFree86, then X.org), so yes, I'd say it helped a lot to keep the video/input multiplexing system out of the hands of window manager and desktop environment developers. This ensured that your graphical programs would always work, regardless of what desktop environment or window manager you used, because they all spoke the same protocol and relied on the same reference implementation. A proliferation of Wayland compositors would take all of that away.
- cycloptic 6y ago
  The basic idea of Wayland is that it is a simplification and streamlining of a display server protocol. The work of designing that core protocol is already done and doesn't need to be done again, the original developer likely did it because they found it interesting or useful to work on in some way. The situation isn't that much better in X, the window manager and desktop environment can break clients in other subtle ways that have nothing to do with the X server. There's no guarantee that graphical programs would always work if your setup does something strange.