3 ms·

Don't get me wrong, I'm not trying to suggest that the X devs are ignorant of this. I too have both deep respect and gratitude for the work they have done and

• kaba0 6y ago
  Here you are: https://youtu.be/cQoQE_HDG8g https://youtu.be/cQoQE_HDG8g It’s a great presentation by one of the guys behind wayland, who worked on X a lot before. Basically, X has a fundamentally misaligned abstraction of the underlying hardware - which is expected based on its age. When used with a compositor, it is basically a middle-man with no function whatsoever. So Wayland decided to cut out the middle man and pass events directly between client and compositor. But please watch the video, I think it will answer all your questions. Also, it’s not like X will be totally deprecated, XWayland is an API implementation of it that will be supported forever.
  • jude- 6y ago
    Right, and as I said elsewhere, this is a problem with the reference implementation being crusty, not X11. That seems to be the point the speaker is making as well. Like, I'm fully supportive of having the X server simply manage DRI3 for a bunch of clients and composite the results. That's all well and good. I'm less supportive of doing this while also removing all support for the other things that the X server provides the ecosystem: * Unified input/event capturing and forwarding * Unified screen capturing/recording * Window management * Clipboard * Structured IPC (on top of which you get ICCCM and NetWM) * Xrdb * Xprops * Notions of windows in general (everything's now client-side) * Fonts * Drawing APIs These were all standardized things that users could count on always being available, regardless of which GUI programs they used. Wayland completely punts on these things and defers them to extensions. Before you ask, I've already seen the "Wayland is a protocol; these are all extensions" song and dance routine. That's a cop-out. Dropping these things means that there will now be multiple incompatible implementations of the same concept, and no way to mix-and-match them because they now all have to be built into the same process that does your window management. Wayland implementations completely destroy this digital commons, for no apparent reason or gain for the users. The only people I see potentially benefiting from this are full-fledged DEs who can leverage their compositors' incompatible implementations to enact a form of lock-in (i.e. your GNOME programs are no longer guaranteed to run in KDE, and vice versa). So, why do this?
    • kaba0 6y ago
      > Unified input/event capturing and forwarding This is simply insecure. “It is easier to cut holes into a solid block than to patch something that looks like swiss cheese”. What reason does a random app has to see each keypress, when it doesn’t have focus? Do you trust eg. the teams app or the million other app to be a good citizen? Screen capture is implemented with pipewire in a better way than before. Fonts: noone uses the old font API of X, even under X. And third party libs like cairo work on both wayland and x, so nothing is lost here. Drawing APIs: show me any app that uses it and was upgraded in the last two decades. Feel free to use a CPU only drawing API, I prefer not watching the line getting rendered. Also, as I already mentioned XWayland is important for exactly this reason - it is a completely backward compatible X implementation, on top of a better display protocol. What’s the actual problem, because I still don’t see it. There is no need to have incompatible implementations of each, and just look at the three main wayland implementations: they share many of the work.
      • jude- 6y ago
        > This is simply insecure. “It is easier to cut holes into a solid block than to patch something that looks like swiss cheese”. What reason does a random app has to see each keypress, when it doesn’t have focus? Do you trust eg. the teams app or the million other app to be a good citizen? Up-thread I was asking why X.org doesn't simply firewall apps off from one another, and ship with an extension to control this firewall. Adding this capability to X.org (or any X11 implementation) could be done without throwing X11 away. Having a unified way to decide which programs get to see which events would be lost in a transition to Wayland, since each compositor would ship with its own incompatible way of doing this. > Screen capture is implemented with pipewire in a better way than before. It also requires that the given Wayland compositor works with it. So, you're SOL if the window manager you're using happens to be welded to a Wayland compositor that doesn't. This wasn't the case before with X11, where screen capture was handled by the X server. > Fonts: noone uses the old font API of X, even under X. And third party libs like cairo work on both wayland and x, so nothing is lost here. > Drawing APIs: show me any app that uses it and was upgraded in the last two decades. Feel free to use a CPU only drawing API, I prefer not watching the line getting rendered. I wonder why the server still has them, then. Surely the X.org developers would have simply deleted old code without throwing the whole server away if they were as certain as you are that no one uses them? Also, I see you haven't addressed the other points I raised (Xrdb, clipboard, ICCCM, NetWM, xprops, window management, etc.). > Also, as I already mentioned XWayland is important for exactly this reason - it is a completely backward compatible X implementation, on top of a better display protocol. What’s the actual problem, because I still don’t see it. It's not 100% compatible -- things still break. Distros are up-front about this (I have a sibling comment with sources). > There is no need to have incompatible implementations of each, and just look at the three main wayland implementations: they share many of the work. So now if I want to go and build a window manager, I have to go and re-implement a whole crap-ton of extensions myself that the X server used to do for me? And I have to do it perfectly, so apps written for other DEs won't just break? Sounds like a walled garden to me -- it raises the barrier to entry for new players.