Wayland is not ready as a 1:1 compatible Xorg replacement just yet
gist.github.com
gist.github.com
This is a common sentiment, but it is kind of funny. Because software engineers working for companies will know the struggle of trying to justify reducing technical debt, improving security practices, etc. but fail to see why these things are useful to them personally when the tables turn.
Wayland indeed “breaks a lot of shit” but it’s not an accident or done due to incompetence. Also, it’s worth noting that since there is not one Wayland server the way there is one Xorg server, that not all of this applies evenly. For example, wlroots-based compositors like Sway do not suffer from the screen recording issues as Sway just supports a permissive screen recording API out of the box. I do think the XDG portal idea is a good idea, though, overall, and that the security improvements will be worth the toil eventually.
But more to the point, that the problem is that moving away from Xorg as a display server really needs to happen eventually. The legacy is holding back desktop Linux quite a lot. Issues like supporting modern high DPI displays or multi-GPU setups are ones that Xorg struggles with that Wayland can be made to handle more elegantly (in case of DPI, already does significantly.) It’s not just that. There’s tons of weird old crufty garbage in Xorg. Clipboard is weird. Drag and drop is weird. Wayland is simpler and makes improvements that are welcome, like a good API for keeping window configuration synchronized to help eliminate “imperfect” frames.
No doubt there are issues. I have some choice words about the decision of GNOME to push for using dbus to communicate cursor size changes on high DPI setups, and I do not like the way client side decorations are favored in Wayland.
This is the only actual, honest, problem that I've ever seen about X. Still, it does not seem a really fundamental problem, it must surely be solvable from within X? Do we really need a full-rewrite of X, unstable, with new bugs and less functionalities? (many of us don't use "desktop" applications and it will break screen capture tools, and other things that are dear to us like xwit, xdotool and the like). Just for that silly mixed-resolution screen problem? I have observed this problem, but to me is a minor, mostly irrelevant nuisance. Losing xwit would be a major problem.
The transition to Wayland is largely finished now. Electron added support last year and eventually the last of the electron apps will update and everything will be done other than nvidia proprietary driver support.
There are so many minor improvements from wayland that are less noticeable like the lack of screen tearing, the possibility of sandboxing apps.
Fedora has has it on by default for about 4 years now and its perfectly usable. I use it every day.
The problem is much more serious than you are explaining. While using X, on my main monitor, UI and text becomes so small I can not even read it or click the icons. I'm not talking about the window size, but the UI and text size. With wayland the app can switch from 200% scale to 100% scale as it crosses the window border. On X you must pick either 100% or 200% and stick with it on all monitors.
Can Wayland handle this? If not, what's it really solving?
Yes.
I really am curious what features you think wayland is lacking. I've been using wayland for years, both using Sway and Gnome, and the thing I've missed the most is xdotool, and perhaps there will be a standardization effort to replicate its functionality securely, but for now it's an understandable omission.
Maybe it's not fair to say that X is broken for mixed-DPI configurations, since I have managed to get it working with X, but it was quite unreliable, whereas on wayland it just works, save for some incompatible electron apps.
X gives you two options: set DPI per displays. The thing is, you cannot drag windows between displays, the app has destroy it, connect to another one and recreate it here. There's even no mechanism to detect multiple displays other that user setting up the DISPLAY env variable.
Or you can do, as the Xorg does: use multiple screens on a single display. Here, the limitation is, that all screens have to have same DPI.
Neither of those are acceptable for modern display server.
> it will break screen capture tools,
It is a good thing that they are broken, because what they do is snooping on windows that do not belong to them. Just like it is unacceptable to integrate user address book to your app by going through its internal files, it is unacceptable to screen grab by snooping windows of other apps. In both scenarios, your app must go through API, which puts the user in the control, whether the app is allowed to do that. Wayland enforces such protocol for screen grabbing and input handling; those app who do not bother... well, the train will leave the station without them.
> other things that are dear to us like xwit, xdotool and the like
Same as previous, but for input handling.
> Just for that silly mixed-resolution screen problem?
No, there are multiple problems. For another, surely you would like screen lock that doesn't flash your desktop on unlock?
> I have observed this problem, but to me is a minor, mostly irrelevant nuisance. Losing xwit would be a major problem.
See even here on HN, it is important for many. Just few days ago there was a discussion under article about i3 and how to drag it into hidpi world in 2021. On the other hand, the mainstream user doesn't even know why they would use xwit, even if they knew it exists.
Don't want to derail this discussion anymore, but this argument is nuts. If you are so concerned that programs that you run can spy on other programs that you run, how do you deal that the fact that all of these running programs have full read-write access to all files on your $HOME?
EDIT: I agree that being able to run selected programs inside a sandbox would be a good thing (maybe even all programs). But attacking the problem of visible display before that of hidden files seems ridiculous. Moreso if it cripples copy paste, screen capture, and similar basic stuff (which to me are just like unix pipes: ways to make programs work together!)
They don't necesarilly do; if you are running flatpak, chances are that they don't.
For example, there is a flatpak for MS Teams. For application like this, you want it to be able to share your screen, but it doesn't have any access to your $HOME (in this specific case, only to ~/Downloads).
More importantly, if you want to tight up your desktop, why do you criticize something that starts attacking it from one angle, that it is not 100% solution? It is not; others are working on the other angles, and then together it will be the 100% solution. In this case, Wayland is only one piece of puzzle, not the entire puzzle.
The limitation is not true. Yes, the core protocol gives you a single, global DPI value. However, who cares about the core protocol? You have XRandR, which gives you a per-screen DPI. Alternative, you could have a freedesktop standard/convention where the DPI is stored as a global property of the root window, in a array of values, one for each display, so that you can override them.
Problem solved! I am actually running Gtk+ slightly patched to support that... trouble is, most of the toolkit is hardcoded to assume a fixed display or even process-wide global DPI, or at least it was when I last looked at it. Dunno what they did for wayland.
I really don't understand why we need to throw away an entire 30 years of software development just because the current property for storing the DPI only has space for 1 value instead of 1 array of values, one per monitor. Just use a new property.
Not so fast!
Are you going to patch it to decade old binaries? How are you going to handle that Wordperfect from 1998? It certainly won't respect you new protocol.
How the compositors are supposed to handle that?
If you are not going to handle it, and just let it behave as it behaves today, you are still not achieving your goal of scaling all clients properly, and kind of throwing away that 30 years of development by making it unusable anyway.
You need to put in some type of kludge which is the reason this article exists in the first place (e.g. copy paste will work randomly).
And if the toolkit is linked dynamically, you are very lucky... Not to mention that a more realistic scenario is that you have to update a 20 year old toolkit to support multiple DPIs, in which case it is much easier if you just have to read the property from a different place rather than having to target a different display protocol entirely. You made the program vendors life easier at the cost of making yours harder...
Even window grabbing will work, albeit only with other Xwayland clients.
No reason your "classic" X11 compositor cannot scale and make any windows blurry, either. No changes required to the client code at all, but some are required to X11 itself, e.g. https://www.youtube.com/watch?v=BrK4c7iFJLs
The point of blurry scaled windows is, that X11 compositors cannot tell which clients are DPI aware and which are not. If you run Chrome, it can render itself properly for HiDPI; if you run Gimp (the Gtk2 one), it won't, it needs to be scaled, Meanwhile, the compositor is none the wiser, which is which, which needs to be scaled and which doesn't. So Xwayland lies to them all about real dpi, and upscales everything.
For Wayland native clients, there is a property that the compositor can take into the account. Theoretically you could make X11 windows property for the same effect, and define new events for display/scale changes, but good luck persuading anyone to use it in the next 10 years ("it works in the current Ubuntu LTS, we are fine, no need to add anything").
Just make a new property, and make those DPI-aware clients set it!
You could even make a small utility program that sets it on _other clients_, e.g. "windows created by these binaries get the DPI-aware property set automatically because I know it". This would be trivial to write in X11, but becomes again Mission Impossible in Wayland (you have to edit every display server -- Gnome's, KDE's, etc. -- in existence).
> For Wayland native clients, there is a property that the compositor can take into the account. Theoretically you could make X11 windows property for the same effect, and define new events for display/scale changes, but good luck persuading anyone to use it in the next 10 years
Yes, exactly. But it is going to be much harder to make anyone support Wayland within the next 10 years, since it brings its own share of problems and because of "the devil you know". E.g. can Firefox already screen grab from Wayland these days? From non-Gnome Wayland? Will Zoom ever do it? And work with any Wayland display server other than Gnome's? It is a mess, and has been so for a decade already. And that is why we get this article.
That's the easy part.
> and make those DPI-aware clients set it!
That's the difficult part. You are welcome to try, though!
> You could even make a small utility program that sets it on _other clients_, e.g. "windows created by these binaries get the DPI-aware property set automatically because I know it".
Yes, another hack to keep on piles on other hack. Why would anyone want nice, clean solution, when a hack does?
> E.g. can Firefox already screen grab from Wayland these days?
Firefox can do screen recording/screen sharing under Wayland these days. Hardware encoding for WebRTC is in the works; that's something they would not be able to efficiently do under X11 at all.
> Will Zoom ever do it?
That's the question for Zoom. If we kick them as Apple does, they will. If we lay down and keep piling hacks on top of other hacks, they won't see the point.
> And work with any Wayland display server other than Gnome's?
That's a question you have to ask the authors of any Wayland display server other than Gnome's.
> It is a mess, and has been so for a decade already. And that is why we get this article.
It is a mess, because some people are too hung up on their current ball of mud and cannot see further than their personal desktop. Then they write articles like this and try to drag down others to the level of their ball of mud.
I am quite confused by the fact that apparently changing toolkits to set a new property (a one liner) is hard, and creating a program to do this change for these toolkits externally without changing them at all is a "hack" (despite the fact users likely want to do this, as evidenced by Windows offering this setting); but on the other hand throwing everything away and changing everything to support an entirely new display server protocol with its on set of problems is ... a nice, clean solution?
What I see is another manifestation of the "backward compatibility is a hack" mentality. Well, this annoys me to no end, but what can I do.
Because if it was just setting a new property in a toolkit, we would not have this discussion now.
Ultimately, it is not just that; if it were, all clients would be Wayland native already as the toolkits have had Wayland backends for years.
As for the "Meanwhile" part, again, how is that better with a new display stack? Unless the point here is that it will be better to just break all those (DPI-aware) clients unconditionally, rather than actually offering them a way forward that does not involve targeting an entirely new display server API.
So "meanwhile" you would have apps that are not DPI aware without flag, DPI aware without flag and DPI aware with flag. And even crappier desktop as you have now for years to come.
The new API is not just for DPI; it is for many reasons, DPI is only one of the issues.
Most issues could probably solved by a variety of hacks. Several issues that don't concern yourself couldn't. The problem is that X consists of 40 years of hacks piled up on each other. THe X.org devs actively chose to stop further development and continue their work on wayland.
You are on the same side as the people bemoaning IPv6 and asking why we couldn't just use one of the unused flags in IPv4 to solve the address depletion issue. It sometimes makes sense to make incompatible changes.
And this is a not true, as evidenced by the fact even software ported from Windows (OBS) does it.
Here, Firefox uses dma-buf. Unless X11 exposes a special extension for exposing dma-buf, your client won't be able to do that.
And in practice, XShm-using OBS actually works better right now than this specific apparently Gnome-only dma-buf API. https://www.youtube.com/watch?v=kD70ur_xTmE
Just because some specific application works better (for some values of better) on the Xshm does not say anything. In year or two, the situation can be very different, permanently.
The same way Apple handles a PowerPC-compiled application from 1998.
By incrementing to a new major version number, and stating in the changelog that users are free to keep running the older version if their software won't be patched.
Does Wayland provide a better solution than that? No, and in addition it also breaks a lot of newer applications. We don't need to do a lot of math to figure out more people would miss Xorg than Wordperfect.
It doesn't handle them at all. There was a transition mechanism, to get users updated, but it wasn't maintained long term. You could not run PowerPC binaries from 1998 in 2005.
Apple expected their users to update the binaries for new architecture in the long term. In many cases, not only ISA and ABI changed, APIs too; good luck if your application used Quickdraw.
(Yes, I still do have coasters in the basement).
So compared to that, Wayland's Xwayland is too nice and too longterm.
I think the difference to xwit is that it does not work across windowmanagers/compositors, because much of what X11 used to do is now the job of the compositor, but I assume the users who script xwit likely also have a very tuned windowmanager, so it's unlike they switch window managers all the time and they could therefore just tune their environment for the same functionality as xwit.
I don't see any screen tearing when moving a window fast across the entire screen either, if that was the concern.
I also could set up large enough font sizes in cinnamon and browsers.
Yeah, to a "better Xorg". The problem is people don't believe Wayland is a "better Xorg".
There are some aspects of X11 that aren’t so bad, especially more recent bits. Personally, I think XI2 is relatively nicely designed. But on the whole, I just don’t think what we want is better Xorg.
belief
People are flaming and screaming about their beliefs, demonizing systemd, Wayland and what-not with FUD, baseless arguments and non-arguments, because they "believe" these things are bad and must die.
If I want to talk about what runs on my workstation as if it was religion, I install Temple OS.
If I want a modern (and basically following sane/safe architecture decisions) display protocol, I run Wayland.
The linked post is just one thing: superfluous. It helps no-one, a waste of energy and time for everyone involved.
Moving to Wayland would force a bunch of changes on me for the sake of no functionality I care about.
That's the big difference. Given it provides no benefits to me that I care about, I won't move until staying on Xorg is more effort than replicating my current setup on Wayland, and as it stands it seems that's likely still years away.
The problem is that many are complaining that _their_ specific set of functionalities is no longer being catered for, or better not being actively developed. The great thing about linux is that you can do what you are doing and continue running Xorg as long as you want, it might be more work however.
Regarding your wayland would force a bunch of changes on you for no functionality, what are those specifically?
I would encourage you to try out wayland, for me moving from i3 to sway has largely been a seamless experience and I (tell myself that) see notable performance improvements for example.
With respect to my time investment, it's down to having to switch window manager. I'm using bspwm, and rely extensively on the API it provides. I could probably transition that to sway if I had to. But I have no incentive to. It gives me no new functionality and solves no problems I'm having.
So I'll stay on Xorg until an incentive appears to justify the fairly significant time cost of reworking my workflows and/or a bspwm compatible compositor arrives (there's been an issue open for 5 years, and at least one - abandoned - attempt).
The time investment required to switch also means I'd be prepared to invest quite a lot in getting Xorg running if the situation is the same down the line at a point where I can't get an "off the shelf" dpkg of Xorg.
At the pace Wayland efforts are moving, I suspect I'll still be on Xorg in 5 years, and wouldn't be surprised if I still was on it in 10.
But really, the main point of my earlier comment was that there are real, concrete reasons for people not to move to Wayland that has nothing to do with belief. It would take time I don't have to make the move, and it doesn't provide me any benefits to justify putting aside other things to invest that time. Maybe one day it will, but it won't be any time soon.
Reducing technical debt by rewriting everything from scratch (almost?) never works. It's the baby and the bathwater. It's the sort of thing that seems attractive to junior developers, but more seasoned folks know that the legacy system contains years of embedded knowledge and workarounds for "real world" issues. The new, conceptually beautiful system always fails to capture that embedded knowledge, and ends up breaking many things in many ways for many people.
Perhaps we did need a new display server, perhaps Wayland is conceptually better than Xorg, but it'll be many years before it reaches feature parity, if it ever does.
I haven't followed the development at all but, Xorg is 16 years old and Wayland is 12. It seems counterintuitive that feature parity could not be attained in this time unless it's for philosophical reasons.
Edit: Thanks for pointing out that Xorg is actually much older. My argument indeed doesn't hold.
Wayland's latest release "mostly contains bug fixes and minor protocol updates." [0]. That is ~12 months worth of changes. Pretty similar to 1.18. It isn't like the protocol is a hotbed of massive changes, it looks largely complete according to the release notes.
[0] https://lists.freedesktop.org/archives/wayland-devel/2021-Ja...
Xorg is a fork of Xfree86, which was released in 1991 (https://en.wikipedia.org/wiki/XFree86).
Xorg is a fork of Xfree86 which started in 1991 but feature parity minus the cruft has been reached years ago. Some people disagree about what is cruft however.
For example, I view 90% of the list in the posted articles to be minor softwares relying on undesirable behaviour and unwilling to adapt (the remaining 10% being misrepresentation of actually solved issues listed in bad faith). The original author would obviously disagree.
Then again, I consider X.org to be and always have been completely unusable. How can people accept to use a display manager with constant screen tearing is beside me.
That's solved by using a compositing window manager such as Compton.
see: https://imgur.com/a/lDfObqw
It's in the advanced settings.
Silky smooth Xorg web browsing and video at no extra compositor cost.
Frankly I have no idea why it's not enabled by default.
I never even noticed it, and I never quite understood what people are on about with this. I had to go to YouTube to watch a demo video to see what it really looks like. And if I try it, then yes, I suppose I see some tearing if I move a window and pay close attention to it. But I never even noticed on my own, and am not bothered by it in the slightest.
Would it be better without it? Sure. But the amount of effort to eliminate what I experience as basically a non-issue is a poor trade-off IMO.
If Gnome, KDE and compton all manage to get compositing wrong on X, and yet every wayland compositor manages to get it right, then maybe it is a problem with X, even if there is some arcane way to fix the issue.
I have been running OpenGL based applications on KDE for some time and the answer to tearing was always disabling the compositor in the desktop settings or just overriding the compositor related redirect state of the window. OpenGL tends to sync against vblank anyway so I don't find it surprising that rendering directly to the final output buffer instead of an off screen buffer that is at the mercy of the compositor helps.
I'm not saying this isn't true, but I always find it interesting when I see people complain about screen tearing.
How often does it actually happen to you, and under which circumstances?
Personally I've been using computers since 1995, (Windows and Linux) and I practically never encounter screen tearing. And this is on a wide variety of hardware. Spread evenly over intel, nvidia, and AMD.
The rare times I did encounter it, was only on one PC with an ancient nvidia graphics card (running Arch linux, bspwm). And it would only ever (if even) happen right before a restart after updating the nvidia drivers.
>> How often does it actually happen to you, and under which circumstances?
It happens every time I Watch a video on X, which is really annoying. It also happens when dragging large windows on my 4k. Wayland is fantastic in this regard.
Scrolling, moving windows, resizing windows, approximately constantly.
I've been enjoying silky smooth Xorg and video for a very, very long time.
If the goal is to have a different display protocol that a significant fraction of the possible user base can’t reasonably use as their root display because it provides yet another way in which “Linux isn’t ready for this to be the year of the desktop”, that’s a perfectly reasonable aim, but it seems like Wayland is targeting replacing X, in which case supporting screen sharing (and recording) is probably not an ignorable “minor feature degradation”.
If not, then Wayland doesn't support screen capture. Individual compositors might, but asking developers to implement five separate screen capture protocols is a big ask.
Is this really a problem for people?
The goal of Wayland is "every frame perfect", which means I consider it broken by design. I want imperfect frames right away, not perfect frames later.
I think very few people involved underestimate the work involved to replace X, and that it is going to be many years before it is somehow done.
The problem was not the protocol, but that the Wayland devs explicitly wanted to throw out a whole lot of functionality people actually depend on without having put thought into replacements.
Many seasoned Xorg developers work on Wayland. All the decades of lessons form Xorg _were_ carried over to Wayland.
There will be some loss of lessons with almost no doubt.
All of them are either working on Wayland or moved on. There are no Xorg developers.
I'm sure many lessons from Xorg were carried over to Wayland, but "all" is an insane exaggeration. And I'm sure many new mistakes were introduced. It's inevitable with any new system.
You make it sound like Wayland has been pushed by some script kiddies, when in fact the lead developers on Wayland are the actual Xorg maintainers.
To me, the migration from X11 to Wayland looks similar to the switch from DOS-based Windows to Windows NT. At the time, lots of programs were broken by the move because they assumed you could meddle in other application's internal memory. But breaking those applications was not malicious intent on the side of the Windows devs. It was a legimitate move towards a more sustainable architecture. I'm not intimately familiar with X11 internals, but my read of the situation is that X11 just exposes too many internals in its interfaces, and therefore it becomes increasingly impossible to adapt it to contemporary needs (in this case, application sandboxing).
Daniel Stone[0] incredibly funny and educational talk[1] from 2013 could help many critics who missed the 3 decade long ongoing discussion of why X is bad. We've talked about this already in the mid 90ies (when there were no alternatives) and now 8 years after this popular linux.conf.au talk, people still having troubles understanding why X has always been a terrible tradeoff for both security and performance (well for literally everything).
[0] https://www.fooishbar.org/about/
[1] The Real Story Behind Wayland and X https://www.youtube.com/watch?v=RIctzAQOe44
edit: BUT X IS THE UNIX WAY! << so what is the 1 thing X does, and what is it doing well?
> so what is the 1 thing X does, and what is it doing well?
It provides functional and well-established(accepted standard) graphics server technology/libraries for any application that uses graphics.
I don't care if it takes 10 liters of blood to compile one version of X or whatever. I'm a user. All I care is that my desktop works as robustly as did it yesterday or 5 years ago. If that's not happening, I'm not interested in macros, classes, variables, declarations, structs, or any other geeky CS technobabble. That's irrelevant. And a product that advertises itself as being created to be convenient for the people developing it is a paradox. Don't develop it, then. Makes things even easier.
-- from https://www.dedoimedo.com/computers/fedora-25-wayland-vs-xor...
Application sandboxing is not a need I have or one that I want my display manager to solve.
But incompatibility vs the architecture disallows features like screen sharing, automation or accessibility means I will not ever have it installed anywhere.
I can't tell people want to do, but those features seem very "contemporary" to me.
Perhaps it's because I use linux as my work desktop. I suppose if this is the feature I should just migrate to OSX.
Because I need video conferencing. I don't need a sandbox. I already am selective about what I install and most of those things aren't even desktop applications.
in X any application can turn into a keylogger, and you don't need a GUI for it, as long as the program can "speak X" it will be able to read the shared memory of all other programs the X server manages.
Not being able to participate in video conferencing and desktop sharing is an employment risk.
Im a picky person though. I already use i3, but also have NVidia gpu's. I don't mind spending some money on another real GPU (will it work with AMD).
I understand the frustration of the developers too. But screen sharing or my custom screenshot tool.. are things that will make me recompile if needed for days before I give up and abandon linux for the desktop.
I realize I'm spoiled, but I do wonder if this is the direction things are going who is going to be that hypothetical user that cares?
It's not just the internals of X11 that are the problem, it's that the entire concept was baked in a different time. The major innovation of the X11 server was that, well, it's a server. It can be completely decoupled from the client, even physically if you use it over tcp. That was kinda nice, but then came GPUs, and direct rendering. The name of the game is now violating every single abstraction that stands between a userland app drawing directly to the display with only a GPU and a single graphics api in between. It was definitely not junior developers who rewrote the entire kernel graphics stack to move from frame buffers to direct rendering.
Computer graphics are pretty tough if you think about how many bits/s are being transferred to your 4k display at 60hz and how little latency we will tolerate. It's not like network data where we can afford to encapsulate it five times over and abstract it and forget about the contents.
Any criticism of Wayland should be with regard to what is next. Hell I'm not even convinced we need a display server, let's talk about that. I'm not going to take anyone seriously who says X11 is better, and because of a few insignificant issues like taking a damn screen cap (really? and that works fine now btw).
Take for example, Mac OS 9 -> 10. Complete rewrite. One of the best decisions in computing history. And especially relevant here because the display server was one of the babies they threw out the window or whatever, and the quartz compositor was born.
Rewrites don't work when the following two statements are both true:
- the rewrite should achieve feature parity at a higher generaly quality
- the people who're doing the rewrite don't have most or all the knowledge that people working on the legacy system had (this could be written docs, automated tests, or just actual people hanging around)
The lesson here is that writing a direct replacement system rarely succeeds because the new system will hardly be able to implement all the features in a reasonable time. Instead you should take a step back and develop a completely new system that follows actual user requirements and gets rid of all the dead code.
I'm afraid that's where the Linux desktop is today. Linux as a platform actually sucks for running "untrusted" software. And "untrusted" doesn't just mean proprietary games. It also just means "can I please run the alpha version of this cool open source project without being afraid that it'll fuck up my whole home directory?"
Android does a hacky thing where each program is its own "user". But then, having multiple (human) users is confusing (I don't know how Android does this, actually).
I don't know if Wayland will succeed. In fact, I'm rather pessimistic about it. But I'm also pessimistic about desktop Linux "succeeding" (staying reasonably useful even to nerds) if Wayland doesn't.
And for the sandboxing it uses SELinux which is available on desktop as well. It's just a royal PITA to configure. This is why many people don't bother with it. But in a highly restricted environment like a smartphone it's a lot easier.
I wouldn't call that a 'hacky' thing, it's just using it in a very different environment.
The point was intended to be that Linux is becoming more and more lacking as a personal computing platform, relative to the gains elsewhere in the space. The display server is one part of that- the entire user/group permission model is another part.
The part of Android that is "hacky" is using a separate user for every app. That's obviously not what the Linux/Unix guys had in mind for the user mechanism, thus it's a "hack". It's not necessarily a bad thing and it's totally hidden from the UX of your typical Android user, so it's fine. Just interesting.
I used to think that, and then I started using Fedora. They have put a lot of effort into their SeLinux policies. I do all sorts of things with my workstation and very rarely have to care. In the last 6 months the only thing I have had to do is add ":z" to a bind mount running a podman container so that labelling happened correctly.
Maybe we've worked on different projects, but sometimes the legacy is just that things were done differently in the past, and the APIs available were crap.
The Wayland developers are the same people who have been building all these workarounds for xorg for decades. This isn't a new thing coming out of nowhere. When the old guard is telling you that their own work needs to be replaced, I'd listen.
>Perhaps we did need a new display server, perhaps Wayland is conceptually better than Xorg, but it'll be many years before it reaches feature parity, if it ever does.
Good thing nobody forces you to use it and it's just one click away on the login screen from switching to xorg. In the meantime people who want to hack on the project can do so and ship their changes to users to test them plus those who do suffer from xorg issues( because yes, xorg doesn't do well on a lot of things that aren't even that modern despite all the workarounds for the "real world" issues it has) can use wayland right away.
Agreed but this is one of those "almost" exceptions.
1. Is the code built to 40+ year old requirements, many of which are irrelevant today?
2. Is it hard to make it work for today's requirements without widespread fundamental changes?
3. Is the code a huge pile of foo that's damn near impossible to navigate, much less understand, much less debug?
4. Would a hypothetical program that solved today's requirements (with an architecture where the most important backwards compatibility features could be hooked in as needed) be smaller, simpler, and easier to maintain by newcomers?
If the answer to all of the above is "hell yes!", you might want to think about a wholesale rewrite.
Problem is, ever so often what should reduce technical debt ends up also reducing "technical assets" even more.
Firefox is a perfect example of this, they reduced technical debt by selling of so many features that it was sometimes hard to see a single unique selling point except not being owned by what I think is the worlds largest data miner (and quitter)!
For someone who used to use and advocate Firefox this hurts.
What is left is certainly better than Chrome on a number of points (except being bug compatible with Chrome) but the differences are now so small on every point except "not being owned by Google" that they are hardly visible to non tech folks.
Edits: a bunch above, mostly to soften and clarify. Also:
IMO the current management at Mozilla inherited a fortune of goodwill, a best in class web browser and significant tech debt.
They supposedly traded goodwill and features for reduction in tech debt but a few years later I suspect they squandered most of it on coolness because if there was less tech debt now, some of the old features should now be trivial to add back.
Ublock origin and treestyle tabs alone make a compelling case and are visually and functionally distinctive.
I get why they did it though, allowing extensions to effectively take over the browser sounds like a recipe for disaster. Too bad there isn't a way to opt into it when it's actually what you want.
It actuall feels snappier than the latest Firefox, but a profile reset on my main Firefox might change that (traditionally with my usage patterns there's little improvement to be seen from that.)
So for now the advantages of Firefox vs Chrome are:
- not Google
- less RAM usage
- slightly better extensions
And for Palemoon vs Firefox:
Pro Palemoon:
- snappier (?)
- extensions work
- looks better (subjective) and can be skinned
Advantages Firefox:
- more secure (maybe, Palemoon unlike Mozilla doesn't have a history of abusing extension bundling for various promos)
Your browser is your number one vulnerability and you have selected poorly.
https://www.howtogeek.com/335712/update-why-you-shouldnt-use...
Note that I write "experimenting with".
I'm fairly aware that my browser is the main vulnerability, thank you, which is why I run different (mainstream) browsers for different sites already and actually want even more lock down for certain use cases than what IT currently privides.
I'll also add that in the last 20 years I've had one infection on a machine that I alone used (a drive by exploit in a banner ad on a developer blog I read) so a combination of carefulness/paranoia certainly helps ;-)
And no, I'm not suggesting anyone should uncritically download a random browser and start exploring the dark corners of the web.
Also: I agree, the robot thing was harmless, but that said: do you remember Superfish? The little thing that Lenovo added to their laptops? Which turned out to be a giant easily exploitable hole?
As for the robot extension:
- when I noticed it in between my own extensions it scared me quite badly until I managed to look it up
- companies that does such things aren't trustworthy. The robot thing was harmless. Superfish wasn't. Do you trust marketing executives to know the difference?
https://github.com/jasperla/openbsd-wip/issues/86
If you run it you are choosing poorly
In fact I asked yesterday and it was an interesting experience: https://bugzilla.mozilla.org/show_bug.cgi?id=1332447#c170
For all the talk about UX, why cannot someone be bothered to sit down and talk to the actual people who use the product and ask what the ux problems are?
At this point is there anyone left using Firefox except stubborn power users like me?
Another similarity I see is that Xorg is like the Linux Kernel of GUI applications. Ideally, you just shouldn't break "userspace".
I agree that some stuff is definitely broken in Xorg, like High DPI setups. But I also believe that's no reason to break a myriad other setups that are working well, right now.
This constant "1 step forward, 2 steps back" (from the point of view of the final consumers, who really only care about the result, and not the means) is so common in the ecosystem of GNU/Linux based O.S. It's also why I see the mantra of the Linux kernel so utterly fascinating and inspiring. It takes real work to build something and keep it working for decades with a minimum of breakage; starting from scratch looks then like child's play in comparison.
I guess the problem is the same as always: money. In a parallel universe where Xorg is at the base of Windows, Microsoft would just throw millions at it to improve the architecture and fix issues, while at the same time trying to limit breaking changes as much as possible... but that requires willingness to do it, and deep pockets.
This post is a bit too ranty for its own good, but it has a valid point, and one that is unfortunately common in the open source community: because you have no monetary obligation to your "customers" (=users), there's not really a lot that forces you to maintain backwards compatibility. And because a Linux distro is made up of thousands of applications, many of them not in active development anymore, changing such a fundamental component (without providing a "compatibility layer", which I have no idea if it would be even possible) will break a lot of applications that may never be "fixed".
Nvidia is the major blocker here and there is very little wayland devs can do to fix this. Fedora has actively discouraged using the proprietary nvidia driver for a while now and they ship wayland by default since the open source driver works fine. I saw that ubuntu is also shipping wayland by default soon for amd and intel users.
Just interested if it works OK.
For graphics I'd like to switch to AMD, but right now you just can't buy their higher end consumer cards.
In this case I already have a 2080Ti, which gives my previous comment context. If I was starting from scratch then, well, I'd be stuffed either way :)
I know, but it can be difficult to understand. I mean, how come we currently have Nvidia drivers for Linux, which work pretty well, and they can't be used for Wayland?
And yet, distros like Ubuntu are too conservative, because they are too careful not to break something. Their signalling is then considered as it works, we don't have to fix anything, Ubuntu will keep things broken for us. Due to this attitude, they have slowed down Linux desktop by years, by not switching to Wayland by default in the past LTS release.
Compare with Apple: in the same timeframe they've deprecated and removed support for entire architecture (i386) while Ubuntu just thinks about doing one step. Apple breaks compatibility at much faster rate than Linux world, and everyone is fine with it. The difference is in signaling: Apple decides and does. In Linux world, we have articles like these, that try to slow down everyone.
eg. for years you couldn't resize a window from the left edge and everybody was "fine" with it. When they actually bothered to implement it, it was astounding to think you couldn't do it before!
As for me, I await each Apple release with trepidation and fear.
Will my audio hardware continue to work? (They break the utilities most releases).
Will I need to buy a new version of Parallels or VMWare because Apple changed the virtualisation API? (This happened a few years ago).
Will my apps no longer work? (Goodbye useful 32 bit apps that I can't find a 64 bit version of).
Will they just break random things? eg. PDF viewing, Quickview of multiple files (both of these happened to me).
Will they change random things for the sake of it? eg. Giant spacing between icons on the menubar on Big Sur. Behaviour of the maximise button into "full screen" button just because they could (a few releases ago).
Will my machine be slower for no apparent reason? HFS+ to APFS makes my machine start up TWICE AS SLOW.
The best bits are due to the Objective-C message passing, old apps will make a "call" to a function that no longer exists and it won't break - it'll just do nothing. You literally have no idea if your app will continue to work between releases, even if it runs and the certificate for the app hasn't expired...
And I say this as a daily user of macos! It just isn't reliable between releases.
It got really tiresome rebuilding my dev environments in particular with every new release. Butterfly keyboard, touch bar, and other hardware choices were additional hindrances. Infuriating design choices like doing away with 'Save As' were the last straw. I don't really care about UI improvements, to be honest. OSX Leopard was usable for everything I do in normal life.
I remember Snow Leopard being a deep joy to use.
How can you complain about Ubuntu LTS keeping Xorg as default in an LTS when RedHat itself had Xorg as default at that time. Isn't this hypocrisy or irony? (same thing of idiots complaining about upstart being shit while RedHat and Goole were still using and supporting it.
IMO let RH use Wayland as default for a few years , then hopefully they can't ignore user bugs and fix them.
RHEL8 uses Wayland as default. RHEL8 was released in May 2019. Ubuntu LTS was released in April 2020. What hypocrisy you are talking about?
> (same thing of idiots complaining about upstart being shit while RedHat and Goole were still using and supporting it.
Redhat uses systemd since RHEL7; Upstart was used in RHEL6.
Story time: Redhat management didn't see the point of systemd originally; Poettering did it in his spare time, and Redhat management has seen the point only after Fedora and Arch adopted it. Meanwhile, RHEL6 was already deep into its release cycle.
But they didn't and the long-term consequences of delaying it will be felt across all linux distributions for years to come. So much for appeasing RH and it's fanbase.
I also think NVIDIA had a role in this default display issue, Ubuntu has to use something that actually works on all hardware combinations,competent users can install and try a Wayland implementation or all of them.
The forced PA brought some pain. but it forced swift improvement in audio drivers. Without it, we would still have half-buggy drivers that do not really work.
Regarding Nvidia: all distributions that switched to Wayland default switched that only for supported hardware, so Nvidia users are still getting X11. I don't expect Ubuntu doing it differently.
I understand that when you work on your free time you want to work on shiny stuff that maybe you created and not on someone else old code, but for good results we see all the time that serious money need to be spend and developers need to be made to work on users feedback and not on what they like. Red Hat is pushing this, they have the money so they need to find more competent developers and do it right.
Of course not. Casual users having no issue with X is a lie.
The fact is, that some subsytems on Linux are pile of hacks piled upon something built on assumptions that are no longer true. X11 is one of such subsystems. It is a dead end. When you are stuck in the dead end, you can either back up and once you are out, continue in your ride, or keep being stuck in the dead end.
Wayland is backing out of the dead end; yes, it is short-term, high intensity pain, when you are not going forward, and even have to go back for a while. Piling new hacks on top of X11 is trying how to continue going forward without backing out of that dead-end. You will be stuck in that place for a long time, and ultimately you will move nowhere. That is long-term, low-intensity pain. Some people do not take the long term view (or do want to avoid high-intensity pain), being stuck in a place works for them (and chronic low-intensity pain is fine to them).
These two approaches still clash, it is this https://www.youtube.com/watch?v=ZTdUmlGxVo0, all over again, 10 years later.
If RH were actually competent would have had a roadmap and Xorg would be replaced with some Wayland implementation only when all X featues are ready. Until then RH can label it as Beta.
I don't like how you propose this unfinished stuff is pushed on users so maybe someone would get frustrated enough and make RH job, like WTF RH has tons of money, they could fins competent people to implement the missing stuff 10 years ago, and while at it they could have fucking fixed GTK or maybe buy Qt and the dev team .
That's news to me. I have yet to read or hear the sentence "removal of magsafe was a great idea", or "I love carrying around this bag of $50 USB-C adapters". Or "this touchbar sure is a gamechanger, who needs the F-row on a Pro device anyway".
> Apple decides and does.
And Linux decides not to break everything just because they got a new favorite technology. I am not sure why you complain so much about Ubuntu when you can just use another distro that does things differently. Because unlike with Apple, you actually can choose, and without buying new hardware.
Which is also the reason I'm not that invested in the whole Xorg vs. Wayland debate; I am certain one distro or another will still support Xorg for a long time, and who knows, maybe one day Wayland is actually mature enough for me to use out of the box.
I'm not talking about hardware. I'm talking about software. How they changed the network filtering several times in last 5 years. How they deprecated and removed i386 support during the same timeframe that Ubuntu only considers switching to Wayland. Heck, my ~2015 Samsung MFP in office doesn't scan with MacOS anymore, apparently the latest driver from September 2020 is too old now. And bazillion other examples, see them in sibling thread.
> I am not sure why you complain so much about Ubuntu when you can just use another distro that does things differently.
I do use another distro that does things differently. To problem with Ubuntu is, that application developers do target Ubuntu, not those another distros. So when Ubuntu doesn't need Wayland (or Pipewire, or whatever), they won't allocate manpower for Wayland (or Pipewire, or whatever) support.
Then we get stuff like "Wayland is still broken after 10 years".
> I'am certain one distro or another will still support Xorg for a long time,
That's certainly fine
> and who knows, maybe one day Wayland is actually mature enough for me to use out of the box.
In order to mature, it has to be used by critically-sized amount of users. If you just push it aside, it will stay aside. It is not just Wayland's problem, for another example see ARM support under Windows.
It has plenty of momentum. The two main desktop environments have wayland ports. Several distros ship wayland by default.
without providing a compatibility layer
Wayland does provide a compatibility layer, XWayland, which runs an X server that does all the internal processing that Xorg does, and then send the final frame to wayland to put on the screen. It works very well, just with some quirks around mixed-DPI setups, which X can't handle well to begin with.
When people complain about wayland breaking their set-ups, they're talking about tools like xdotool, which Wayland deliberately does not allow because they're security risks. Old applications, the kind that put a window on the screen, rather than manipulating other applications' windows, work just fine.
The gnome global menu thing is a problem with gnome's implementation of wayland. The functionality could surely work if Gnome decided to support the same standard as wlroots does for allowing custom panels like waybar. Perhaps the complaint is that wayland give the gnome despots too much power, but if you don't like gnome, then complain about gnome, not wayland.
I don't know enough about KDE or AppImage to comment on those complaints.
Do they have a common screen capture and automation API yet?
Automation no https://news.ycombinator.com/item?id=26000740
Though I would say that standardization of screen capture is far more important than standardization of automation, since screen capture software needs to work for all compositors, but my automation scripts only need to work on the compositor I actually use.
While Linux community can pat themselves on the back for having Linux kernel as part of ChromeOS and Android, they tend to forget it is hardly exposed to userspace frameworks used by app developers.
ChromeOS vNext could be based on Fuchsia and still offer Crostini.
I mean to be fair now that Wayland and PipeWire are there it's finally starting to look like a modern OS.
The rest of the new desktop apps are electron which doesn't care about X vs Wayland
Besides, tablets and laptops are desktops as well, specially when parked on a docking station.
And the issues in X that wayland aims to fix are much bigger than the issues that python2 had when it got replaced.
The same is true for moving away from win32 GUI API. How many times has Microsoft tried?
I have experimented with wayland and considered submitting patches for various 30-bit color issues, but the community is so catty. Everything is met with snark. It reminds me so much of trying to help a damaged person who doesn’t trust me, which is so weird and off-putting, in this context.
I'm not very familiar with this example, but experience from proprietary systems rarely applies to FOSS because the way free software is developed is so different. Furthermore, Qt and GTK apps work out of the box with both wayland and X. The same applies to many other toolkits and libraries.
> I have experimented with wayland and considered submitting patches for various 30-bit color issues, but the community is so catty. Everything is met with snark.
What part of the ecosystem did you attempt to contribute to? I got a couple of patches merged into Sway and some of its utilities and the community always felt rather welcoming.
I am expecting someone would comment that browsers are a good example, and my answer is go check the contenteditable and for example how text selection works and all the issues people had creating a rich text editor that works on all browsers using it.
I agree the selection is sometimes handy, but I've accidentally hit the middle button where I didn't mean to just enough times that I'm ready to give it up. I rarely use them to hold two different things.
This is what killed XMPP and it's likely to kill Wayland too.
(It is very similar to systemd, and the motto on page https://nosystemd.org/ that is what I think about systemd also: If this is the solution, I want my problem back.)
If one doesn't use multi-GPU setups or high DPI they don't need Wayland, yet (later they will either have no options (like with systemd) or will buy better screens).
For me e.g. I don't know if I have a problem that Wayland may solve - I have not issues with Xorg, I don't like using more than one screen (I forces me to move my head left-right, I prefer single large screen, with full sized window) and I don't have high-dpi screen (I think, at what DPI does it start? My laptop has full-hd with 14", so probably not).
But later when such high-dpi screens will be the norm it would be nice to use them.
But I'd rather have it be replaced by something that's like X but supports higher resolution then (4K works for me with X though, no issues), rather than with something that doesn't allow screenshots, xdotool automation, clipboard, ... in the name of "security".
Wayland seems like a move to take away control from the user to me.
Hopefully you are not referring to the fact that there are two clipboards in X, because I really like that "weirdness", and I'm really used to it.
Indeed, it's funny they would think it was meant to solve issues they had. The justification for it was never X11 doesn't work. It was always "it's becoming impossible to work on".
As it happens, Wayland does solve a problem I have. The HDMI port doesn't work under X11 on my Lenovo X1 2nd gen laptop. It does under Wayland. Granted, that's because no one wants to work on X11 any more, so new or unusual stuff doesn't get added. (The X1 gen2 is indeed unusual: the HDMI port comes off the Nvidia card rather than the intergrated graphics. The X1 gen3 fixes that nit.)
Which brings us the full circle: Wayland may fix no issues he has now, but the X11 code base being so much of a pig will mean he has issues with it in the future.
I've now moved to Wayland, and it was under sufferance. It's forced me to use Gnome3. The Gnome3 taskbar and I are not compatible ("what a complete waste of space" springs to mind), so I'm not that happy about it. Debian's alternatives system for selecting a Window Manager (now the compositor under Wayland) seems to be completely broken.
But Wayland itself: a few paper cuts, touchpads not working after suspend and things like that - nothing serious. But my god it's fast, and amazingly remote X11 connections (ie, "ssh -X") still just work. And the code base is much smaller.
People are comparing Wayland to systemd, to me it's not at all like systemd. Systemd was more complex, in lines of code literally 100's of times larger than then things it replaced, and never delivered on it's speed promises, and seeks to replace everything with Systemd. On all those metrics, Wayland is the reverse - it even encourages mutiple implementations.
"It has to happen because it has to happen" is classic logical fallacy anti pattern.
I am picking up on this from writing app that cares about the currently focused app and with x11 that is easy to deal with. Wayland explicitly denies it from happening, only the DE can give me that information and I have to work out how to work with all of them individually if I want to retain parity. There are definite cons to that as it limits the DEs that I can support vs having the capability retained in Wayland.
X11 had horrible tearing on external rotated screens - Wayland fixed that.
Colour temperature changing works.
Screensharing works just fine on Chrome and Firefox. I use it every day.
Screen recording works with Gnome's built in recorder.
I'm sure there are a few esoteric bits which don't work - but I've had nothing but success with it.
Did you manage to setup more than 1 monitor to run on various (an sometimes very different) dpi settings?
On the other hand, the reason I switched to Wayland was that I wasn't able to get multiple monitors with different pixel densities working in Xorg. That works fine in Wayland, and since one of my monitors was unusable without being able to choose different pixel densities for each monitor, Wayland it is.
If it matters, I'm using Pop OS on a System76 Thelio.
I have set up fractional scaling of different fractions on all three of my screens. No issues on Wayland.
When electron 12 is released and slack will be build using it, it will be possible to use slack as a native wayland application and then screensharing should work.
That never worked under X11 either so not a problem with wayland, just it would be nice to find a solution.
I'm using Ubuntu 20.04 on an XPS13 and can finally have different scaling factors between the internal HiDPI screen and external normal DPI screen without awful issues.
Some monitors also have unusual dpi where they are HiPDI but don't suit 2x UI scaling. A very popular LG USB-C 4K monitor is in that camp.
√(3840²+2160²)÷275 ≅ 16
For the external monitor to have the same dpi as the laptop, it would need to be a 16K resolution monitor.
I _am_ disappointed in that fractional scaling is not first-class :(
I have screens with different DPI attached to my linux machine running X/nvidia. A bit of futzing around with xrandr had it sorted.
Firefox is quite buggy on Wayland, you need to set up some environment flags before launching it, and there's a trove of bugs still open for it.
https://bugzilla.mozilla.org/show_bug.cgi?id=635134
> I'm sure there are a few esoteric bits which don't work
Like cut and paste between different kind of applications, which is an horrible user experience tbh.
You will probably also want to force enable webrender (gfx.webrender.all = true in about:config), which still isn't on by default apparently.
I've used this for more than a year on Sway. Recently I had some issues with addon dialogues , but mostly it's been running just fine and with best in class performance, very noticeably faster than Chrome.
With the environment flag, it works pretty well.
On Gnome, plugins can cause issues. hidetopbar, for example, had an issue with Firefox when the screens are stacked vertically.
The main thing that annoys me with firefox is drop-down menus don't respond to clicks properly so I'm forced to use the arrow keys.
Is it? I moved to Sway (a Wayland WM) a few months ago, and run FF exclusively. Hell, I even run Firefox ESR (as provided by Debian), and I've noticed precisely one bug, and it's tiny: the main FF hamburger menu has a vertical scrollbar even if it's got plenty of vertical space left on the screen. Whatever, I use that menu once in a blue moon. Everything else is perfect!
What are you experiencing?
> you need to set up some environment flags before launching it
A single flag! Come on, this is hardly a problem.
> and there's a trove of bugs still open for it.
There's a trove of bugs open for FF in general ;-)
> Like cut and paste between different kind of applications, which is an horrible user experience tbh.
What do you mean? It works fine for me. From FF to other Wayland windows, from other Wayland windows to FF, and to and from Xwayland windows. The only copy/paste behavioral difference I've noticed on Wayland is that I lose the copied data if I close the source program. So when copying from FF, I can't close FF (as a whole, not talking about the window in question) before I've pasted. I can't see that this is an actual problem.
This is because sway by default does not provide a "clipboard manager" component. It has been the case for a long time that the clipboard is only actually populated when you paste, copying merely stores a reference. This is so you can copy/paste multi gigabyte files without running out of memory. A clipboard manager component solves this issue by intelligently saving your clipboard as applications come and go.
Honest question: Is this something that people are missing in Wayland?
okay, but what if I don't like gnome ? e.g. I had to record a screencap of a bug of a software (that, uh, occurs only under wayland) so I went under weston and, well apparently there is also a screen capture tool but it is incompatible. On X11 I use simplescreenrecorder no matter the desktop (I mostly use i3wm or KDE Plasma depending on the circumstances).
Also what's the way to set a different keymap, that would work for any wayland compositor ? `setxkbmap` used to work but doesn't anymore and this is fairly frustrating and I really really don't want to have to learn one command per compositor.
Moving windows (or even the mouse cursor) also feels absolutely sluggish on wayland, like the frame rate is halved.
X11 / i3 : https://streamable.com/fo8ixw
weston-eglstream : https://streamable.com/wmp6vy
Also switching in/out from a wayland tty apparently gets it stuck here.
etc etc... it's just painful from start to end
Under X11, the screen capture and recording doesn't work when one of my screen is scaled and rotated. The capture will turn entirely black, even when capturing on my other screens. If I want to capture something, I need to unplug that monitor (or change my xrandr settings to put it back to horizontal).
Works just fine under Wayland with Sway.
Improvements in X11 break software all the time too. It's not a wayland thing.
So it took a while for screen capture to work on Wayland. I agree that it was questionable for distros like Fedora to move to Wayland before such a critical feature was working, but now it works.
Because Wayland is a protocol with no canonical implementation, it is going to take a bit of time for all compositors to implement the new standard for screen capture. But gnome has implemented it, so has wlroots, and I assume KDE has or soon will. Weston is a toy compositor, not intended for serious use, so it's not surprising if it lags behind.
And so it on X11.
Yes, Xorg is now legacy, outdated, insecure, and does too much. But what wayland did was to replaced one functionality of Xorg, without offering alternatives to other functionalities. Which is good, I guess, it has a clear and focused responsibility.
But now compositors are responsible for other functionalities and they seem to be doing things in their own way. Which is also good, I guess, they explore the design space and then they can gravitate to a standardized way of doing things later.
But it's more than a decade now, many things seem to be stuck in the "exploring design space" phase, so it's understandable if some users are impatient. Yes, it's free software without warranties, it doesn't mean immunity from criticism though.
I also get performance regressions in wine games on xwayland, didn't try wine-wayland yet though. But many games I play will never move from X.
Also I believe the problem is not Wayland. It's the lack of other standard protocols on top of it that are required for application developers to not chase ad-hoc, desktop environment dependent protocols for basic needs like screen sharing. The issues are probably political rather than technical, and the solution is coordination between the desktop environment implementers to use the same standards and provide common interfaces for application developers.
Red Hat blogger marketing budget.
Statistics say nvidia has around 20% global marketshare and for gamers it's up to 80%. My guesstimate is developers are somewhere in the middle there so you are looking at 50% of all developers that can't use wayland themselves. How is that ever going to make the compositor ecosystem catch up.
Luckily Nvidia announced support earlier this month so hopefully this stalemate will soon end. https://news.ycombinator.com/item?id=26004651
Autokey uses Xorg APIs for key handling. Of course this is not going to work on Wayland since it's written for Xorg and not for Wayland.
The author is probably the type of person that buys an AMD graphics card, and then complains that AMD "breaks" software that's based on CUDA...
Heck, you can even go a layer lower and simulate a keyboard event device, which would work with any window system, past, present and future. Even kmscon.
Do you know if there's any standardization effort to support xdotool-like functionality over wayland with some kind of actual security model (using ydotool kind of subverts the security improvements wayland offers unless one does more due diligence than is pleasant to do for quick scripts)
It is just like the web. By default websites don't get to access your camera, but that doesn't mean that camera access is impossible. They just added a way to request camera access with user permission.
However as far as I am aware there is no proper key-capture or key-inserting API in Wayland. There are hacks (IMHO) like bypassing the compositor and reading the events directly but we are still missing a well-defined API that is supported cross-compositor.
I am fine with GNOMEs very limited keyboard shortcut support but I definitely agree that this is a step down from what we had on X.
Stopped reading at this gem from the OP a long way down:
> For all the Wayland proponents here, why argue in places like this, wouldn't it be a better use of your time to send PRs to fix things like MaartenBaert/ssr#431 and vkohaupt/vokoscreenNG#51.
Time perhaps to invoke Teddy Roosevelt:
"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat."
Hats off to the Wayland devs. We're cheering you from the sidelines.
Its pretty horrible how much toxic crap gets directed at the people who actually do all of the work. Just look at the amount of abuse has been flung at the SystemD developers from people who largely do not even know what it does.
It’s like the System D shills - they are HYPER obnoxious. I don’t need software made inside IBM, and I don’t need software which apparently can only gain adoption by obnoxious bullying.
It’s too late for Wayland, much like it’s too late for System D. The hyper childish bullshit chased me, and many others, away.
Now when the standard gets rolled out kludge will be developed to allow users to still take screenshots. The beauty of the standard will be compromised or everyone will spend a bunch of time pretending the kludge isn't de-facto part of the standard.
Wayland's model of user security was a mistake if the goal was getting typical users to use it. It isn't secure, it just means screenshots will be done with a kludge. I think literally everyone I know who owns a computing device (I'm counting phones and tablets) wants to be able to take screen captures to show people things.
https://docs.flatpak.org/en/latest/portal-api-reference.html...
There are still apps using legacy gnome/kde specific APIs, but, from what I understand, in the future Flatpak APIs are becoming the defacto standard
On the one hand this means you can support both X11 and Wayland with a single API from a client perspective, on the other you have to use DBus, which is horrendous to use (especially from statically typed languages).
It also doesn't seem to work on my XFCE/X11 desktop, which shows what fragmentation we have now.
Could you explain this? In my experience DBus provides you with a schema, the exposed DBus interface describes the callable methods, their arguments and types, readable properties, and signals.
Just like with SQL it's useful to create a layer that takes advantage of the statically typed powers of the language.
Usually there are tools that use introspection (or the XML introspection data) to generate "types" (ie. this layer).
Gnome people push for everything Dbus, and many Wayland dev prefer to standardize over Wayland protocol.
It's kinda sad that the APIs are fragmented over two IPC solutions (unlike for eg on Android where everything goes through Binder IPC).
I think the overall the idea is : if it requires permission/sandbox -> Dbus, otherwise Wayland . But in practice there is a lot of disagreements.
Context: https://wayland.emersion.fr/grim/
Here's my key binding config from sway:
bindsym print exec filename=$(date +'screenshot-%Y%m%d-%H%M%S.png') && swaymsg -t get_tree | jq -r '.. | (.nodes? // empty)[] | select(.pid and .visible) | .rect | "\(.x),\(.y) \(.width)x\(.height)"' | slurp | grim -g - /tmp/$filename && notify-send "Screenshot captured" "/tmp/$filename"
I picked one a few of those issues at random, and they're entirely out of context and deliberately misrepresented.
For example, some Jitsi bugs are closed as "we can't fix this", and it's because the issue was a Firefox bug (hence, Jitsi devs could do nothing). Also Firefox did actually fix that. So, not only is the context wrong, the issue is actually solved.
Also, I used Jitsi and screen sharing on sway several times a week - works like a charm.
I've looked at a few examples, and they seem to most be misrepresented the same way.
i3, xmonad, elightenment, ctwm, WindowMaker and dozens of others appeared only because X made it easy.
Wayland makes developing window managers difficult again.
The Sway devs maintain a list of common helper applications that work with Sway: https://github.com/swaywm/sway/wiki/i3-Migration-Guide
Creating a user service per single line exec foo is extra ceremony.
I have nvidia hardware so sway makes no sense for me to use.
Also it's developer is extremely abrasive.
Furthermore a lot on that list isn't an even trade.
ydotool is a poor unmaintained replacement, making your own custom layout is a lot more work than xmodmap.
On net if you don't have mixed dpi so far as I can see you aren't actually gaining anything.
The best sales pitches I've seen are almost as good as what you already have but on wayland.
Is there anyway that sway does better than i3?
Then go with the parent post's other suggestion: a simple startup script that ends with launching Sway.
> I have nvidia hardware so sway makes no sense for me to use.
I mean the fact that Nvidia refuses to play by the rules, making their hardware unusable with Wayland, is a well-established thing by now.
> Also it's developer is extremely abrasive.
Is he? He has strong opinions and doesn't beat around the bush, but does that really matter unless you yourself actually want to develop Sway?
> Is there anyway that sway does better than i3?
I actually haven't tried i3, but on the face of it I would say that it's an advantage of Sway that it can run without the gigantic and increasingly unmaintainable legacy system that is X. You can certainly run X without problems today, but isn't it widely agreed that X doesn't exactly have a bright future? Sway is not tied to X's future.
No user on earth cares any more than they care about the sharpness of the blades used to grind the sausage they ate for breakfast.
I'm not sure why you imagine that nvidia is obligated to support Linux in the fashion you would prefer. I bought the hardware based on the existing drivers working well under Linux and windows not love for them or idealogy. This is why most people buy things.
X11s future departure seems like a thin justification seeing as it's future seems pretty secure for the next decade. Maybe by 2030 there will be a compelling case for switching plus hopefully the kinks will have been worked out courtesy of folks like yourself.
OK, let me rephrase it: a feature it has over i3 is a higher probability of running on the platform provided by most distros in 5 years' time.
> No user on earth cares any more than they care about the sharpness of the blades used to grind the sausage they ate for breakfast.
Indeed. But if you're choosing a sausage you wanna have for breakfast for the next few years, you might choose better than the one made from the animal that people fear might go extinct.
> I'm not sure why you imagine that nvidia is obligated to support Linux in the fashion you would prefer.
Oh not the fashion I prefer. The fashion the Linux developers prefer. Most other providers of hardware seem to. What makes Nvidia special?
> X11s future departure seems like a thin justification seeing as it's future seems pretty secure for the next decade.
Perhaps. You may well be proven right, but I wouldn't bet that X11 is able to attract sufficient manpower to keep up going forward. Time will tell.
I'm not trying to convert you. I'm trying to give one argument why Sway might offer something that i3 doesn't.
No word on whether red hat will be able to get rid of x11 by 2023/4 or whenever the next major release is and end up supporting it until 2036ish.
You had to use xlib to access X11 too.
(and bunch of others if you wanted nice things like font scaling, clipboard etc.)
And people will probably write other libs. If nothing else I expect ... but in rust and goloang variants.
It has its own libraries for things like screensharing (xdg-desktop-portal-wlr) that should work across these window-manager-esque desktops.
WayFire makes wlroots a bit easier but I find it quite messy/not clear (but it's very powerful & flexible).
There's definitively the need for an easy high level API for wlroots (the main wlroots dev started working on a high level scene tree API some times ago but it now seems kinda abandoned)
That's subjective. There are compositor libraries. It shouldn't be more difficult.
-simulated keyboard/mouse input (some progress recently with some composers)
ability to inspect window attributes (e.g. window title, executable and handle)
ability to manipulate windows (e.g. maximise, close, etc)
So just as with automation software this has significant impact on accessibility. The current composers available provide very limited functionality. Not to mention there are many different composers that would have to be supported to make many different system configurations accessible.
Wayland has a different approach when it comes to security, which makes it much less flexible in order to increase user security. It has evolved a in way to allow as much legit things as possible, but it will never be 100% compatible with what Xorg offered, by design!
I have never had this serious hardware issues with Linux since 2002. Xorg got outdated but the replacements are not here yet.
The desktop environments do have settings for scaling all the elements (not only fonts) but when running on Xorg, the alternatives in the DE are 1x, 2x and 4x, while many present-day configurations would require fractional scaling (like 1.5x) to be usable.
I have a 27-inch 3840x2160 display which I cannot use without scaling, since the UI elements get too small for my eyesight, and scaling everything 2x (effectively 1920x1080) kind of voids the purpose of buying a 27-inch display since the usable screen estate is downgraded to something typical for 23-inch screens. Our laptop has 13-inch screen with 1920x1080 resolution - again not usable without scaling and a disaster with 2x scaling (960x540). Windows is offering very convenient 150% and 125% scaling options on these pieces of hardware, so I had to migrate my professional work to WSL unitl updating to Radeon and Wayland.
https://refi64.com/posts/dont-boycott-wayland.html
They seem to point to https://pipewire.org/ for screen recording. I don't know how well that works out in practice and if there are other solutions for automation
Which is not surprising, because pipewire, too, decided to start from from scratch instead of working inside gstreamer.
I'm on freebsd mostly anyway which isn't big on the Wayland train so I'm fine for now. But it would be great if X11 development would be continued.
Really? I’ve found x-forwarding much slower and annoying unless the host is on a LAN.
Ideally if X was still maintained they could incorporate some of the old freeNX / X2go logic that makes it more robust against latency.
But I think this usecase is becoming more important again. In the early days of X it was great because we were all using terminals on single powerful machines. Then we moved to desktop and transparency was less of a thing. But now we're moving more and more towards cloud computing again which is not all that different from the old client/server model. At least not in the sense of having a separation between compute and I/O.
It would be. If a group wishes to take up Xorg development then I would be supportive of that. I suspect it may come from the BSDs, too.
I really hope some group will take it on board that really wants it. I think there's still a good usecase for it.
FreeBSD does support Wayland in a way but it's pretty primitive.
For users, not 'right' and 'wrong' here, just two groups whose goals differ.
Those supporting X.org are using X very much in the spirit of it; custom window managers, network transparency, and possibly bitmapped fonts, BSDs.
And those in support of Wayland have arrived there via Linux with eg. GNOME and dominated by GTK and QT desktop apps; looking for an open-source offering with the same functionality as Mac and Windows desktop.
Really, this has been brewing for a while. It's been a fluke that the underlying X has allowed these two groups to co-exist.
Wayland solves a lot of problems by deciding to just not handle things but we have to recognize that taking that position sacrifices things.
Does this mean that moving to Wayland (or its implemenation) is going to add 1 or more frames of delay to my output? This could be a part of why I have always found other modern systems to be less snappy than my own X desktop.
Apart from that, I depend quite a lot on things like xdotool, for which I'm not aware of a (generic) Wayland alternative.
If these issues are solved, I may try it again, but overall I'm pretty sceptical; around mid-2019 I tried GNOME on Wayland and there were some pretty wild rendering bugs that I didn't have on Xorg. The compositor being responsible for all rendering also meant that when doing something like opening the app menu, the cursor started lagging, but that's probably more of a GNOME problem, but it still concerns me.
> [user@laptop:~]$ echo $XDG_SESSION_TYPE
> wayland
Apparently it's not as bad as it seems! However, now that I think of it, I haven't been able to share the entire screen and must add one application at a time to OBS. Maybe I've gotten used to this. At least I won't accidentally show something that I'm not supposed to.
Ultimately the reason why I won't adopt Wayland is that I use XFCE, and XFCE doesn't support it.
Yes, some software will need to be updated, and no there's nothing preventing this functionality in Wayland.
Surely it's possible to write a modern display stack while preserving the rich legacy of applications, toolkits, window managers. I would certainly like proper isolation of input, and better support for HiDPI and even locking. But I would certainly miss Xscreensaver and Fluxbox, and even random applications like Asunder or Suckless Terminal.
Though I admit that I'm speaking from a position of ignorance, having only ever written in C/SDL for anything graphical on *nix.
PS: Now the possibility of porting Fluxbox to Wayland is beckoning me. Could such a mad thing be attempted?
I'm of the opposite opinion. Think twice before doing anything with X as the experience and knowledge you gain will soon be useless.
Instead invest in wayland, it works great and will only get better and X will only get worse at this point.
The pain points are few but yes, if you must have screen sharing with a particular app that doesn't work with wayland that might be a dealbreaker. If not, no reason to stay with X, pick a time when you are configuring a new computer or whenever it is a good time to make the switch and try it out.
That's been the sentiment for the past 12 years and X11 still works great and wayland implementations are a buggy, slow, featureless mess.
Remote desktop, game screen recording, screenshots, how do those work?
I'm having no issues with screen recording and screenshots. Haven't attempted nor need remote desktop but know people that do it. Obviously don't have the same breadth of alternatives such as X.
For instance, Wayland handle my multi dpi displays like a champ. Whereas xorg is a no end nightmare with no acceptable outcome;
In wayland, I have tearfree scrolling by default. Whereas on xorg I have to access some old magic knowledge hidden in the archwiki.
So, in a sense, wayland have more features (For me) than xorg, whereas xorg is the featureless mess (For me).
Wayland could have been executed better to ease adoption, no doubt. More than anything momentum is required, which we arguable are beginning to see.
The question today isn't X vs. Wayland. It is Wayland vs. Y. Whatever Y is.
Thus the choice today is actually X vs Wayland because those are the 2 choices that can provide a functional desktop at this point in time.
As for possible Ys I see SurfaceFlinger from android which doesn't look like its suitable for a desktop
Arcan a one man band that doesn't look apt to replace X soon
Whatever Redox uses. I don't quite understand from a casual inspection how graphics works there.
I would bet money that the choice over the next 10 years will STILL be X vs Wayland with more stuff wedged in until wayland is more functional but as kludgy as X wherein someone will have the brilliant idea to replace it with something more "modern"
When using gnome wayland is already the default in most major distributions already or have been announced for the next major version (such as ubuntu 21.04).
I don't know about KDE more than that they are making progress. If they within a few years make the same transition then pretty much every single default installation will be on wayland. A few moments after that XWayland will become the leading X-server. X will surely live on for decades to come inside wayland, and that is fine. And X will surely be an option for an eternity in some distros. But it will quickly become quite niche, similar to the way systemd has become the mainstream init system.
I wont feel bad about running a niche distro or even a different OS any more than I feel bad about picking Linux over windows in 2003. There is no accounting for taste and there are probably more people listening to Britney Spears than Beethoven. Its OK if you want to be involved with pop music there is money in it and it still requires the same skills to produce good sound regardless of the artist.
In order to go further, I had to do the same thing for KWin on Wayland, Sway and other compositors out there in the market and then integrate them into my program. I had to find some workarounds for any bugs that may occur.
Later on, some changes for ffmpeg API broke the Xorg recording (Green Recorder used ffmpeg to record on all desktop environments on Xorg), so I had to do more testing now for multiple versions of ffmpeg and on which distro do they work and don't work.
So I just gave up, as I simply didn't find any particular reason to continue doing that since the only amount of support I received on my then-opened Patreon was $20 per month at its max.
But it shouldn't be said that Wayland can not support screencasting or that it breaks screencasting. It is possible, and the previously mentioned issues are actually on the compositors' developers side, not the protocol.
For me it didn't "break everything" in fact, it fixed something for me. Moreover, it seems to be more secure (which is of course something you only notice by things not happening). So such a title does not really make me want to read what is probably an emotional rant.
Edit: I see the title just changed, anyway, I think most people realize it's not 1:1 with X, which is why Canonical makes X defaults and allows me to choose easily. At some point though it will be nice, I for one like the promises of PipeWire. Why is there so much emotion involved with such projects anyway?
But.. in desktop I use a Nvidia card, and for business shenanigans the drivers are not compatible with wayland, and Xorg it's ok but there are some features I miss, like fractional scaling in Gnome 3.
Right now I can see wayland as great alternative for casual users, that mostly use a web browser and require a fast solution that it's good enough, but I don't see it as a full replacement yet, and god knows if will ever be.
The problem it's that despite being old Xorg it's great too, and the benefits for wayland are there, but maybe not enough for a full migration from all developers.
The screen sharing works fine with xdg-desktop-portal-wlr and with Fedora moving fully into pipewire I'd expect things to get even more stable under wayland.
One thing I'm missing is a decent screen recorder (gif/mp4). For screenshots one can use swappy, it works perfectly.
wf-recorder (https://github.com/ammen99/wf-recorder)
for example:
wf-recorder --audio -f video_$(date +%F).mp4 --geometry $(slurp)
The glove is on the ground, Xorg is getting abandoned, anyone who needs Xorg in their life can take up the mantel and continue developing and maintaining it. I for one prefer Wayland since it has an architecture that allows for security (not that the protocol enforces security by default).
Wayland is a protocol, and wayland-related libraries are probably needed even if you just use X.
It's almost like different people have different priorities, who could've though?
If Wayland is just the protocol, this should be very possible; and perhaps it would have eased some of this transition.
If the CLI terminals improved on Windows that they could compete with any of the Linux ones, I would probably switch to Windows since it's now got a ubuntu compatibility layer.
Most I tried didn't work well (just didn't work, or broken keyboard shortcuts). I was a big fan of Kazam and Peek.
But I also think that they (Wayland) took a way too heavy napalm approach to the solution, almost like they totally ignored how painful such a transition would have been. I still don't get it...
But this last step is taking ages, what I don't understand is why it had to be such a painful process without a migration path (hence we are still talking about it and the transition still didn't happen)
DPS was available as extension on X11, but it wasn't the same implementation as on NeXTSTEP, where AFAIK even the old 0.8 code already used Mach IPC for communication with window server.
Wayland is a clear-cut example of that. Oh, mixed-resolution does not work well in X? Alright, let's rewrite everything from scratch. Of course, new bugs will appear, but then you can iterate the process to close them!
https://www.google.com/search?channel=fs&client=ubuntu&q=lin...
At some point, even in kindergarten, some kid's just being an ass.
Sorry, I'm picking sides here. :)
I am embracing Wayland and wlroot-based desktops. It is simpler, faster, and fits easier in my head.
Forgot to mention that I also just got my screensharing working under Wayland with Sway and Chromium for MS Teams (Have not tried with Firefox yet). Works like charm, albat with Pipewire. I have no gdm/GNOME installed.
Edit I: Mention the OS.
Edit II: Mention screen sharing.
Shame on those who speak / think ill of Wayland. /s
> What a surprise. Desktop components requiring X do not work on Wayland. It's as if they're different display server protocol
Yes, it's a breaking change. Yes, old software will have problems.
But X11/XOrg has run its useful life
Rhel 8 supports x11 and will be supported until 2029-2031. If they don't excise support by the next major release which is super likely it will end up supporting x11 until 2034-2036
I’m not sure there’s a legitimate case to be made against Wayland at all. The author seems to have installed it without understanding what it is.
Also xwayland is not a fix for any of the issues identified.
First problem identified
> Wayland breaks screen recording applications
Can xwayland fix it? Nope.
> Wayland breaks screen sharing applications
Can xwayland fix it? Nope.
There is very little Linux desktop malware in the wild.
What there is would seem to be minimally effected by wayland example
https://animajav.us/linux-systems-hiddenwasp-malware-trojan/
Instead of worrying about trying to get the keyboard as a non root user logically one might attack the filesystem or just work on getting root.
Linux desktop security vs threats actually already running on the system appear to be more an asperational goal than a reality.
At least there are documented cases of meteorites injuring people I can't find Linux malware available in the wild that would be mitigated by wayland.
Much like systemd, Wayland sounded as though it might have some serious wrinkles but those, as with systemd, never really materialized for me (a power user on a powerful machine). Most issues I experienced were transient as applications caught up with the switch (mostly screen sharing). Even though it's not too important to me, games (wine and native) are working better than ever on Linux (and Wayland).
I think the two persistent "issues" I've seen are: graphical ssh (X-over-ssh); and, maybe, others screen drawing on my screen in Slack calls.
I trust the arguments from the x11/Wayland developers and, AFAICT, Wayland has been a Good Thing but some eggs were broken to make the omelette...