5 ms·

> This brings so many advantages, such as true tear-free graphics and lower input latency. Curiously, people always seem to list the same advantages, and it's

> This brings so many advantages, such as true tear-free graphics and lower input latency. Curiously, people always seem to list the same advantages, and it's a very short list. Fewer (but still non-zero) torn frames are the top of the list pretty much every time, since that was the very first thing its creator listed in his original goals... but that's a pretty small benefit in exchange for breaking entire categories of functionality. Like, it looks smoother when I scroll, but features I rely on heavily every day are forbidden. As for input latency... that doesn't seem like it was ever a problem. Using X11, I'm able to get 500 to 1000 inputs per second even on a potato PC. That's faster than the frame rate of pretty much any screen, and fast enough even for audio / midi purposes. Reducing input latency from ~1.5ms to ~1.0ms doesn't really matter when the timeslice scheduling has ~6ms of jitter on an average system, a common screen only draws a frame every ~16ms, and many input devices have 50+ ms of their own additional latency. > if you want to take a screenshot in a generic way, you have to go through the XDG portal API This is a symptom of what's wrong with Wayland. Wayland doesn't do screenshots. Like many things users need, they decided it was someone else's problem, and threw it over the fence for the fragmented ecosystem of downstream projects to solve. So each downstream project came up with their own workarounds for essential features not existing. The solutions had to be built entirely outside of Wayland, and even after years of development, the solutions are still incomplete, unreliable, complex, and full of caveats. It required (and still requires) everyone except Wayland's core devs to write a lot more code for less functionality than they used to get with a couple of simple API calls. They had to architect entire complex infrastructure layers in order to work around a missing feature in the core protocol, since the core devs stubbornly refused to allow it. Similar situation for input automation and remote control. It's a common thing people need. I use it every day and can't use the notebook at my desk without it... but the Wayland folks refused to solve it, so it had to be done outside of Wayland. For example, one workaround is to give the user direct access to the kernel so they can create fake input devices at a kernel level, and generate the inputs they need, which Wayland then sees as a local physical keyboard or mouse. So... problem solved, from Wayland's point of view. The user gets what they need, sort of, and it's implemented outside of Wayland, so Wayland doesn't have any security issues. But... and this is a big "but"... the solution involves giving users device-level kernel access. Which seems significantly worse than the issue it was originally trying to solve. > I understand where you're coming from, but there is no turning back at this point. A position of "sure it has major problems, but it's too late now" is not a position of progress. Much like the situation with pulseaudio being deployed everywhere then replaced with pipewire, it's almost never too late to fix bad software architecture. As you said, this whole ecosystem is still very much a moving target. The ideal solution would be the creation of a new system which supports the features, protocols, and APIs of the older system(s), in a way which "just works". But that requires a very different mindset from the people behind it. Instead of "not my problem, someone else can deal with it" like the Wayland policy, a proper solution needs people to adopt a "the buck stops here" approach, and take responsibility for making the entire system work. Things like accessibility, network transparency, automation, and legacy support... need to be built in from the ground up, not rejected or treated as an afterthought for someone else to handle.

deleted 1mo ago
[deleted]
throwaway84933 1mo ago
> Curiously, people always seem to list the same advantages, and it's a very short list. The things I listed are just the tip of the iceberg. Having studied earlier versions of X like X10, X11, and now Wayland, I could go on and on. What I'm trying to emphasize here is not to look at Wayland through an Xorg lens. I know it's easy to look at Wayland and immediately think it's a rigid protocol that breaks everything, but the reality is that it's a lot more flexible than people realize. Once you understand it, I think the closest thing that comes to mind is "There is no spoon." And just like there is no spoon, there are also no windows, only surfaces, but again, that's only the tip of the iceberg. If you want an example of what I'm talking about, take a look at projects like p9wl. [0] This is using wlroots to create a proxy between Linux and Plan 9 in order to display windows remotely. Such flexibility is only possible when the protocols are small and composable, which Wayland is. > As for input latency... that doesn't seem like it was ever a problem. I never said it's impossible to get acceptable input latency on Xorg. I'm just saying that when your input and graphics go directly through your compositor, the experience is on a completely different level. This is even more true with features like direct scanout, where the compositor steps aside to send graphics directly to the GPU and input directly to the game as it goes fullscreen. It simply makes using your computer so much more pleasant. These input latency issues were exactly what Kristian Høgsberg tried to fix in Xorg, and addressing them was one of the primary motivations behind creating Wayland. [1] > This is a symptom of what's wrong with Wayland. Wayland doesn't do screenshots. You're thinking through your Xorg lens again. That's understandable, since you're probably used to it. However, to really understand Wayland, you have to look at it through a different lens. Wayland isn't defective, and it's not trying to be Xorg 2. It's a protocol. It doesn't do your laundry, nor does it take screenshots. It's just there to provide the mechanism for sending buffers to your compositor. You can think of Wayland as thin building blocks to build compositors, just as you can build window managers on X, except this time, the core protocol does one thing and the libraries already exist. Wayland exists because all the infrastructure is already there in the kernel and in libraries. The screenshot feature is the job of the compositor. Most compositors already have this feature built in. As I mentioned before, XDG portals exist, and interoperability will only keep getting better. > Similar situation for input automation and remote control. I agree input automation and remote desktop are still problematic. GNOME and KDE have their own remote desktop solutions, as do most of the others, but I haven't had a need to use them myself. All in all, Wayland really isn't trying to prevent you from doing things, it's just a protocol. I'm pretty sure all this will be solved eventually, and I understand the frustration of those who need these features. However, I also understand Wayland and compositor developers taking a careful approach here, and it shows. > A position of "sure it has major problems, but it's too late now" is not a position of progress. That's not what I intended to say. The intended message was: the core Wayland protocol is set in stone and won't change, but we can build these things that aren't working and make them work. That is already happening every day. Progress has been steady, it's a lot better than it used to be, and it will only keep getting better. Going from Wayland into a whole different windowing system, I don't see that happening, at least not in the next 60+ years, but I definitely see the whole Wayland ecosystem improving. [0] - https://www.youtube.com/watch?v=tRx75piIlxo https://www.youtube.com/watch?v=tRx75piIlxo [1] - https://archive.fosdem.org/2012/interview/kristian-hogsberg.html https://archive.fosdem.org/2012/interview/kristian-hogsberg....

