Wayland is not ready as a 1:1 compatible Xorg replacement just yet
gist.github.com
gist.github.com
Of course, it's entirely possible I'm misreading the history here: Wayland could've been widely despised back then, or maybe this thread is an outlier. Either way, I'd be happy to see if anybody's got a good pulse check.
(and I think the nvidia issue is solved or close to being solved)
wayland has been the only way I've managed to get tear free smooth 60fps on Linux (trying intel, nvidia and amd drivers on Xorg)
I don't have nvidia.
Where can I learn more?
FWIW I was also an i3 user for a long time (and xmonad before that), and I’m a very happy convert to Sway.
Though, fwiw, I had no issues with screen tearing once I started using picom. I used to have mild tearing before that, but after setting up picom (don't remember how I configured it exactly) I got buttery smooth output!
vsync = true
Put another way: do we truly believe that in 12+ years, some motivated hackers couldn't evolve X11 into something better? I get that many of the people involved were burnt out on it, and sure, no one (myself included) stepped up to the plate, but it doesn't seem plausible to me that X11 and Xorg are lost causes.
IDK. I understand the direction they decided to take.
But when most (every?) computer includes some kind of GPU, local rendering makes the most sense -- especially when that's how your primary competitors work.
I don't know enough about Wayland vs X11 to make an informed statement, but I do appreciate that Wayland explicitly didn't try to include remote rendering. Let's just leave that up to other protocols (VNC/RDP/etc...). Now if we can just get one of those protocols to work on an individual application/window basis as opposed to the whole desktop.
Now I donate monthly to Xorg release engineering.
(for when you very rarely need to use X)
Could you spare a link, so I can follow your example?
EDIT: I should also mention that my experience is overall positive, I use swaywm so config and setup is easier than with X (no xorg.conf to tinker with every driver update) with a small stability tradeoff. Sometimes sessions will crash out when doing things with the GPU dmabuffers, which for a lot of people isn't really acceptable, but also who's usually using dmabuffers?
Oh and mouse interactions can be really wrong when going between xwayland windows and native ones.
Yes. It is not just a random program that needs some fixing here and there, it is a program which has to evolve with all its accompanying user space, as almost anything can be a breaking change. Sometimes reinvention is the correct decision, and I am quite sure that the whole X11 team uniformly deciding on that gives it enough weight.
They didn't switch to Wayland by default, because the apps weren't ready. The apps weren't ready, because they ran on current Ubuntu just fine, so why would they change. Chicken, egg.
Compare that to Apple macOS. Apple breaks macOS compatibility at the rate that GNOME can gush with envy. But the third parties are quick to update, without dragging their feet for years.
So if the signalling was, that Wayland is inevitable by release XX.YY, apps would be ready.
I went looking for a video demoing the first statement and came across https://youtu.be/sdSFzZCgWp0. I'd find a better video but sometimes the worse video is too funny to pass up :).
This post projects an idea that there is a new resurgence of push-back & dislike, a failure to come into fruition, but personally I feel there's been a long continual & ongoing history of refusenik/can't-do attitude, like nearly all new technologies & especially sizable open source developments face. And success is widespread.
What I see as somewhat new is that the pace in Wayland protocol development has indeed really tapered off, with a large part of that slowness being chalk-up-able to (alas) internal obstructionism. A lot of innovations have been really hotly contested. Rather than independent innovation (which Wayland protocols make imminently possible), there's way more bickering in the various protocol proposals & less getting shit off the ground. There's absolutely a place for getting it right, but the clashes have gotten louder & bigger & it's sapping the energy in the room. Virtual input devices for example have been a shit show and a half, all kinds of hard work & valid proposals getting snubbed & shot down left & right, rudely. Some stuff has just been slow: global hotkeys for example.
Even still, I think far more of the problems in this gist relate more to apps that just aren't well maintained (alike your NV gpu that has been a bad actor on the scene), aren't well cared for. Others of these grievances are kind of small & non issues, or just paranoia (eg: conspiracy-theory freak-outs about client side decorations), some are indeed deeply technical sticking points Wayland hasn't specified it's way through yet (hotkeys again), some just seem... wrong (most Intel users don't experience terrible godforsaken tearing all the time?) but a lot of them are just slow apps not doing basic good. Yeah. It takes a long time to improve a vast vast vast vast ecosystem.
That said, it's really been about a year that Wayland has been shipping truly genuinely en-masse, so the visibility & noticeability of issues is much much much higher than it had been.
The fact there was no default widget kit is the big one for me. If you're developing a new GUI in the early 2000s, "all the software looks native" is pretty near table stakes. Yeah, not doing so probably avoided a huge holy war, but surely the right thing to do would have been to do Xaw, GTK and Qt flavoured bindings atop some native widget set so you're at least 70% of the way there.
The movement from "window manager" to "compositor" is a huge scope creep. I'm going to admit that one of the things that drew me into Unix/Linux in the late '90s was the appeal of highly customized X11 desktops (i. e. Enlightenment v0.15).
Now, an X11 "window manager" is probably a within scope of one, or a small team, of moderately competent developers. I think one of the big old O'Reilly X11 reference books actually had a clumsy but functional example with line-by-line commentary. I like that I can run something fairly lightweight (FVWM, for example), instead of having to pull in most of the GNOME or KDE desktop incidentally because I want frames around my windows.
A Wayland-style compositor, on the other hand, seems to be a much higher barrier to entry. The whole "nVidia works, but only with the GNOME compositor" sort of stuff reads as a sign that there's way too much involved in there. I don't recall ever seeing "You have to use TWM because AfterStep won't work with your Trident 9440 video card" back in 1998. I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it.
This wouldn't have worked. Different DEs will never ever ever agree on a common toolkit. If Wayland had a single official toolkit that means that today one DE (probably GNOME) would be using Wayland and every other DE would still be on Xorg (which is unmaintained).
The movement from "window manager" to "compositor" is a huge scope creep.
It's not. It's actually simpler and more reliable to implement window management inside the display server than using a separate process.
I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it.
Agreed. Wayland probably could have done a better job of putting 99% of the code in libweston so that different compositors would only have to reimplement 1%.
But at the same time that was meant as reference implementation, prone to quick changes and no promise of backwards compatibility. It could hinder their initial progress instead.
Wlroots is exactly that and has been available for quite some years now (with many niche wms building on it)
All in all, the basics of Wayland are a pretty tight package. https://wayland-book.com/ goes through the pieces, and it's not a super thick read. The system of passing around surfaces is comprehensible, tight, makes sense, and there is very little fluff or barriers here, imo.
Wayland has a common core, but absolutely I'd grant that the various protocols do indeed make it a much less tightly coupled thing, with different compositors having different sets of protocols they support. So yes, some apps that require advanced capabilities run much better in some compositors than others; the compositor choice matters. Sometimes there are multiple competing protocols for the same feature-sets, but usually/historically, wayland-protocols hammers stuff out reasonably quickly & most of this is a matter of time.
Still, this is often easier than the past, where apps would have to each test for extensions & have various fast/regular/fallback codepaths depending on available extensions; not necessarily a hindrance to the window-manager, but a bundle of complexity for everyone else trying to use X11 adequately. The Wayland common primitives, on the other hand, are fairly universally performant & well chosen.
Returning to complexity for window-manager/compositor, the situation is not unlike X11 itself, where yes, a simple window manager (or compositor) is possible to spin up relatively quickly, but where there is a sea of different standards to implement to do a good job. Window manager hints, extended window manager hints, and a plethora of other standards existed around X11 that were up to the window-manager to tackle, and implementing each of those took a lot of time too, if you wanted good support for all apps. Different Wayland compositors also have different support for different protocols, and those are a bit deeper rooted capabilities, less superficial than many of the X11 hints (which, if ignored, were less likely to impede use), but the idea is the same: real support to really be decent took work in X11, and it takes work in Wayland to implement a good suite of protocols here too.
Where I disagree highly is calling out the hardware here. Wayland is closely tied to kernel fundamentals; any reasonably supported video card will perform adequately under any competent/non-specialist compositor today. (Certainly some compositors could demand higher standards, such as some of the experimental compositors requiring Vulkan, but generally compositors have very similar, very common requirements.)
> I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it.
I like where we are, where there are various toolkits/libraries for accelerated implementing. Wlroots, which underpins chiefly Sway (the i3 replacement), has given rise to a variety of other compositors, spanning the gamut from quick/fast/experimental to rich/deep/powerful. libwayland still defines some core ideas, if not compositing implementations, to speed development somewhat. Weston is still available as a reference compositor, although yes it's designed (more or less) to be forked & enhanced, not built to be preserved & built (extensibly) on top of. Wlroots & other alternative toolkits fill this need, & provide a diversity of ideas for how we might get going. Projects like Greenfield, the HTML5 compositor (https://github.com/udevbe/greenfield) demonstrate the diversity we get from not having a single common core technology, are possible because of this belief in protocol & standards over implementations, eased though implementations might be from promoting something like Weston to the one-and-only implementation.
> The whole "nVidia works, but only with the GNOME compositor" sort of stuff reads as a sign that there's way too much involved in there.
We can't look at a anti-plays-well-with-others entity like Nvidia to assess what is/isn't a good idea. Nvidia spent nearly a decade stomping their feet & demanding only their way was ok. The fact that Embedded OpenGL itself, what the rock their obstinacy was built around (EGLStreams), is quite heavily on the way out further should stress how foolish & self-centered this vendor has been. This discompatibility indicates nothing, is no sign, except an indicator of what kind of a company Nvidia is/was (one that obstructed any implementations of well known & common kernel constructs).
And I very much don’t agree with the window manager compositor “feature creep”. If anything, the only reason it was easy to write for X11 is because X was a huge monolith doing things it really was not meant to, making you in essence write a window layout plugin. That’s why it was easy. But that just pushed (and worse, solidified) the complexity a layer beneath.
Wayland instead solves the complexity of its problem domain, not more, not less. You can still write a window manager plugin over wlroots for example with not much work, but writing a wayland implementation is not the same thing.
Honestly it really wasn't until SGI and NeXT did we see powerful mini computers on the desk running GUI applications in the 90s.
X11 is due for a replacement, but users just dont want to let go. Linux GUI based applications are still a small user base compared to the headless nature Linux normally gets used for.
For every 1 GNU GUI using Linux user, there are 100+ Linux installs that run completely headless. So the demand to move to Wayland is small.
Virtually all of the complaints listed in this rant are the result of enforcing a sane security model.
> I absolutely detest it when software tries to prevent me from doing what some developer thinks is "a bad idea" but did not consider my use case, e.g., running truss for debugging on FreeBSD needs to run the application as root.
These are not compelling arguments for running the GUI as root or allowing different applications to spy on each other.
I suspect the rationale behind this rant is motivated by the author's position as a BSD distro manager. BSD people really dislike it when Linux replaces legacy Unix infrastructure with Linux specific technologies. But if Wayland is doomed as an Xorg replacement, then why has development activity dropped off [0][1]?
[0]: https://www.phoronix.com/scan.php?page=news_item&px=X.Org-Se... [1]: https://www.openhub.net/p/x
For example, screenshots. It is still possible to make screenshots. It is not possible to make screenshots without the user knowing. What use case do you have to make screenshots without user knowledge, that benefits the user?
Why? If you knew all your programs, and that they are well-behaved, there is no need for that.
But we do use protected memory. And IOMMU (you know all the peripherals that you connect to your computer as well, right?). And other facilities intended to separate programs and hardware from each other.
So the same way as programs do not snoop on shared global heap, do not big-bang i/o ports, etc, programs are not supposed to snoop on shared display surfaces (really just a subset of 'global shared heap'). If you need something specific from them, you ask them via defined way (e.g. screenshot API), that might or might not have facilities to enforce access control.
Because we are not relying on them to be well behaved. Instead, we will notice if they aren't.
SCNR :)
I'm sure LOTS of people stopped using certain Unix programs that relied on a single address space whenever that was implemented. But to quote myself a few relies up,
>> These are not compelling arguments for running the GUI as root or allowing different applications to spy on each other.
> or give up on Linux entirely and get a Mac.
You mean the Unix that originally decided against using X11 because it would have required a re-write to do what they wanted anyway [1]? You understand that Wayland was designed by core Xorg contributors to replace X11 because attempts to match OS X resulted in a glitchy nightmare ... right?
[1]: https://news.slashdot.org/comments.pl?sid=75257&cid=6734612
The benefit of being wide open is that no coordination is needed between desktop environment and developer leading to a wide open field of tools that work on every environment without exception, difference in feature set, no need to check if version foo works on version bar of $DESKTOP.
You could of course get virtually the same benefits plus improved security at the cost of some complexity by standardizing the feature in common usage for nearly 30 years towards the beginning of the development cycle of Wayland instead of 13 years in.
You point out the need for security and completely ignore the fact that such security could trivially have been obtained without reducing users to obtaining a pile of tools only from their desktop environment or waiting 20 years for things to standardize so they can again pick and choose the best tools for the particular task.
It's not like they haven't figured out how to do that with Windows or OS X.
> The benefit of being wide open is that no coordination is needed between desktop environment and developer
The same is true of virtual memory.
> You point out the need for security and completely ignore the fact that such security could trivially have been obtained
The Xorg developers who tried really hard for decades would disagree with you. That's why programmers that Red Hat used to pay to hack on Xorg now get paid to develop Wayland [0].
[0]: https://www.theregister.com/2020/10/30/x_server_lead_maintai...
You misunderstand. Wayland development started in 2008. Screenshots/recording should have been on the board from day one and they could have gotten to standardizing on how to handle them in oh 2013-2015?
The sin is not the extra complexity to secure the system. It's having first zero then more than one way to go about it and 13 years later ending up in the situation where some utilities support only X and some only some Wayland implementations. It's the sin of forcing your users to rip out the walls and stare at the plumbing.
What other OS makes you think about display servers?
Red Hat doesn't believe in the Linux ecosystem and it shows they believe in their ecosystem with a singular official GUI and unfortunately an ecosystem in which one is required to use only their tools is a mostly mediocre one because they are best in class in nothing and worst in class in many.
I agree that Wayland's development has taken far too long and the transition has been rocky. But what development team couldn't use more funding? Ubuntu throwing a tantrum after the ecosystem rejected Mir and not contributing to Wayland certainly didn't help.
> What other OS makes you think about display servers?
I am sympathetic to arguments that Wayland/Weston could provide more functionality out-of-the-box. The bazaar's fragmented mess of "desktop environments" is certainly not a strength compared to what the Cathedrals have produced. But Linux's uniquely modular GUI stack necessitates coordination across lots of projects to develop and adopt standards.
But not doing anything and sticking with X11 would have condemned us to being stuck with an insecure, buggy, and visually glitchy mess forever.
> Red Hat doesn't believe in the Linux ecosystem
I have my qualms with Red Hat too, but my point was that Wayland was created by Xorg developers because they tried and failed to make X11 competitive. Seriously, just go watch this XFree86/Xorg/Wayland developer's talk [1].
I will have to disagree. I like having options. Before Wayland having options meant that your app starting GUI and your file manager was different. If Wayland had meant there were now two options one deprecated and the other coming this wouldn't have really been a huge problem.
It's a problem now because insisting on standardizing on so little means we now have fragmentation the likes of which we never had with X and will likely have for many years to come.
Even more so because it isn't yet ready about 6 years after its fanboys started insisting it was and shitting on other options and dismissing actual problems as the mutterings of crackpots and luddites.
What does "competative" even mean in this context? Linux has had a nicer GUI since 2003 and if you don't hop on the pointless change parade a fairly consistent one. I literally switched to linux for a better interface 19 years ago and its still better.
I agree that the transition has been long and messy. But the Linux desktop experience has always been a fragmented mess of half-baked apps that quickly fall into disrepair. Wayland breaks a lot of stuff that has been in maintenance mode for a long time. That sucks, but it's not a good argument for sticking with X11. The situation with X11 had been unacceptable ever since the adoption of virtual memory and Wayland is the only real alternative.
> It's a problem now because insisting on standardizing on so little means we now have fragmentation the likes of which we never had with X and will likely have for many years to come.
I'm not going to criticize the boundaries of a standard that I haven't been deeply involved with. I understand their impulse to keep it minimal, as Wayland is something of a forever standard. But I am sympathetic to arguments that Wayland doesn't do enough.
> Even more so because it isn't yet ready about 6 years after its fanboys started insisting it was and shitting on other options and dismissing actual problems as the mutterings of crackpots and luddites.
If by "other options" you mean Mir, my memory is that the primary criticism of Mir's original architecture replicated Wayland in an incompatible way without any good reason for doing so. Eventually Mir was re-architected to layer it on top of Wayland and does provide more of the batteries you seem to want to have by default.
If by "other options" you mean X11 ... only crackpots and luddites think applications should be able to spy on each other [0].
What other options were there?
> What does "competitive" even mean in this context?
* Not having every app double as a key-logger.
* A working screen-locker.
* Not tearing on window resize or scrolling while a video plays.
* Multi-DPI monitors.
* Non-blocking API calls.
* etc [1].
I remember context menus being especially glitchy.
> Linux has had a nicer GUI since 2003 and if you don't hop on the pointless change parade a fairly consistent one. I literally switched to linux for a better interface 19 years ago and its still better.
Let me guess, you use some "minimalist" desktop environment? I'm not here to hate on people that don't need what most consider a modern user experience. If that's what you want, that's great! I was into lightweight desktop environments for a while and liked exploring that design space.
But I'm also a usability engineer who remembers Linux back then: it was not competitive with OS X and it still isn't.
[0]: https://en.wikipedia.org/wiki/TempleOS
[1]: https://www.phoronix.com/scan.php?page=article&item=x_waylan...
* HALF BAKED
=================================================
> But the Linux desktop experience has always been a fragmented mess of half-baked apps that quickly fall into disrepair.
> Let me guess, you use some "minimalist" desktop environment?
You mean the environments which aren't half backed and instead of falling into disrepair just sit there quietly working the same way so you can use your computer to do useful things?
=================================================
* WAYLAND SECURITY
=================================================
Millions of people have apparently solved the keep applications from secretly hacking you for man eons and decades of real time by not installing uncle bobs malware from www.notarealsite.com or responding to prompts to install software by fake support scam agents.
This is admittedly inferior to better isolation but better isolation is quite hard and few people are actually tackling it in any meaningfully complete way. If I solely switched today from X to Wayland I wouldn't meaningfully improve my security because apps aren't strongly firewalled from one another and so many vectors exist its more like installing a screen door than a bank vault. Proposed improvements like flatpak actually greatly reduce security in practice by
- Allowing users to be targeted by targeting already fixed vulnerabilities in flatpaks with outdated libraries
- Making it MUCH easier to get random bobs software in front of the user
- Trivializing the gap between compromised developer and user by shortening the gap between compromise and distribution from days->weeks to minutes->hours.
All told security is on net a pretty pointless reason to switch to wayland at this point. See qubes, distro processes, FDE, user education about common scams for actual improvement in security.
Lets be real you knew I didn't mean MIR.
=================================================
* COMPETITIVE POINTS
=================================================
- Tearing: I didn't have this problem in 2003 and I don't have it now.
- Multi-DPI monitors: I am typing this on a machine with a 4K monitor flanked by 2 1080p monitors. I scale them down from a higher resolution. Apps think all 3 are the same DPI and its transparently scaled down so that UI elements are identically sized on all displays. Nothing is blurry.
- Non-blocking API calls. I'm using an environment not writing one. None of your users on earth care.
=================================================
* SECURING LOCKED COMPUTERS
=================================================
On desktop machines screen locking provides by default similar levels of security as locking a bathroom door it protects against casual intrusion. You can keep someone from sitting down and looking at your email it cannot prevent an attacker with physical access to your computer from gaining access to your data.
You could get greater security by blocking switching TTY and by blocking usb devices from being attached while the screen is locked for example with USBGuard regardless of choice of display server.
For machines that are at risk of actual attack you would want to to rely on FDE and either full shutdown or locking critical data when user isn't in physical control of the device.
None of this has much to do with choice of display servers and choosing Wayland by default doesn't appear to do much beyond what could be accomplished by blocking changing ttys.
=================================================
* END LINKS
=================================================
I'm not sure why you linked either TempleOS or a 9 year old write up on the design flaws of X.
For what its worth its not only dated but bad as well. Just to pick on a particularly bad patch.
>Wayland breaks everyone's desktop.” Also wrong. Once XWayland is finalized and merged we should have more-or-less perfect backwards compatibility because every X app just gets its own mini X-server to deal with.
This was back in 2013 and the entire ecosystem has spent 9 years going through growing pains with applications going through a plethora of Wayland specific issues with entire categories of applications disappearing or requiring different implementations on different compositors years later. In 2013 this was basically the definition of over-promise under-deliver. It's aged like milk and it makes the authors analysis challenging to take seriously.
Headless browser testing. Network admin at a corporate site. For starters.
For corporate uses, you can use something like vPro and it's remote access. It works independently of the OS (and by default expects user consent too).
It's not going to get better, because Wayland is a broken/malicious architecture: the protocol basically does nothing useful, leaving essential interfaces such as screen recording for individual "compositors" to define and implement mutually incompatibly. This means that nontrivial applications don't really target Wayland, rather they only target a finite set of Wayland compositors (or other, completely separate software stacks) that they have support for.
This sort of works in favor of "big" DEs like Gnome, but for the rest of the ecosystem it would mean death by fragmentation.
Wayland might not be the place for such specs and another common standard should be adopted.
If there was a bad implementation, it could be fixed. Wayland, on the other hand, does not even specify a way to do things like screen recording, screen capture, automation software (e.g. wmctrl), or other miscellaneous screen features (e.g. Redshift) which effectively means that there is no way to do these things at all.
The official Wayland response is that these features need to be implemented by the individual window managers, but the absence of a standard or protocol specifying them means that (a) many window managers will not implement them and (b) those that do will do so in incompatible ways. Which means that a program like a screen recorder, that was previously agnostic to window managers, now must explicitly support each window manager separately, and even then it may not be possible to use everywhere.
X was a gargantuan mess, and it had to go. The by cutting it out, we've also cut out the only commonality, the lowest common denominator software, sitting between widget libraries and the video drivers. There is now no common interface to access a wide variety of important system functions, and no one has a plan going forward. Wayland refuses to step up.
Ever since finding out Wayland is more like a library or spec (wasn't clear and I'm not really into the specifics) that the individual window managers implement, dropping the whole client/server and separation of display and window manager that X11 has, I've been kinda wondering in the back of my mind how long it'll be until someone designs a new system on top of Wayland to bring back that architecture... One that includes these missing APIs that window managers can use, making the new system the common target.
https://gitlab.freedesktop.org/wlroots/wlroots
> missing APIs
They are not missing, they just were moved from the kitchen sink of X to things like xdg-portal and pipewire. This also helps with things like sandboxing for flatpak apps, where you want apps to ask for permission to record the screen.
No, that's what I was thinking of but couldn't remember the name of. I'm imagining separating the window manager like in X, making them interchangeable without having to hook in everything else.
Yeah, it encourages more consolidation, e.g. many projects build on wlroots. Not really different from how it has been before (reuse X and this WM and this compositor and ...). The only difference is that instead of a giant X and the kitchen sink and 50 different small projects on top, you now have a small wayland + xdg-portals + one of gnome/kde/wlroots to build on.
> nontrivial applications don't really target Wayland, rather they...
That sounds like a good thing. Instead of hacking X inputs (e.g. xdotool or xcape, just grabbing any input and window) in a horribly insecure and nonstandard way we now get proper standardized components like the above mentioned portals. So no, they don't target "complete separate software stacks", rather the complete opposite.
This is exactly the thing that's missing and it's practically impossible to hack on top of Wayland now, because any new standard that appears would be just another competing standard (ref. xkcd).
> any new standard that appears would be just another competing standard
That seems to contradict what you just argued. Adding a new standard is hard and needs buy-in from at least one of gnome/kde/wlroots. So instead of "there are now 15 standards" you have a much more pressure to agree on just one.
I’m pretty sure wayland just follows the small core with plugins strategy. If you prefer the kitchen sink way then whatever. There are official extensions to the protocol here https://gitlab.freedesktop.org/wayland/wayland-protocols and there is also the Wlroots library that can be used to implement a compositor. So, no, those smaller projects are not being “persecuted”
Like, you do realize that the “core” protocol set is ever growing and there has been a standard for screen capture for well over a year now to the point where even discord and the like just works on every wayland implementation? There is usually a bit of experimentation done individually to see what sticks and later a core/accepted protocol is proposed that is shared by everyone.
The electron app is not yet working as per the arch linux wiki.
Firefox will stop updating the window contents but will still accept clicks and keypresses. You can either start a new Firefox process or go to the application switcher to see the updated window contents.
OpenSCAD editor has a one second lag between a keypress and the character appearing.
Those are the two that affect me everyday.
Admittedly, I've steered clear of NVIDIA products which may have helped.
I have to switch to X when using those apps.
I've only ever had this behavior with FF running under XWayland. Are you sure FF isn't defaulting to X?
In about:support, I have MOZ_ENABLE_WAYLAND=1 but also MOZ_USE_XINPUT2=1, which I haven't noticed until right now. xeyes doesn't respond at all (window freezes) so I can't tell which backend is actually in-use via xeyes. Finally, I'm using the package manager Firefox, and I'm not sure if that's different than the snap/flatpak.
In the OpenSCAD case, I've tried installing various qt-related and wayland-related packages and setting QT_QPA_PLATFORM or QT_DEBUG_PLUGINS, but this either ends in a crash or the same slow behavior.
I've actually had this happen on macOS (seems to be occasionally triggered on wake from sleep) - assuming it's the same bug, it might not strictly be a wayland issue.
I'm going to disagree; some Wayland implementations of Wayland are good, but the concept is bad. Wayland is a beautiful, elegant protocol that does almost nothing, instead delegating everything more interesting than "display these pixels" to other protocols. That could have worked, but in reality nothing else was actually standardized (n.b. if a "standard" isn't implemented by GNOME, KDE, and libroots, it's not actually a standard), so there is no useful "Wayland" only many Wayland implementations. If you pick an implementation that covers every feature you want, it's great! And if you ever want anything it didn't implement, or ever want to use software targeting a different implementation, you're stuck. Thus, I say Wayland is a bad concept, because it ensures that everyone will be forever reimplementing everything, incompatibly.
Why do you think that? There are some arguments on bleeding edge protocol proposals, but once they are wide-spread enough they seem to get implemented by everyone equally well - causing apps to depend on them and solidifying those.
I don’t see any problem here, the slight slowness of certain proposals is simply the bazaar style development where unlike Apple, linux can’t just decide on a fix thing, it has to get a certain network effect going for it firts.
Bleeding edge? As far as I can tell, GNOME and wlroots still have incompatible APIs for screenshots.
> it has to get a certain network effect going for it
When it takes years to get network effects for little things like screenshots and screen sharing, I certainly see a problem here.
X11 has many things, for example drawing primitives in core; nobody uses it, but it has to be there, because it was specified so.
Wayland extensions, not being mandatory, solve exactly this problem - if something is not used, it could be removed and clients will know very well, that it is not there.
setxkbmap is another interesting thing. There are about two people in the world that know, how it works. Additionally, the linux console used separate mechamism to set console keyboard and font. So it was a duplication of a kind. The nice thing about wayland compositors is, that they remove duplications; X.org (or was it XFree86?) originally included it's own dynamic linker / module loader, driver system and another functionality, that should not be a business of a display server.
So I'm a bit more optimistic. It will became better to the same degree, but it won't be tomorrow. It wasn't quick for X11 either, it took literally decades. Not a consolation, I know.
Wayland isn't a complete replacement of Xorg and has never been intended to be one. Nobody with close knowledge of the project has ever pretended it has - that premise just appears in severe oversimplifications and strawmen. Wayland is just a part of a rethink of how Linux desktop architecture works, together with Freedesktop standards for things like screen casting or window control [1]. The state of complete implementations of those Freedesktop standards - as well as application support - to the point it can replace a lot of X11 is pretty lacking for sure [2]. But that's just unfortunately just what you get when trying to establish such a new architecture in an underfunded and undirected community like the Linux desktop community. No need to "boycott" anything - just use whatever you like on Linux, like you always have.
[1]: E.g. contrary to what many people seem to understand, lacking screencasting support is not actually due to faults in """Wayland""", rather apps and desktops not properly supporting a wholly different Freedesktop standard made to work on Wayland compositors and X11 desktops alike (not dependent on any display protocol at all!). Screencasting on macOS, Windows and Wayland is not the display server's job, it's just one of the many things added to the kitchen sink that has become Xorg.
[2]: In fairness, it covers enough that it's working for a lot of people's workflows. It should work for way more people though, and I hope we get there.
Well, that's part of the problem: I think the consensus is that a lot of these solutions are bunk. Wayland doesn't feel like something you'd build a desktop with, it feels like a software API for digital signage or maybe something for an iPad-like UI. This is cool, but shoehorning it into a desktop is a bad idea. The entire desktop space has moved on, Wayland is comparatively low-tech at this point. Quartz is a good example of this. Not only is it more secure than Wayland, it supports features like app indicators and global menus controls. That's a problem. An even bigger problem is that Mutter, the official Wayland implementation, exists exclusively to support GNOME. Other desktop developers are not welcome, instead they're tossed wlroots and told to make do.
Developmentally, I think Wayland is a trainwreck. If it is a "rethink", then it should have been used to design a tablet OS instead of a desktop OS that runs desktop software and supposedly supports legacy features/apps. If you disagree, then maybe you'd enjoy Windows 8, which is a similarly brave reimagining of the future of the desktop.
And I fail to see your point, you are mixing up wayland’s tasks quite a bit here. It is pretty similar to Quartz, in that it is also a compositor (as is every other OS’s display manager by the way, it is time for Linux to also get there)
Red Hat seems to disagree:
> The X.org display server is deprecated, and will be removed in a future major RHEL release. The default desktop session is now the Wayland session in most cases.
https://access.redhat.com/documentation/en-us/red_hat_enterp...
Otherwise the same thing as usual: pay someone to build actually secure automation tools. The way X does these is horribly insecure and broken by design, so wayland rightfully says they won't support doing it that way. Nothing about not doing these ever.
Same for screen recording by the way. "Any app can see everything with absolutely no security"=not supported anymore. "Any app can use this standard way to ask for permission to record"=new. Obviously that breaks older software, but that is on purpose. So you had a transition period where for instance OBS did not work on wayland, then it was updated and now it does.
This is why permission models exist, make the user aware of the security implications and allow the user to decide on a per-app basis what permissions should be granted. Make the user complimentary to your security model rather than making them an adversary.
There are two processes that need to be running that somewhat work.
xdg-desktop-portal & xdg-desktop-portal-wlr
Even then it can be garbled, only supports one screen, and you can’t use it if the process was started under Xwayland - which is opaque when it’s being used.
Might be better under Firefox, but chrome is spotty for me.
(as the version that ships almost never has wayland support enabled in the sandbox browser- and even force enabling it where it isn’t compiled out crashes it randomly)
EDIT: why did I get downvoted for that? It’s extremely true and I’ve tried to run without Xwayland a lot.
I’ve been using Electron apps natively on Wayland for quite a while with those force-enable flags you mentioned. Few issues so far.
At one point, the apps indeed started crashing. Turns out this was due to the compositor (wl-roots) evolving while the Chromium team didn’t get the memo. They quickly fixed it in Chromium though but not before people started filing bugs. Didn’t take long for their patch to bubble up to the next Electron patch release.
The sooner people report those crashes, the better for everyone involved.
DOSBox exists because DOS legacy applications still exist, and will continue to exist for a very long time. The same is true of X legacy applications.
Soon it will get to the point where the UI toolkits that matter will have ported entirely to Wayland and remove their X11 compatibility code. When that happens, all modern apps will be Wayland-native only. That leaves legacy apps and toolkits that haven't gotten with the program. For those, a VM running an old OS with Xorg will suffice. That is the "DOSBox equivalent" here.
[0] https://wiki.archlinux.org/title/PipeWire#WebRTC_screen_shar...
If I can't run suckless terminal then what's the point of having a computer on my desktop? At that point I might as well kill the GUI altogether!
I haven't disabled Xwayland, but I have configured the apps that by default do not do it (in my case, Emacs and Chrome) to avoid Xwayland and instead to talk directly to Wayland.
(Gnome's interface design decisions are not very good IMO, but that's clearly not Wayland's fault).
At least some of comments on supposed defects in the architecture of Wayland seem to me to be written by long-time X users who simply do not like change. (I used MacOS for 11 years before I switched to Fedora and barely remember X.)
The problem for those that want to continue to use X -- well, Xserver to be specific -- is that nobody wants to maintain it.
I'm reminded of an early systemd security choice that killed all of a users processes on logout, for 'security'. Because they didn't personally have the use-case of wanting to fire off long-running jobs, so didn't consider it.
(I'm not raging at systemd, I like the unit files and while I have some concerns about the design, in general I believe it's a positive thing to have around. IIRC this issue was fixed fairly quickly when it came to light.)
Wow that is crappy. Yeah I haven't encountered it since way-back, partly because my use-cases have changed but also quite likely because debian and ubuntu (my general distros of choice) have configured it better.
Put another way, would you expect to get a higher bill on some cloud provider because after logout some userspace process (say, a dev server) continued to chug along?
I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks like ignoring OS signals instead of exiting for some functionality - that could not be implemented other way back than. But these are trivially portable to user services that are meant to linger after logout (but hurrdurr, why depend even more on evil systemd) with like a few lines of configuration, solving all of these problems.
Just remember, after a while every observable behavior of a program will be dependent on. If the alternative is forever stagnation, I very much prefer evolution and some manageable breaking changes instead.
There wasn't any good reason to change this.
>hur dur why depend on evil systemd
Not everything needs to be a service. I don't mind writing services but stuff like my apt example shouldn't be. This effectively makes interactively using apt reliably over ssh impossible. Sure, I'm the stupid one for wanting usable tools though.
And this is why people reflexively avoid systemd; if you use it stuff just randomly breaks because "stagnation is bad."
If I remember correctly, some systemd maintainer did try to help make tmux systemd-aware so that existing use case could work as-is, but they didn’t want to add it not even as an optional dependency so that’s on them.
I recommend checking out systemd-run, which has a similar mode to basically nohup, you can even alias it to that.
>I recommend
No. Respectfully, shut the fuck up and listen. It isn't just one thing like this. Every month systemd changes some fundamental thing like this and you trip over it. With systemd you trade knowing how the machine is going to behave (even if it's not intuitive to new people) with never knowing because fundamental crap is always changing. Yes there are always solutions but it really doesn't matter because next release something new will break and you'll only find out when it blows up in your face. With a platform you practically can't predict the behavior for correctness doesn't fucking matter. If I wanted an OS that behaved this way I would just run Windows.
>That's on them
No. Breaking standard platform behavior and demanding other projects depend on your rapidly changing project is not "on them."
Signal handlers are simply not sufficient to discern between “ok, I’m getting ready for termination”, “I don’t want to terminate”, “not listening”, and “process not responding”. Just because it has been used for decades, doesn’t mean it was ever good. UNIX has plenty less than great decisions that became set in stone.
If an interactive program crashes the user would notice and kill it. If you never handle the nohup signal (and, again, the only reason for handling it in an interactive program is because you want that program to persist when the tty goes away and almost the only things that do this are tools like nohup and tmux, not the processes that run inside them) then your crashed program is going to be killed by the hup signal when the user closes their terminal.
Yes you can contrive pathological examples, yes signals are hacky in general. You're never going to be able to come up with a real problem with this other than "misusing tmux and nohup to manage deamons instead of initd causes problems." There isn't a legitimate problem with handling the hup signal for interactive tools when the user is expecting it.
>RE: Discerning between states
Yeah if you want the OS to manage a process for you write a service. I'm not going to write a service for everything I do interactively that needs to not die if there's a network problem.
Again, because you seem to be missing it, handling the hup signal in an interactive program is just a way to tell the OS that the user is managing the program themselves. If the user does this and then decides not to manage it, "that's on them."
And finally, the real problem here is that systemd breaks stuff like this all the time and makes the platform unpredictable unless you spend time reading the release notes.
Sure, agreed — and the standard way this was done for decades was by sending a HUP signal to the processes. And the standard way for decades that the user could say, 'hey, don't kill this one process; leave it running' was to use nohup. Systemd just decided to ignore nohup and kill every process, period. After all, it's just as simple for a user to learn the systemd model and how to write systemd unit files, open a text editor, actually write a unit file, install the unit file and use systemctl to start the process as it was to write 'nohup daemon,' right?
This is an example of the sheer unmitigated hubris behind the systemd project. Wayland feels very similar to me. Maybe that's not fair, but it sure feels like it. All I know is that with Wayland I cannot use Linux and Unix for over three decades. It definitely seems to do some things right, but it also seems to do some things wrong, and some things needlessly weirdly.
Among other things, it seems way too difficult to write a compositor from scratch. I am trying to minimise the amount of C/C++ in my life: one nice thing about X is that X bindings exist for many languages which do not rely on xlib or xcb.
Because it changed longstanding behaviour for no good reason, without consulting anyone on whether they wanted it changed.
> Put another way, would you expect to get a higher bill on some cloud provider because after logout some userspace process (say, a dev server) continued to chug along?
Yes, if I instructed that user process to do so, and hadn't explicitly set something up to kill all processes on logout. 100% yes.
> I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks
It's not a hack, and it's not ignoring OS signals. HUP is explicitly a hangup, not a kill. If something keeps going after HUP, you leave it alone.
I log into a remote server and start some long compute job - why on earth should a continuing TCP connection get to be the determining factor in whether my job completes?
> But these are trivially portable
OK, but it is an effort to port, even if it's a small one, and it complicates a very simple way of working.
> some manageable breaking changes instead.
This wasn't a 'manageable' breaking change. It wasn't advertised (clearly, because the distros rolled it back when it was discovered) and it broke stuff, because the people writing the new shiny hadn't even considered that it might be a legitimate use case.
They didn't think and things broke. You don't get to paint that as innovation.
I'm really not a fan of software being this presumptuous. The root of most of my gripes with things like Windows and macOS (not to mention most of the things gnome/freedesktop puts out) are entirely because of this mindset. I am not interested in infecting Linux with this baby-proofing as well.
Security maximalists, especially when removing or refusing to implement useful functionality as a result of that stance, should be reminded that the first pillar of security is availability.
More to the point, you can always add the ability to do stuff like that, when you have the time to do it in a way that lets the user decide what should and should not have any given kind of access. On the other hand, if you start out by just letting everything run amok and then try to add controls later, assumptions will get changed underneath existing programs. That pretty much always makes things break in ugly ways... if it's even possible to do it at all, which is not guaranteed if you didn't think hard before you designed the function to begin with.
It's now something your 70 year grandmother who doesn't understand computers does.
But that is much easier to do than not getting soaked in the rain when all you have is a door in the middle of nowhere.
Do you really think that Linux users are asking "why do you want that?" about screen sharing applications? Of course not. You can't implement screen sharing the same way you did in X, and software will need to change if it wants to support Wayland.
Which shouldn’t surprise anyone changing their display server.
> I don't want one process to be able to […] see what's displayed on another processes windows
The traditional, greybeard way to deal with a misbehaving application is to stop using it. This “security” approach breaks all other applications instead.
Wayland DOES work with fractional scaling values. It's labeled "experimental" right now but in my personal experience it works fine on both GNOME and KDE.
"Nothing we can do from the $SOMESOFTWARE side so we're closing this issue." stuff is also bullshit. Yes, there IS something you can do from your side software wise, and that's UPDATE THE GOD DAMN SOFTWARE. Steam w/ Wine works out of the box with Wayland and GNOME on Fedora Workstation 36. I just did daily quests in The Elder Scrolls Online with it earlier today. I can even run Elden Ring in the exact same configuration. With a damn controller, no less.
So yeah, this is just bullshit.
I'm not sure about how it works in KDE, but at least in GNOME the way it works is kind of a hack IMO. When you do a 150% scale, it renders to a framebuffer at 3x the resolution of your display and then scales the framebuffer down by 1/2, which compromises the video quality, as well as wasting CPU (and battery life if you use a laptop).
Isn't that exactly how apple does fractional scaling?
There is also some kind of belief, that scaling down framebuffer is somehow demanding. It isn't. The output encoder (the modern equivalent of VGA DAC) can do it on the fly. For several overlaid planes, each at different scale, at once (one of these planes is going to be your cursor).
Windows DWM, Android's SurfaceFlinger, and Wayland allow for true native per display fractional scaling but it's still up to each app to actually use it.
Since X11 apps can find out the display dpi and render accordingly, they do not communicate to compositor at which scale they really do render their contents. This gets even more interesting, once there are multiple scales (i.e. you have multiple displays, each at different scale).
This leads to compromise, where xwayland assumes that all X11 clients render at 96 dpi and upscales them to the actual one. It is not pretty, bilinear would not be my choice of algorithm here, but the apps are at least correct size. There are patches floating around that modify this assumption, let X11 clients render at actual dpi, and if they don't, let have the user apps with tiny UI. So YMMV.
To be charitable one would suppose that its just a low priority as fewer people have high dpi displays. If one was less charitable making X apps work slightly shittier serves as motivation for developers to support the new standard. If you listen to these people talk the less charitable interpretation sounds entirely plausible.
Where does it work seamlessly? Yes, Chrome can do that. Gimp and myriad of other X11 apps can't.
I will repeat the point from the previous comment: from the point of compositor there is no way to tell, whether the X11 client does support dpi properly or not. And since it cannot tell (short of guessing), it assumes they don't.
In theory, you could invent a new protocol for X11 apps announcing their capabilities. But good luck with adoption, you may switch to an entirely incompatible protocol as well.
> To be charitable one would suppose that its just a low priority as fewer people have high dpi displays
Strictly speaking, it is not a problem with hidpi. It is problem with fractional scaling.
With hidpi on and fractional scaling off (not set to 200%, entirely turned off), you get all the 1:1 pixel glory. If some app doesn't adjust to dpi, you will see that immediately (basically everything except gtk3+, qt5+ and current firefox/chrome/electron). I actually prefer the blurry one, it makes the apps at least usable.
> If one was less charitable making X apps work slightly shittier serves as motivation for developers to support the new standard.
IMO it is actually too nice anyway. Should have gone XDarwin all the way -- i.e. to run X11, you have to manually launch separate application, and that server does not support hidpi at all.
> If you listen to these people talk the less charitable interpretation sounds entirely plausible.
AFAIK there were multiple approaches tried. Even theone, where whitelisted (i.e. the ones that passed manual test) applications would be allowed to run hidpi and the rest upscaled. It went nowhere.
But as they say, patches welcome.
Smaller changes can be handled with scale and mixed dpi by scaling down from higher res. Note the end result is again not blurry.
You spend 30 seconds setting it up then every works including mixed dpi. In fact one could trivialize this at installation and write configuration to xorg.conf or xorg.conf.d
One in general doesn't need to worry after setup if a particular app will work, if it will be wayland native or xwayland, if it will look different on different DPI displays, if it will be blurry, if all functionality will work.
All high and mixed DPI concerns are front loaded into a tiny amount of time setting it up in a way that will just work well without compromise.
A tiny amount of effort by your distro could easily erase even that by simply doing it for you.
>IMO it is actually too nice anyway. Should have gone XDarwin all the way -- i.e. to run X11, you have to manually launch separate application, and that server does not support hidpi at all.
This is an example of user hostility that goes a long way towards destroying adoption. Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you.
Then you can call them all luddites for caring more about working hardware than plumbing.
I will again repeat myself there: and how does the display server know, if the app won't tell?
> 99% of people are going to need exactly one variable for gtk apps that wouldn't be needed if gtk was just a tad smarter.
Variables do not work in dynamic environment, where hotplug is a thing. Like personal computing in last 25 years or so.
> You spend 30 seconds setting it up then every works including mixed dpi. In fact one could trivialize this at installation and write configuration to xorg.conf or xorg.conf.d
So you are telling here, that:
- there should be a database of apps; ignoring that the display server won't be able to recognize them solely on socket connection and it won't have another info available (no, Xresources is not a solution) - that database would be local system-specific - and it would be static, so if the user hot-plugs some hardware, it won't reflect the current system state anymore - and it would be static at runtime. If you want a change for a running app, you have to restart the app.
Do you see some problems with that?
The problem with this kind of thinking is putting hacks on top of another hacks and then wondering when the mountain goes down.
> This is an example of user hostility that goes a long way towards destroying adoption. Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you.
How exactly did XDarwin destroy adoption of Quartz? If anything, it drove adoption. Instead of trying to hide the shortcomings, it exposed them and offered another solution, without them.
> Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you.
Only those who prefer long pain; those who prefer short pain would do exactly the same.
> Then you can call them all luddites for caring more about working hardware than plumbing.
The entire point is that it does not work. Remember that when someone will complain that the monitor they plugged into their laptop doesn't do the right thing, unlike their Windows or Mac.
In my shell config
set -gx GDK_SCALE 2
xrandr --dpi 163 --output DP-0 --scale 1.75x1.75 --output HDMI-0 --pos 3360x0 --mode 3840x2160 --output DVI-D-0 --pos 7200x0 --scale 1.75x1.75
This isn't automated because I really don't care because like many devices it only actually has one configuration but it would be trivial to do so by computing the exact scale based on difference in DPI. The one thing that can't be determined automatically is the physical layout. There are 17 different GUIs that amount to dragging around iconic representations of your screens. Autoscaling mixed dpi configurations could be a check box checked by default and writing to xconfig could be a button like it is in nvidia-settings.
Other people prefer to simply switch between different named configurations with one of the 17 scripts that have been written to do this.
The gist of why this arrangement needs to app specific configuration for proper behavior per screen is that as far as apps are concerned every monitor has the exact same DPI. Scaling is done by X not the app so if you were to say drag a window from monitor to monitor you would note that the window and its elements remains exactly the same size between monitor not because the app is smart but because X is. This is true enough that you can drag a window halfway between and notice no discontinuity between a line of text across both monitors.
Note that this functionality isn't new nor does it require massive coordination or anything new at all. It has probably worked longer than you've used Linux.
The elephant in the room that you still ignore after several comments in this thread is, that the display manager cannot know magic variables for misc clients, it can barely tell clients apart (and it certainly doesn't know their image names, linked libraries or environment or how they were launched), and it shouldn't know, the clients should tell what resolution they are using so the display manager can adjusts their display. Wayland clients do that, X11 don't.
No, you can't paper over it with some scripts. Suggestions like that always remind me this: https://www.youtube.com/watch?v=ZTdUmlGxVo0
Let me try again. Here is an xrandr invocation that configures 3 screens [1080P 24"][4K 27"][1080p 24"]
xrandr --dpi 163
--output HDMI-0 --mode 1920x1080 --scale 1.75x1.75 --pos 0x0
--output DP-4 --auto --pos 3360x0
--output DP-1 --mode 1680x1050 --scale 1.75x1.75 --pos 7200x0
If one simply runs xrandr after one sees a curious thing. The 1080 monitors are listed as being 3360x1890. If we pop out our calculator we will note that the systems sees every screen as being about 161 DPI. Prove it to yourself if you like.
This means that the most poorly written application on earth only has to contend with high dpi support not mixed DPI. X asks nothing of the client it needs no magic variables nor insight into its linked libraries or images. If you grasp the window metaphorically and move it from screen to screen its size won't perceptively flutter because the screen differential in DPI is as far as its concerned within 1%. If you open a fullscreen app it will draw its window to the whole perceptible 3360 width of the screen and X will scale it down to the actual width of 1920. X has taken sole responsibility for giving a fuck what the difference in DPI is. High DPI support at this point is very good and no scripts to "paper" over anything is required.
xrandr --scale is a thing that would have worked in 2003 and still works in 2022 even if people have forgotten about it.
However...
I am still shocked at the wonder Linux Desktop is. The world has entered into VR/AR, AI, and completely stupifying marvels of engineering but we still haven't gotten the Linux Desktop right. It's a downright fragmented mess. And if that wasn't enough, we had to build another windowing server! Now there's more fragmentation and apps that barely got the funding to work on X or get ported there will never see daylight on Wayland. Yay! Hurrah! We did it! Not to be so condescending but it's truly terrifying how horribly amateurish Linux Desktop is when the underlying system is so amazing.
It's almost like JavaScript developers got together and decided to build the desktop part of Linux. Every week they deprecated/overhauled/threw away last weeks changes and started a new in the name of engineering. The result? Nothing ever works predictably on anything. You open one app in X and the same app on Wayland...and there's no surety it'll work the same way on both. Now open the same app on Gnome and KDE (although that difference has slowly been fixed so it's now much better).
A lot of things don't work in Linux as they are supposed to. You have to tinker the guts out of them sometimes. Sometimes you may even have to recompile. Props to the way Linux is designed that makes all this possible and not locked down but..man it gets annoying sometimes.
I hope one day we'll have some solidity and stability in Linux with everyone building upon an agreed set of foundations so we can actually move forward instead of rebuilding the same wall over and over again.
Strictly speaking, Wayland is just the protocol. Pedantry aside, X11 is from 1987, whereas Apple totally redid their display server in 2001 with OS X, and Microsoft in 2006 with Vista. Wayland brings the Linux desktop kicking and screaming into the 21st century. But bazzar development will always be very different than cathedral development, so inevitably Wayland has its problems and rough edges. X11 being longer in the tooth doesn’t help.
Soon enough all the Linux forums will be filled with workarounds to get X or Y or Z app to work on Wayland or X or something else. The result? Nothing will work as expected for a long time (until everyone has forgotten X).
What is the alternative? Leave linux distros on broken, substandard tech? Sometimes you do just have to break things to make progres. Fedora turned on CGroupsv2 despite Docker not supporting it after years. Very shortly after turning it on and breaking docker, docker updated to support it. It likely never would if no one made the first move to just break things if reasonable time has been given and still no movement occurs.
I don't think it was a bad decision to go the Wayland way at all. But it accumulates because Linux is so fragmented. There's multiple distros, each with their own toolkits, own package managers, own cores etc. And then someone comes along and fragments it at an ever lower level by proposing Wayland. I am sure it fixed a bunch of core issues but look at the cost it will incur:
1. All GUI toolkits will have to support Wayland across the board. Some stuff will break, some stuff will have to be abandoned.
2. After that they'll have to maintain both because it'll take at least a decade or two for everyone to reasonably migrate.
3. The app developers will have to upgrade to this new version of the toolkit. Which they might not be able to do because the changes are too many and too big.
4. The toolkits might even have to backport the Wayland related stuff a few versions. Which would require insane amount of resources.
Is the end result worth it? I bet for a long while we'll be having a way poorer experience due to Wayland. The worst case would be developers ditching X too early when Wayland isn't properly stable. Oh man, it's a recipe for disaster.
This part has been true for years actually. Gnome Shell UI and various other gnome apps are written in javascript now using gjs[1].
1) Wayland isn't X11. Applications whose core purpose is interacting with X11 features (e.g. xrandr, xprop, window managers) won't work on Wayland.
2) Screen recording on Wayland remains an incompletely solved problem, and a lot of applications don't support it yet.
3) Global key capture is, similarly, not a solved problem.
(And by the way, it was only in one of our offer, the most expensive one, and sold as a feature, it was not some shady stuff)
Even for code reviews sometimes it's easier to do it via screensharing with a full IDE for jumping around the code...
So if you were PM, the ball would be on your side.
My general perception of it is that it has many good design decisions from the point of software architecture and security, but they are too cumbersome to add stuff to Wayland that is absolutely needed for desktops. The result is that people end up finding a way to do that stuff anyway in the implementations and the ecosystem becomes a fragmented mess that somehow works worse than legacy Xorg.
The solution is to use Pipewire and DBus to connect to proprietary APIs.
The arguement whether it is the correct location to provide a standardised API is a separate one. But Wayland does not support this.
I don't understand this at all. Can you open a bit more? To my understanding, current screen recording is relying mainly on xdg-desktop-portal and it's variations. It depends on flatpak and glib and uses D-bus. None of these are proprietary to my knowledge.
With these, it supports WebRTC out of the box for browser, and for example OBS studio supports natively, and works really well.
Apps need to implement and use org.freedesktop.portal.* interfaces to support screen recording in Wayland.
Because the APIs that are exposed by Gnome, KDE, and wl-roots are all different. Flatpak has access to the `xdg-desktop-portal.*` namespace, but everyone has their own implementation so saying they use the standard namespace is misleading as it makes it sound like all the work is done.
Pipewire masks all that by implementing everyone's API and then exposing this via the Pipewire API, neatly solving the Wayland limitation and providing a standard.
The original statement was:
> Wayland is not preventing screen sharing or recoring. The API supports it pretty well.
No it does not. Pipewire does.
So there is demand for API. Gnome, KDE, wl-roots implement it, in the discovery phase by their unique way, so we have 3 different APIs. Then, once the requirements are known, standardization happens and every compositor implements the standard API. So far, good.
But what happens with the old, experimental APIs? Because meanwhile, there are apps, that do use them. Remove the old APIs and you will have cries on the Internets, how you break compatibility again (even if you announce deprecation plan years upfront). Do not remove them, and you have complains, that every compositor has its own API (ignoring, that there is a standardized one too, now).
So, there's no pleasing everyone. Someone will complain.
> No it does not. Pipewire does.
xdg-deskop-portal-(gnome|kde|wlr), among other things, which do include desktop-specific dialogs related to the functionality.
That is simply all we are talking about. I don't think the situation that we are in now is terrible, it's just a shame that Wayland ignored it and so it's taken much longer than it should to get it in place.
This is a solved problem, but you are correct that a lot of applications don't support it yet. The solution is Pipewire. OBS works fine, Firefox and Chrome can share windows fine, but there's a lot of software out there that won't be updated overnight.
Paraphrasing Charity, "approved protocols don't matter if the users aren't happy".
I don't expect this to be fixed for another 5-10 years. I used to drag to extract files almost every single day, it's a core use for me. Simply broken now. I get nothing from Wayland, it was a net downside for me.
We, the creators of the new screen thing, are about to break a TON of your old screen things, on purpose.
Now, I'm not saying you can never be that bold -- but if you are, then you need Steve Jobs level effectiveness or you shouldn't do it.
After 3 years someone finally stepped up to do an Xorg release and had to immediately roll back the main new feature because a massive security vulnerability was found.
https://www.phoronix.com/scan.php?page=news_item&px=X.Org-Se...
Given how far away Wayland is from replacing Xorg for many, I wouldn't be surprised if it'll be replaced by something else before getting its time in the limelight. Wouldn't be the first time.
Then again, never underestimate sunk cost I suppose...
In the real world, X has remained as good as, or better than Wayland this whole time. Proven by "people still use it, a LOT."
X’s basic primitives are simply bad for today’s hardware. It was inevitable to fix at some point. OSX changed to Quartz in 2001 I believe and windows quickly followed with their compositor based display manager.
So no, your assumptions doesn’t hold here at all.
The only reasonable solution (nested X servers and XSECURITY are not reasonable solutions) is to switch to Wayland.
Keylogging and screen monitoring is trivial in Windows.
Wayland solves a problem that is present on all systems, but it does it with a sledgehammer.
[Edit] I am reminded that MacOS has a sane model for this.
Same with intercepting all keyboard input IIRC.
Can’t speak to Windows.
Don't ban, just make it a user specific choice.
All the desktops made their own API outside of Wayland and Pipewire standardised a global API wrapper for everyone's implementation.
Whether that's the correct location rather than Wayland is a separate discussion.
(That’s where we can see how a cathedral model could fare better). I think having a simple screen shot api in wayland is a good idea, while letting pipewire properly solve video (and optionally audio) channeling a good technical solution.
The only thing I have said is that Wayland has not, and will not implement an API to their specification. Everyone has implemented their own one due to the lack of directionn and then Pipewire did the presentation API.
It could have been a lot tidier if Wayland had actually accepted that they are the display server and that Pipewire will want an API to capture the display.
Pipewire is the correct output as it captures both audio and visual and can do manipulation of the output as required, but the display server feeds the visual output.
Turns out, you can handle many cases in the linked libraries and if you do not have them, and you cannot change the protocol, touch luck. Sledgehammer time.
People understand that Wayland isn't a drop-in replacement for Xorg, and that's becoming a problem. People want to run desktops that aren't GNOME or Sway, people want to use hardware that isn't AMD-based, and people want to use the software they've always had just like they did before. Wayland doesn't do that, and after 10 years of antagonizing Linux software development, I think it's safe to say it failed.
In that case I think it is safe to say that all the apps I have been using for over a year have been talking to my window server using a failed protocol.
But I really like the experience.
That is not a concern in the world that I or many people live in; the desktop is not expected to provide this type of Web browser-level isolation to protect against adversarial programs running on our machines.
It may in theory be worse than e.g. Windows in this regard, but in practice you can operate a computer in the freedesktop.org tradition with much more confidence compared to running Windows. The traditional packaging and distribution practices and social norms turn out to provide a much better line of defense than whatever technical design is being imported from other contemporary OSes.
Increasingly, it is. Mobile OS's have operated under this assumption since the App Store. Windows and macOS are both strongly moving in this direction. Sandboxed apps are the future, and desktop Linux is behind.
> The traditional packaging and distribution practices and social norms turn out to provide a much better line of defense than whatever technical design is being imported from other contemporary OSes.
No, they don't. The thing you're trying to defend against is not just hostile apps, but someone remotely achieving RCE in one of your network-exposed applications. With X11, any compromised app has keys to the kingdom.
> Increasingly, it is.
You haven't really done anything to show this. And as a point of fact, I'm in much better position to explain the concerns I live with than you are.
Appealing yet again to what other platforms are doing is not an argument. Mac and Windows and Android are doing this. Fine. Granted. Where's your evidence of the actual, practical threat, besides merely gesturing to the (purported) imperative to follow their mitigation strategy? To repeat, this is just not a concern in the world that we're talking about—that other platforms/vendors have taken a different position is not evidence that their position is ipso facto rational and correct.
> The thing you're trying to defend against is not just hostile apps, but someone remotely achieving RCE in one of your network-exposed applications.
I'm not. I'm far more concerned, actually, about the threat from programs and utilities that don't have GUIs, incl. programs that depend on third-party packages of dubious provenance, than I am concerned about the threat of desktop applications reaching across to interfere with each other and violating any (non-existent) expectation of isolation of the sort described here.
EDIT:
But this whole thing means that a normal CLI app also gets to read everything on your screen! It is not only desktop-to-desktop protection, X has no protection whatsoever.
What does a "list of several potential ways your computer could be vulnerable"* have to do, specifically, with my comment? Where is the logical throughline? Do you understand my comment to contain an assertion that my computer is not vulnerable if I were to run an "npm install script adding a few lines to your bashrc"? (It doesn't. That's the entire basis for my remark that I'm far more concerned about things like that than the threat of programs monitoring/faking IO among GUI-based apps.)
* ... which, to be clear, is not what your comment actually contains—it was rather a series of questions in non-sequitur
But there is no difference between a strictly CLI app and a GUI one. Even if you ran everything in a sandbox, under X they could still do every nefarious thing. It would be like sealing one hole of a broken bucket, while water will still leak out on the other ones. Without GUI sandboxing we can’t even start fixing the security question on Linux desktop.
I think you've stumbled upon my point without realizing it...
I find it hard to believe that the security issues with X11 could not be fixed. It might have to be done in a way that causes some incompatibilities and pain, but I can't imagine that would be anywhere near as bad as all the time people have spent working on and dealing with Wayland.
I mean, c'mon, here's a simple X11 "any app can read out the contents of any other window" solution: add access controls to Xorg so that they can't. You open a connection to the X server, and you can read any window created by that connection, and that's it. Input events? You only get the input events destined for windows created on your connection. Want to write a screenshot or screen recording app, or an app that allows sharing your screen? Cool, we can create an interface for that, one that requires user confirmation. Privilege separation is hardly an unsolved problem.
I'm not saying all of this is easy, but it strains credibility to suggest that this could not have been accomplished in the past 12+ years since work started on Wayland.
This exists and is called XSECURITY. It breaks everything, so nobody uses it. Also, nobody thinks Xorg is secure against RCE from hostile clients: the code is just too old and brittle.
This is a valid enough point in isolation, but it seems belied by actual experience. There are really very few desktop-related exploits I can think of reading about, at least since the days of unencrypted X servers on the network. The most recent panic (maybe 10-15 years ago?) was about the default permissions behind ssh protocol forwarding, and even then I don't think anyone famous got hacked by ssh'ing into an untrusted or compromised host.
The simple truth is that getting access to a user's X display on a modern Linux distro requires being able to run arbitrary code as that user, on their system. And let's be real: if you can do that then the game is up anyway. Local root exploits are cheap and pervasive, and there are much more attractive options to an enterprising hacker than trying to spoof a UI.
You can’t record all my keyboard activity. You can’t see my whole desktop. You can’t see other applications’ windows.
Running local code is not game-over.
I know what you're saying. I'm not saying it's false (I was writing Xlib/Xt code professionally in the late 90's on a giant open network where we all had "xhost +" in our startup scripts, trust me I know what you can do). I'm saying the rest of the system sucks even worse. If you have an exploit on a modern linux system and want to install a keylogger, you don't do it with X. You just don't. It's not a realistic hole.
Especially since the first line of defense (don't let attackers run arbitrary binaries of any type) is actually quite strong on modern systems.
That's why seccomp-bpf exists.
Besides, seccomp-bpf and windowing protocol security are orthogonal. Desktop apps must make syscalls, and they must interact with the window server. You need security for both.
I believe wayland does in fact fix this issue. Does anybody have more context on what’s going on?
'Hardware overlay' is an old video acceleration trick to write processed video straight to the output framebuffer. It bypasses the OS windowing system completely and if you as a developer get it wrong in any way you get video peeking through other apps. Video playing via a hardware overlay' has caused such issues for 30 years now. Not just on xorg or Wayland as you'll sometimes see this on windows too.
So it doesn't matter what I am browsing in my personal browser, nobody from the work VM can ever see it.
[0]: Unless you do something "exotic" like pass the GPU through to a particular VM which is not supported and explicitly not recommended for the security reasons that you are thinking about.
... but I was shocked at how much faster and responsive Xorg was, -- and because of it have no interest in switching back to wayland even if the crashing issues are resolved.
- SSR's status seems correct, unimplemented
- Green-recorder is fully archived for 2 years, I mean yes it's technically incompatible with Wayland but that's probably not the main concern there.
- VokoscreenNG added experimental support in 3.1.0 (currently 3.3.0)
- OBS Studio added GA support last summer, the workaround is outdated
So just because the list was revised in April doesn't mean it's up to date with April.
Wayland was definitely pushed too early, a lot of these issues date back to 2016 and tracked through 2020 for example and it was all too soon. This is especially true if you don't use Gnome or KDE. To this day it's also true Wayland still doesn't have full X11 feature parity and I don't think it ever will. What you'll see is more and more of the important ones like screen recording will start to have answers and overall eventually X11 will lack more Wayland features than Wayland lacks X11 features. Mixed rate screens are already an example and fresh things like HDR (not just deep color) may be the big drivers in the coming years. Neither is likely to ever be a true strict subset of the other. Lists like this do a poor job tracking which is actually better for the user because they are focused solely on finding what doesn't work after having had a bad experience instead of tracking what works in each. At the moment this persons workflow would very likely still come out to a preference for X11 but that doesn't change this type of list being a poor way to conclude that.
I know there are people who don’t like Wayland’s design or goals. Same with systemd. But we still hear constant complaining.
The big distros appear to have decided on these as the future. You don’t have to like it, you don’t have to use it. But the other (or older) options aren’t going to get much development.
I’m not sure such posts are very productive this many years in.
(the Wayland people apparently didn't, that's for sure)
But also, I have no obligations to like or respect what they do either. I think they're going the wrong way and I can say so. The freedom works both ways, and I don't think we should shield them from criticism.
basically, ask yourself: is your response friendly and helpful and likely to motivate the developer to consider your issue, or are you venting your frustration. if it's the latter, then please just don't.
see here for example:
https://news.ycombinator.com/item?id=31945618
i made a similar comment a few weeks ago:
https://news.ycombinator.com/item?id=31679373
users should be free to be critical of it
absolutely not. you can say: "unfortunately, i have this problem, so i can't use this, i am going to go use something else". but that's about it.
criticism is the bane of our society. criticism hurts peoples feelings. criticism causes burnout. FOSS maintainers are volunteers and absolutely do not deserve that kind of criticism for just developing software. (that doesn't put them above any criticism. if they are rude or mean to their users, then that may well be criticized. but not if they ignore a problem or are unresponsive. they may well have other things in their life that are more important than to care about your software issue) (and if the developer is paid, direct any criticism at the company, but don't beat up the employee who may not have the freedom to choose what issues to work on)
Being open source doesn't mean nobody should dare criticise you
if you didn't pay for it, it means exactly that.
Now, it's true -- I absolutely have no legal or physical recourse to materially affect them them and because it's open source, I shouldn't. They should never be sued or anything like that.
But you can get out of here with the silly idea that it also shields them from me COMMENTING, even HARSHLY.
Look, I didn't talk about their mama's, I talked about their product.
Your idea that "FOSS developers should be shielded from criticism because they'll stop sharing" is as absurd as "Never boo a musician because THEN THERE WILL BE NO MORE MUSIC."
https://news.ycombinator.com/item?id=31977136 Why criticism lasts longer than praise (bbc.com)
Because I said complaining wasn’t productive?
This far after adoption, I don’t think it is. Fedora isn’t going to see this list and drop Wayland for X. They went to Wayland 7 years ago. I think they’re happy enough, they had plenty of chances to change their mind.
But hyperbolic titles like this one (“Think twice before abandoning Xorg. Wayland breaks everything!”) are unhelpful. HN later changed the title here to something much less inflammatory and more fair.
You know, I was anti-systemd at first, until I started learning more about it and honestly, I kind of like it now. Yes, I fully admit that makes me crazy, but hey the world is upside down anyway so why not join the party? ;-)
> [...] You don’t have to like it, you don’t have to use it. But the other (or older) options aren’t going to get much development.
THIS. THIS THIS THIS! This is why I use Linux! Because with Crapple and Microsnot, I don't have this choice. At least with Linux, I do! Kinda sucks about the other options not being maintained, and I agree that's a problem, but this right here is why I dropped both MacOS and Windows earlier this year for 100% Linux full-time.
And Linux as a desktop has a LONG way to go. But Wayland is a good start.
I, and only I, goddammit, will decide what code runs on MY computer. (Within functional reason; not a lot you can do about binary firmware blobs, realistically, but you get the point.)
Microsoft and Apple rob people of this necessary choice. Such a detriment to personal freedom and security is not acceptable. And if that means I have to endure the X vs. Wayland drama and nonsense, in order to maintain the liberty I should have damn well had from the beginning, well then so be it. I'll take that hit and be better for it.
I know the one missing function, network transparency :)
While systemd was pretty much transparent because it happens around the kernel, Wayland-or-X was regularly in my face.
It seemed like ultimately something in my world was going to snap and break…two things I relied on were going to make a stand on opposite sides of the line in the sand.
And whatever ethical pleasure I might draw from Linux would always be tainted by the consequences of practical smartphone choices.
Ultimately predictability has high value for me and Wayland-or-X was mostly a worry.
YMMV.
The 3 big issues are: I can't screen share, can't screencap, and it flakes out every 1-2 weeks and the session crashes and I need to start over.
Compared to Xorg where my sessions could run for months, basically indefinitely, and screen/window sharing and just worked.
I've been hoping it being in Ubuntu 22.04 would get it the exposure to get this fixed, but I think I'm going to have to switch back to Xorg.
StumpWM is definitely my requirement for using a computer, and it doesn't support Wayland. And yet my laptops and desktop (all of which cost well over $1,500) are pretty wonderfully useful.
They would be close to useless if I did not have a Lisp-extensible tiling window manager to run on them.
It's basically a complaint that X11 software doesn't work on Wayland while conveniently ignoring patches or alternatives to that same software.
This is akin to saying "32 bit x86 is not a 1:1 compatible ARM64 replacement" or "English is not a 1:1 compatible Japanese replacement" or "Writing with your left hand is not a 1:1 compatible right hand replacement". They are different things. Why should they be? Who said they should be? Where was it agreed it should be? I don't see anyone in the Wayland community who actually does work (e.g. maintaining the protocol spec or large projects) saying it should be.
Also, there are either maintained forks for these (e.g. redshift-wayland for redshift) or straight up Wayland alternatives (e.g. wlsunset instead of redshift). The author even links to the Arch Linux wiki page for Redshift which at the top in a purple banner says "Note: Redshift does not support Wayland [1]. See Backlight#Wayland for alternatives." so that's some nice cherry picking to say the least.
So while the claim "Wayland breaks Redshift" is _technically_ true (even though there's a patch) it is heavy implied, I feel, that there is no alternative which is objectively false and misleading.
It's FOSS, go contribute if you are this upset; it's not like you do not have access to the entire protocol specification for Wayland, and the source code for each and every single item listed. This kind of complaint would make sense if it was closed source software where you cannot make changes without extreme effort in reverse engineering and potential legal problems with redistributing those patches. Not the case here.
Since then, the situation has largely pretty much improved, in particular both OBS and Zoom have support for the screen sharing portals.
WTF?
Desktop software isn't sand-boxed. If you're running applications you don't fully trust then you've already lost. Every app you install can access your full filesystem, communicate freely with other things on your network, scan your browser history, steal your cookies, and exfiltrate it finds over the internet.
This has always been a problem in X, actually, since there was never an assumption that everything showing on your display would be running on your local computer.
Now step outside X. whats the client? the xterm. Whats the server? the remote host.
Semantic confusion is real folks. "Display server" only partially fixed it because people never remember to vocalise the qualifyer. And then you get Xterminals as physical devices, with "local" clients and now client-server is really really confusing.
That's the pragmatic explanation I use.
Otherwise, and especially if you think servers are somehow always somewhere out there, you'll get a rude counter example. Server just means provider of service and thats about it. You're tripping up on your own assumption.
This is why you can telnet/ssh to a server out there, set the display variable to point back to your machine and xterm will try and connect to your machine. Its wanting a connection to your display to show things and to do so it needs a display server, ie yours.
That all probably made sense.
You then ssh into a remote server and type "curl https://your-workstation/some-name-here". In this case, your local machine is the server and curl is the client.
This is exactly the same as in the X server case. Your server is running on your machine, and the client is running on the remote machine (which happens to be a server).
That is not the only instance of "well this was technically correct but confusing and now its Enshrined and May never be Touched all Hail Compatibility" or whatever the impulse for wart retention is.
However the whole mess goes to show to me that there is no one true Display System and that there need to be more efforts in this arena, obviously there's still unfilled needs and people feel the compromised currently forced by the available choices are constricting.
OpenGL needs yet another networking extension. That'll fix it.
ssh -X forwards clipboard from remote where you can use something like neovim and clipboard syncs to local desktop.
To work around you need to run local terminal in XWayland mode. Something like that for the native Wayland case would be neat.
I'm not going to boycott Wayland though, it's a pointless idea.
And I keep hearing arguments about how broke X is or was and none much seem to carry water. Lots of loud hypothetical security issues and literally no remotely significant problems that I, a 20+ year Linux user, ever encountered.
Wayland's just a joke to me now.
I swear I can see the difference in anti-aliasing between X and Wayland. Under the latter it just...looks so much better, smoother, CLEANER. Is that all in my head, or has anyone else noticed that too?
I heard it is not possible with wayland, because it doesn't give you the global mouse cursor location.