4 ms·

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

by 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.
  - kaba0 6y ago
    > 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 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. > Having a unified way to decide which programs get to see which events would be lost in a transition to Wayland Why would it be lost? There is a core protocol that absolutely specifies it. > This wasn't the case before with X11, where screen capture was handled by the X server. And when you had only one player in the whole game.. which is pretty contradictory to your last sentence. > I wonder why the server still has them, then. Backward compatibility. Show me any desktop app that uses eg. xmotif or something. And with xwayland even these 30 years old apps can be run. 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) > It's not 100% compatible -- things still break. Distros are up-front about this Such is life, I really can’t say anything else to this. > 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? No, you just use wlroots that implemented the “crap-ton” of extensions for you already, and be on your way.

by jude- 6y ago

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.
- kaba0 6y ago
  > 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 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. > Having a unified way to decide which programs get to see which events would be lost in a transition to Wayland Why would it be lost? There is a core protocol that absolutely specifies it. > This wasn't the case before with X11, where screen capture was handled by the X server. And when you had only one player in the whole game.. which is pretty contradictory to your last sentence. > I wonder why the server still has them, then. Backward compatibility. Show me any desktop app that uses eg. xmotif or something. And with xwayland even these 30 years old apps can be run. 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) > It's not 100% compatible -- things still break. Distros are up-front about this Such is life, I really can’t say anything else to this. > 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? No, you just use wlroots that implemented the “crap-ton” of extensions for you already, and be on your way.