deleted 1mo ago

[deleted]

throwaway84933 1mo ago

> Curiously, people always seem to list the same advantages, and it's a very short list. The things I listed are just the tip of the iceberg. Having studied earlier versions of X like X10, X11, and now Wayland, I could go on and on. What I'm trying to emphasize here is not to look at Wayland through an Xorg lens. I know it's easy to look at Wayland and immediately think it's a rigid protocol that breaks everything, but the reality is that it's a lot more flexible than people realize. Once you understand it, I think the closest thing that comes to mind is "There is no spoon." And just like there is no spoon, there are also no windows, only surfaces, but again, that's only the tip of the iceberg. If you want an example of what I'm talking about, take a look at projects like p9wl. [0] This is using wlroots to create a proxy between Linux and Plan 9 in order to display windows remotely. Such flexibility is only possible when the protocols are small and composable, which Wayland is. > As for input latency... that doesn't seem like it was ever a problem. I never said it's impossible to get acceptable input latency on Xorg. I'm just saying that when your input and graphics go directly through your compositor, the experience is on a completely different level. This is even more true with features like direct scanout, where the compositor steps aside to send graphics directly to the GPU and input directly to the game as it goes fullscreen. It simply makes using your computer so much more pleasant. These input latency issues were exactly what Kristian Høgsberg tried to fix in Xorg, and addressing them was one of the primary motivations behind creating Wayland. [1] > This is a symptom of what's wrong with Wayland. Wayland doesn't do screenshots. You're thinking through your Xorg lens again. That's understandable, since you're probably used to it. However, to really understand Wayland, you have to look at it through a different lens. Wayland isn't defective, and it's not trying to be Xorg 2. It's a protocol. It doesn't do your laundry, nor does it take screenshots. It's just there to provide the mechanism for sending buffers to your compositor. You can think of Wayland as thin building blocks to build compositors, just as you can build window managers on X, except this time, the core protocol does one thing and the libraries already exist. Wayland exists because all the infrastructure is already there in the kernel and in libraries. The screenshot feature is the job of the compositor. Most compositors already have this feature built in. As I mentioned before, XDG portals exist, and interoperability will only keep getting better. > Similar situation for input automation and remote control. I agree input automation and remote desktop are still problematic. GNOME and KDE have their own remote desktop solutions, as do most of the others, but I haven't had a need to use them myself. All in all, Wayland really isn't trying to prevent you from doing things, it's just a protocol. I'm pretty sure all this will be solved eventually, and I understand the frustration of those who need these features. However, I also understand Wayland and compositor developers taking a careful approach here, and it shows. > A position of "sure it has major problems, but it's too late now" is not a position of progress. That's not what I intended to say. The intended message was: the core Wayland protocol is set in stone and won't change, but we can build these things that aren't working and make them work. That is already happening every day. Progress has been steady, it's a lot better than it used to be, and it will only keep getting better. Going from Wayland into a whole different windowing system, I don't see that happening, at least not in the next 60+ years, but I definitely see the whole Wayland ecosystem improving. [0] - https://www.youtube.com/watch?v=tRx75piIlxo https://www.youtube.com/watch?v=tRx75piIlxo [1] - https://archive.fosdem.org/2012/interview/kristian-hogsberg.html https://archive.fosdem.org/2012/interview/kristian-hogsberg....