I’ve written some other posts on Wayland recently, and it’s time for another one! Feel free to skip it it you aren’t interested in a discussion of Wayland and platforms.
Many may be familiar with the now semi-famous “Wayland breaks everything!” document written by Probonopd–one of the core AppImage developers–panning Wayland because it isn’t a drop-in replacement for X11. And he’s in the news again for a new Github repo with the aspiration of creating protocols for functionality not currently available to Wayland-native apps that are intentionally missing in Wayland’s standardized protocols–which won’t work because lacking standardization means they won’t become a part of the platform that app developers can reliably target.
There’s a bit of chuckling and jeering over this in developer circles, but to regular people, the whole “Wayland breaks everything” charge might ring true, or at least seem like it contains a kernel of truth. Because from a certain perspective, he’s right: Wayland really does break everything that directly uses X11 functionality!
It’s just that this is the wrong perspective.
Look, if I said, “Linux breaks Photoshop; you should keep using Windows!” I know how you’d respond, right? You’d say “Wait a minute, the problem is that Photoshop doesn’t support Linux!” And you’d be right. It’s a subtle but important difference that puts the responsibility in the right place. Because there’s nothing Linux can do to ‘un-break’ Photoshop; Adobe needs to port their software, and they simply haven’t done so yet.
And it’s much the same with X11 and Wayland. Wayland wasn’t designed to be a drop-in replacement for X11 any more than Linux was designed to replace Windows. Expectations need to be adjusted to reflect the fact that some changes might be required when transitioning from one to the other.
Now, even though Wayland wasn’t designed to be a drop-in replacement for X11, it was certainly intended to eventually replace it. But this implies that it was intended from the start to do less than X11, and and that would be correct.
X11 was a bad platform
In ye olden days, X11 was a whole development platform. Your app that targeted X11 could use X11 to draw its UI with a built-in widget toolkit; print documents with an included print server; record the screen; set global keyboard shortcuts; and so on. This is all way before my time, but I get the sense that X11 was either originally envisioned to be a development platform for app developers, or else quickly morphed into one during its early days.
It didn’t work out. The built-in UI toolkit looked horrendous, even for the standards of the time. Apps that requested the same resources could stomp on one another and break each others’ functionality in ways that were impossible to fix short of uninstalling one of the apps. Features like printing withered because a window manager was really the wrong place to put that functionality and its later maintainers lacked the needed expertise or interest to maintain it. And so on.
UI toolkits like Qt and GTK quickly rose up to take over most of this sort of app platform middleware in a way that worked much better for users and was easier to target for app developers. We’re talking about the mid 90s here; it was a long time ago.
(Of course this is slightly unfair; lacking a print server isn’t what people complain about being missing from Wayland. It’s more like things like apps able to set custom window icons and move their own windows. These are the really hard cases; they aren’t present on Wayland because they were commonly abused by apps on X11 to cause unsolvable problems. It’s not an easy thing and there are trade-offs involved in bringing them to Wayland.)
Linux isn’t a platform
Anyway, the rise of UI toolkits necessarily fragmented the app landscape. Instead of developing for one target (X11), a FOSS app developer now developed for Qt, or GTK, or whatever, so we ended up with a lot of “KDE apps” and “GNOME apps.” Yes, these apps still probably worked elsewhere, but it was obvious what platform and toolkit they been developed to work best in. They might look and feel weird when run elsewhere, or certain features might not work well or at all.
And that’s where we remain today. Absolutely nobody writes an “X11 app”; their app may use functionality in X11 for something that there’s no better way to do, but the app will use Qt, GTK, KDE Frameworks, or whatever for 99.9% of its functionality.
It brings us to a potentially thorny topic: Linux isn’t really a platform either, any more than X11 succeeded at being one. Almost nobody writes a “Linux app”; making raw Linux kernel system calls is generally unnecessary because whatever UI toolkit you’re using wraps this functionality and abstracts it to all the different platforms that the toolkit supports. The toolkit ensures that it just happens to work on Linux too.
The real platform
So is all hope lost for cross-desktop interoperability? No. In fact prospects are better than they have been in a long time! Because today there is in fact an emerging platform; something that abstracts away even the app toolkits if you want to roll that way. I’m talking about Portals, PipeWire, and Wayland protocols.
Probonopd pans these as bolt-ons that you shouldn’t have to have running on your system, but I think this isn’t realistic. The model of the monolithic window server that offers all functionality failed decades ago. In its place, we have libraries and APIs that every FOSS developers can reasonably expect a modern system to be running.
The portal system offers a standardized way to present platform-native open or save dialogs, send notifications, open documents in other apps, print documents, take screenshots, record the screen, handle drag-and-drop, see if the user’s active theme is light or dark, and much more. The portal system uses PipeWire under the hood for a lot of this stuff, so you can expect that to be installed as well. And you can also expect most Wayland compositors–most notably the two most important ones KWin and Mutter–to support pretty much all publicly standardized Wayland protocols.
I think this is the platform: Portals-and-Wayland-and-PipeWire. Clearly we need to come up with a better name. 🙂 Maybe PW2. But if your app targets these, it will run on pretty much every modern Linux system. And the big two FOSS toolkits of Qt and GTK both have cutting-edge support for all of it. So use whatever UI toolkit you like.
Why now?
We’re hearing more about this recently because the transition is picking up steam. X11’s maintainers have announced an end to its maintenance. Plasma is going Wayland by default, following GNOME. Fedora is dropping X11 support entirely. We’re in the part of the transition where people who haven’t thought about it at all are starting to do so and realizing that 100% of the pieces needed for their specific use cases aren’t in place yet. This is good! Them being heard is how stuff happens. I wish it had happened sooner, but we are where we are, and there are a lot of recent proposals and work around things like remote control, color management, drawing tablet support, and window positioning. There will probably be an awkward period before all of these pieces are in place for all of the people. And for the those who really do suffer from showstopping omissions, I say keep using X11 until it’s resolved. No one’s stopping you (well, except for Fedora, so if this is you, don’t use Fedora. 🙂 The cutting edge should be fun! If it isn’t, try something else).
Wrapping up
In this context, “breaking everything” is another perhaps less accurate way of saying “not everything is fully ported yet”. This porting is necessary because Wayland is designed to target a future that doesn’t include 100% drop-in compatibility with everything we did in the past, because it turns out that a lot of those things don’t make sense anymore. For the ones that do, a compatibility layer (XWayland) is already provided, and anything needing deeper system integration generally has a path forward (Portals and Wayland protocols and PipeWire) or is being actively worked on. It’s all happening!
Adventures in Linux and KDE 
I like the name PW2. The other option is PWP, I guess. But yeah, I think presenting the ‘new’ freedesktop standards as an entire platform is the way to go.
Regardless, I’ve been using KDE Wayland this year, and I gotta say, it has improved a lot since the first time I tried it like 1-2 years ago. It’s become a daily driver for me, with just a few things like screen share on Steam and other apps working seamlessly and simply remaining a pain point but not a deal break for me (and I’ve seen a lot of movements from RustDesk on that too).
I’m actually really optimistic about it, I hope the current pace remains and we got there in the next 1-2 year.
LikeLiked by 2 people
Yeah, being in the middle of a transition happening very quickly is an interesting place for sure. Stability has improved hugely but it’s not as high as I want it, either. I do have faith that this will improve substantially over the next few years now that Wayland’s major porting and feature work is done.
LikeLike
I think that PWP abbreviation will stay if people will have a need to use it. If not, well… we’ll see how it goes.
LikeLike
Great article.
Though I would say that the X11 GUI xtoolkit with Motif was pretty nice at the time. It worked and looked well all the way up until the late 90’ies. CDE provided a mellow and comfortable working environment while the contemporary MacOS and Windows was a lot more straining on the eyes.
Wayland is the future though and I’ve been using it for 2 years now. Have only had to log into an X11 session a couple of times, and lately I think I wont ever have to again. Keep up the great work Nate.
LikeLiked by 1 person
Motif was a later toolkit, reacting to the X platform toolkit Xaw being rather ugly.
LikeLike
@Simon Farnsworth
Yes, but Xaw, Motif and OPEN LOOK all used Xt with success. Motif was first released in 1989, only 1 year later than Xaq, and was a quite popular GUI toolkit for Unix.
LikeLike
Neither OpenLook nor Motif were part of the X11 Platform, though – only Xaw was.
It was clear very early on that the X11 platform wasn’t enough by itself (for a whole host of political reasons), so instead of investing in making it better, vendors worked on alternatives like Motif and OpenLook.
LikeLiked by 1 person
@Simon Farnsworth
But the XToolkit did provide the support for Motif to look the way it did. Motif rendered itself with Xt on the X11 side unlike later toolkits like GTK and Qt that rendered themselves on the application side.
LikeLike
Lots of bs. I’ve been on Arch Linux for years and Wayland is running on Gnome.
No problems
LikeLike
Works for you doesn’t mean works for others.
I have a LOT of blockers on Wayland, because my use-case is different.
LikeLike
Sorry, I wrote in Italian, this is the version in English:
I respect your opinion, but it remains an opinion, which you present as fact. Wayland has basically no practical advantages over X11 other than some marginal improvements introduced very recently that would have been implemented in Xorg anyway had it not been decided to abandon it. On the other hand, it has innumerable disadvantages, including fragmentation and the need for applications and toolkits to implement functions that should logically be in a display server and not in its clients, with the result that some do it, some do not, some do but partially, or do it badly. For decades, the open source world has had to live with the problems of fragmentation (including that of X11 many years ago) and now a further fragmentation is being introduced without any real benefit.
As for the comparison you make between X11 vs Wayland like Linux vs Windows… let’s take what you write seriously. Suppose tomorrow the developers of glibc decide that because they no longer understand C then C is obsolete and glibc will be replaced by libR, a system library that only supports APIs in Rust. Immediately all the things that worked before would stop working, developers would have to learn a new language, rewrite everything from scratch, etc. Not only that, the new libR, by design, would stop implementing two thirds of the old functionality, which would have to be re-implemented by individual applications or third-party libraries. That would be a disaster. Here, Wayland is only a slightly less dramatic disaster. But perhaps that is not true either. In the case of libR, at the very least, one would have the advantage of using a language that has real advantages over C and that, in the long run, would perhaps make system development easier and faster. In the case of replacing Xorg with Wayland, basically the only effect is to lose functionality and complicate things, not simplify them.
LikeLiked by 2 people
> Wayland has basically no practical advantages over X11
Wayland will be supported going forward, while X11 will be not. How’s that for a practical advantage.
LikeLiked by 2 people
“Wayland will be supported going forward, while X11 will be not.”
This is not a merit of Wayland per se, it is just a decision made by the developers.
LikeLiked by 1 person
There are only two relevant facts at play here:
– Xorg is unmaintained
– KDE needs to plan for the future to stay relevant
From those two facts alone you can see why KDE absolutely needs to support wayland (or any other alternative to Xorg). It does not matter that “Wayland is hard” or that “Wayland breaks my stuff”. Those can and will be overcome.
Also, it’s hard to take you comment seriously when you complain about “innumerable disadvantages” but fail to mention one thing that doesn’t work for you currently.
LikeLiked by 1 person
It is not so true that Xorg is not maintained, it continuously receives patches (I am talking about Xfree86 not XWayland) also with substantial improvements especially to modesetting driver and glamor. Having said that, it is true that it is not as developed as in the past, and obviously that decision affects the entire Linux ecosystem in a cascading way. But that was not the point. The point is that this whole mess is totally unnecessary and harmful.
LikeLiked by 2 people
> I am talking about Xfree86 not XWayland
XFree86 hasn’t had a release since 2008.
Xorg didn’t even have somebody interested in doing releases which lead to distros shipping random patches for some time. Now this inly significant maintainer, RedHat, has deprecated xserver in their distro.
> The point is that this whole mess is totally unnecessary and harmful.
Actual isolation between clients that doesn’t trivially enable privilege escalation is never unnecessary
LikeLike
> XFree86 hasn’t had a release since 2008.
Totally irrelevant, the various components are regularly released, the latest release of xorg-server is 14 days old.
> Actual isolation between clients that doesn’t trivially enable privilege escalation is never unnecessary
Apart from the fact that this security is already implemented in Xorg via an extension (see https://www.x.org/releases/X11R7.6/doc/xextproto/security.html), it is actually totally ridiculous to think of making a system secure from its graphical server. It is like believing that a house is secure by closing the windows when the door remains open.
LikeLiked by 1 person
> Wayland has basically no practical advantages over X11 other than some marginal improvements introduced very recently that would have been implemented in Xorg anyway had it not been decided to abandon it.
You’re right. Current rootless Xorg with client-side rendering toolkits, window managers/compositors, DRI3, present extensions, KMS and direct rendering is basically Wayland given almost everything is delegated to the compositor and clients. This means the Xorg process and most of its ancient protocols and server-side rendering model are completely useless noadays and that makes it nothing more than an useless middleman between clients and compositors.
Keeping all this legacy wouldn’t be an issue however because X11 was made for single screen/single GPU cases then things like proper screen-independent VRR, HDR, Hi-DPI scaling are impossible on Xorg without a big refactor whereas work seamlessly on Wayland.
Get rid of the useless middleman and make the refactoring for modern use cases and you get Wayland basically.
And that’s without even talking about the security nightmare Xorg is. Not having apps that can snoop on the whole screen or other windows/inputs without your permission is a huge advantage in my book.
> On the other hand, it has innumerable disadvantages, including fragmentation and the need for applications and toolkits to implement functions that should logically be in a display server and not in its clients
Most of the hurdles is already abstracted by toolkits and even when making X11 applications you don’t talk directly to the X11 protocol anymore so they work out of the box on Wayland and if not XWayland takes care of them.
However I agree that the fragmentation is bad on the compositor level but nothing prevents some middleware to take care of the protocol level input/display aspects just like wlroots is doing.
Also the fact that some much needed protocol extensions like window positioning aren’t part of the core yet is also annoying, and I understand the ex-Xorg developers that want to make it right unlike in X11, but this breaks some applications unfortunately.
> Suppose tomorrow the developers of glibc decide that because they no longer understand C then C is obsolete and glibc will be replaced by libR…
But Xorg support isn’t being removed at all. In all distros you can use your Xorg session just fine and if not you have XWayland and this isn’t going away anytime soon (if ever). All Xorg apps continue to work just fine and don’t need a rework so this scenario is disingenuous at best.
LikeLike
“I respect your opinion, but it remains an opinion, which you present as fact”
The same can be repeated about your post. it should have a lot more “I think”, “I prefer” and “I opine” in there.
>> Wayland has basically no practical advantages over X11 other than some marginal improvements introduced very recently that would have been implemented in Xorg anyway had it not been decided to abandon it.
thats admitting that Wayland does have advantages. Infact they existed from day one: an end to frame tearing. However the bigger problem with your statement is it is presented as fact. “Wayland has basically no practical advantage” is your opinion and not a fact.
LikeLike
Supposing for the sake of argument that it were true that Wayland offered no advantages over X11 besides being maintained, overlooking that would be a mistake. KDE doesn’t have the luxury of ignoring important developments that happen in the world around us; when a major component of the software stack that we rely on starts to wither away, it’s an existential risk for the whole project. In addition to the unmaintained software bit-rotting over time, if we didn’t add Wayland support and stuck with X11, we would lose the ability to be a stakeholder and decision-maker in the transition process. Because KDE was an early adopters, we have a seat at the Wayland project governance table. What does this look like in concrete terms? KWin’s Wayland representatives have ack/veto power in Wayland Protocol approvals, for example. Linux Mint doesn’t have this. XFCE doesn’t have this. We do. Because of that, projects like Linux Mint and XFCE have to rely on the benevolence of others’ decision-making. And without KDE there, it’s likely that Wayland protocols would look a lot more GNOME-focused than they are today.
I’m glad that years ago, KWin’s developers decided to step up and participate in this transition–gaining power and influence in the process–rather than boycotting it and ending up getting dragged into it kicking and screaming, in the process losing both agency and credibility.
LikeLiked by 4 people
> In addition to the unmaintained software bit-rotting over time, if we didn’t add Wayland support and stuck with X11, we would lose the ability to be a stakeholder and decision-maker in the transition process.
Nate, nobody cares or complains that you support Wayland. The problem is that you defend it, and advocate it. You can implement things you consider bad, just for sake of compatibility and “existential issue”, this happens on Windows all the time where most devs hate the APIs. But they do it because they have to. They don’t defend it.
Why do you defend this garbage? What is alternative to allowing apps to position Windows? Suppose I am a Blender user. I want to open up a specific project file and have it position windows the way I saved them at, on any system I open them on. Just like how they work on Windows. Why should the Linux experience be inferior?
It is IMPOSSIBLE to achieve this with Wayland. It’s not like it needs a rewrite. It simply cannot do it. The best you can hope is to somehow let the compositor know how to position the windows but that won’t be per-project-file, and it certainly won’t be across systems.
Don’t ask why we need this. Not everyone has your workflows. People want it. It works on Windows, and all this does is push people to hate on Linux even more, even though it works on X11, and it’s just Wayland’s fault.
The Wayland devs are by far the most stubborn bunch I have ever encountered because they think the world revolves around them and what they consider “a workflow”.
You haven’t even addressed half the things probonopd listed in his new repo. Don’t act like you have “alternatives” when they simply CANNOT BE DONE. Whether you, or the Wayland protocol devs, consider them important or not is irrelevant. You, neither them, are not other people’s parents to tell them how they should fit their workflows.
LikeLiked by 1 person
“Wayland has basically no practical advantages over X11 other than some marginal improvements introduced very recently that would have been implemented in Xorg anyway had it not been decided to abandon it.”
Please read carefully: https://orowith2os.gitlab.io/posts/wayland-breaks-your-bad-software/
LikeLike
Not being able to choose your window’s positioning is a major flaw with Wayland, as is CSD being the default (which ironically can be a security hazard, if windows were to use different borders to denote different authority/privilege levels). It is a bit silly for having extensions for a protocol that, virtually most other OSes (Windows, Mac OS, etc) get right in their own way. Why should an application not know where/how its windows are positioned? There are lots of use cases for knowing that information, yet the Wayland devs are too stubborn to accept this fact.
Not to mention, we’re basically back to the X11 dilemma but the complexity being hidden by a library (wlroots) instead of an Xorg server. Hopefully driver support isn’t so bad across the different compositors.
With a protocol that tries to cater for everything including the kitchen sink, it has to tread carefully to avoid turning into a slightly different implementation of what it aims to replace. It’s all good catering to stuff like infotainment systems, kiosks, etc where window position isn’t a big deal, but mainstream applications don’t run on these systems, they often use custom software. Embedded flavors of Windows understand this, yet Wayland devs can’t grasp this concept.
LikeLiked by 1 person
Xorg is obsolete. Wayland is more safe, efficient and reliable. Xorg developers have abandoned the project, if not to patch some dangerous threat. Wayland allows to get results in more efficient way. Linux operating systems need to be modernized and all the software that hinders this aim must be eliminated. Also Wine is migrating to Wayalnd and Vulkan. Opengl and Xorg are overcome. Now it’s time for Wayland, explicit sync and Vulkan.
LikeLike
I will use Wayland when this old Nvidia card fails.
LikeLike
As a Fedora KDE Plasma user, I’m of course in favour of switching to new, better solutions. What worries me a bit, though, is the fact that fractional scaling still doesn’t work with Wayland. At least this is the case on Fedora. I read that fractional scaling has been supported in Wayland for over a year now (version 1.31?) but it seems it hasn’t landed in my distro yet. Losing the option to scale the screen to 125% would force me to a different distro. 😦
LikeLike
I’m use Fedora KDE Wayland as well and I’ve had fractional scaling since Fedora 38. FWIW I’m using only Intel integrated graphics. What GPU do you have?
LikeLike
> I’m use Fedora KDE Wayland as well and I’ve had fractional scaling since Fedora 38. FWIW I’m using only Intel integrated graphics. What GPU do you have?
Also works fine on Arch + AMD GPU with Plasma 6.0 Beta
LikeLike
I use Intel graphics. And yes, I can select Wayland on login and it does work. It just doesn’t look acceptable. See the screenshots here:
X11: https://paste.tchncs.de/upload/otter-viper-pig
Wayland: https://paste.tchncs.de/upload/eel-parrot-raven
LikeLike
It gets a lot better in Plasma 6. 🙂 The blurriness issue shown in your comparison screenshot is fixed there.
LikeLike
That’s great to hear. Thanks Nate! 🙂
LikeLiked by 1 person
Im using OpenSUSE with KDE 5.27 on Wayland and I have fractional scaling working fine, including different scaling factors on different screens.
LikeLike
So how’s that colour management coming along?
Also, non gtk/qt toolkits for audio plugins?
(Audio plugins are loaded into the memory of the host program meaning you can have multiple copies of gtk *and* qt in the same process memory at the same time)
LikeLike
Basic color management is included in Plasma 6 Wayland.
Not sure what you’re referring to with regarding the audio plugins thing. Is this really a Wayland/X11 difference?
LikeLike
Yes, because audio plugins need to use toolkits other than that of the host that holds them.
It’s very common for plugins to use more basic toolkits or even direct X11 commands which won’t work on wayland.
“Basic” colour management? Is it enough for artists for whom good colour management is an absolute requirement?
LikeLike
I admit the audio plugin thing isn’t something I’m familiar with, so I’ll let others talk about that. It’s possible there’s a solution that involves porting to some newer library.
As for color management in Plasma 6, like I said, it’s basic. Right now only supports up to the sRGB colorspace; wider gamut color spaces aren’t supported yet, and will require a new in-progress Wayland protocol. That’s in progress.
If what the Plasma Wayland session offers isn’t enough for digital artists, I encourage them to continue to use the X11 session until that changes. In KDE we have deliberately not removed support for it, and I don’t anticipate that we will for a very long time. This shouldn’t be a problem for anyone unless they use Fedora; if so, they’ll need to switch distros.
LikeLike
The real problem in Linux world, and especially this transition from X11 to Wayland, is that most Linux applications are created by volunteer devs without any financial help.
So, for major players like GNOME, KDE, Inkscape, LibreOffice, Gimp…they can survive via their sponsors, but for solo projects it’s difficult and sometimes impossible to port their apps to Wayland because they need money, time and technical knowledge.
So KDE project should never follow foolish decisions like the last ones made by Fedora and Red Hat to drop X11, because KDE is way bigger than any distro, and it should maintain X11 until the ground is suitable for full and smooth transition to Wayland.
LikeLiked by 1 person
It’s only X11 session that is removed from fedora 40. X11 application support will still be available through xwayland.
LikeLike
It’s a valid point, and transitions are indeed hard for volunteer devs.
But this is also not unique to the Wayland transition; every time there’s a major Qt version bump, some older KDE apps get left behind because there’s no one around to port them. I assume the same thing happens with other toolkits and software stacks too.
Porting to The Hot New Thing™ is simply a fact of life in software, I’m afraid; it’s a part of maintenance and continuity. We could say that volunteer projects often fail to plan for this kind of thing, but frankly a lot of commercial software is in the same boat. Oftentimes it’s easier to just rewrite the software for the new toolkit/libraries/tech stack and sell the new thing at full price despite having fewer features. So I don’t think in FOSS we’re uniquely bad here. 🙂
LikeLike
@Magnus : It is the X11 what we need and not only the x11 support in wayland and it is a stupid Idea to remove it from Fedora 40 what’s my opinion too. In my Opinion have stay the X11 so long as possible and if all works proper in Wayland, include the Windows Positionering protokoll and loging what should existing.. and all what is in X11 funktioning and in Wayland not working.
best
LikeLiked by 1 person
Well, we as regular users couldn’t enjoy more when we see such evolution happening under our eyes, as gnome user I appreciate KDE’s efforts into putting more code than bureaucracy,
Don’t get me wrong I do appreciate developers time and effort but looking from outside from some reason I can’t see new people being involved into coding, Yes I’m criticising gnome’s infrastructure not KDE’s.
Following Wayland Protocol, Wlroots and gtk4/mutter/gnome-shell I got the impression that exclusively only RedHat employees have the right to merge the code, speaking of code recently they rebased some work which was written 4 years ago onto mutter-git!
On another side those employees tend to criticise KDE’s devs cause they run without making sure that Linux kernel side got the given features and from that reason they hold back!
Disclosure, I’m not programmer and of course I can’t say that one thing is wrong or right but looking from outside by the all amount of investment gnome got in a couple of years they still sucks in comparison with KDE, to me it seems that all the resources don’t arrive to coders but to those in charge of bureaucracy!
LikeLike
FWIW, KDE has a leadership position in Wayland Protocols, with ack/veto rights. So It’s definitely not the case that only Red Hat employees are allowed to merge things. This doesn’t mean it’s always easy to get agreement on changes, though! The process is very political and challenging, for sure. It’s something I think no one is particularly satisfied with. But it may be sort of like how “Democracy is the worst form of government except all others” because no one’s come up with a better model for how extremely diverse stakeholders can come together to work on something that affects all of them.
LikeLike
hmmm…
both be Grafical Server, the Windowmanagers like KDE(Plasma) and Gnome be a other, but… the API’s be coded in the Windowmanagers for have a grip at the Grafic-Server like XOrg and Wayland .. so, the API’s exist in Xorg and have pretty well so far his works and exist.. in my Opinion have now the programer analizing the whole API’s in XOrg and export it .. or rebuild it in Wayland to have a 100% Compatibility.. and this in a new modern code, but to have a support for the “more orginal” Api’s out from XOrg which I think is very important in order to have the same API goals as XOrg and therewith it is fixed the most trubles where now still exist because just Wayland have not all api’s what even have still xorg.. look easy the nvidia-settings in xorg and in wayland, this is most prominent, in wayland it is not possibility to have a configuration, only informations over the nvidia-card, but not possible for create a xorg.conf or even a configuration-file in wayland … also Window-scaling-adjusting or figure/schema in the Window-Managers be a bit other … Wayland works maybe so far for have a Desktop, but not in this Art and way how Xorg it does .. and Wayland still has to catch up .
best regards
Blacky
LikeLike
Read this post to understand the advantages of Wayland:
https://orowith2os.gitlab.io/posts/wayland-breaks-your-bad-software/
LikeLike
>>Adobe needs to port their software, and they simply haven’t done so yet.
>yet
What an optimist you are, Nate! lol
LikeLike
Haha I know, but let’s see what happens once our market share reaches 10 or 15%! They won’t be able to ignore a growing untapped market forever.
LikeLike
that’s why I like Nate !\*giggle*\
and if i look of the end of the Support of Win10 , the whole nice Hardware, all for the wonderful Linux distros \*bg* in Seriously, who needs really the TPM in private, it’s imho bullschit and a tool to bring the peoples in sence” of te Security to this way what the Facilitys and moneymashins whant.. and bring clear to the way to Win 365 for bring the peoples into the OS-Cloud for digging the peoples informations … How ever.. this what’s at momens run in the WinNT world is …not good…
and i bet, there makes the way open for more new Linux Users and more Reactos Developer to have a GPL2ed WinNT for free and for all.. how ever , the times what’s comes becomes interresting ..
LikeLike
Funny thing is, the Adobe apps themselves work fine on Wine with little to no tweaking (I think Premier needs 64bit native MSXML3), but you have to use cracked versions of the apps copied from a Windows install, because the Adobe Creative Cloud Installer/Manager app itself is what doesn’t work (no one has been able to get it to work so far). Chances are, if they ever switch from MSHTML.dll (Internet Explorer/Trident) to Chromium/Electron or even Edge WebView2 Runtime, things would probably Just Work on mostly-stock Wine. At that point you could even package everything into a Winesnap/the-Flatpak-equivalent-of-a-Winesnap for easy installation on any distro.
LikeLike
Cool, but i really do need the functionality of launching the window of my own application at defined coordinates and size. Even webbrowsers need that, when they use popups as control elements (like imagine a seperate chat window) and don’t want that to be a full sized window and define an innerWidth and Height.
The arguments of the wayland developers, why exactly this should be a security vulnerability, sound unreasonable to me, because the window manager can always limit the size or position to make sure it’s not abusive.
And for other issues, you just have to ask Krita devs why they aren’t very active in qt6 porting yet 🙂
LikeLiked by 1 person
Wayland allows you to create a new window at a location relative to an existing one, which solves the browser problem completely.
LikeLike
Well, what you want is for your windows to stay where you put them. There are multiple ways by which this could be achieved; letting windows do it themselves is only one. And it’s quite a bad one because it means the position remembering code gets written many times–once per app or toolkit–that opts in, and as a result the semantics of the position memory feature are subtly different across apps due to differing implementations and assumptions about screens. In addition, many apps won’t opt into this feature in the first place, so in practice whether your windows remember their positions ends up feeling totally random to the user–even more so once they start plugging and unplugging screens. This is a case where the window manager really should be in charge, so that it can have one algorithm for remembering window positions, and that system can be applied to all windows universally using the same set of rules. This way the behavior is consistent and bugs can be fixed in one place.
LikeLike
I was primary thinking about applications that use multiple windows.
I.e. a tool preference box that pops out into its own little window of the same size and position it was when it was embedded. That is my specific case here.
Appearing at the middle of the screen or appearing at the last position you used it, is annoying, because the user has to look for it, rather than it popping out right where he triggered it.
Or i am missing something very drastic.
What Simon Farnsworth says is a solution i have to research, but somehow i have the suspicion that it’s a wayland protocol that is a suggestion and not implemented yet. Firefox at least doesn’t do that, neither for tabs that get dragged out, nor for pop ups. On X11 it works.
LikeLike
Yes, relative sub-window (or sub-surface, in Wayland lingo) positioning is something that works. It sounds like you want to do that rather than spawning a real top-level window. Not spawning a top-level window will offer a better UX anyway since a new top-level window for a little tool popup would also inappropriately show up in the task manager, task switcher, overview effect, etc. You could set flags to make that stop happening, but then it would just make sense to use a sub-surface which gets you all that stuff for free. 🙂
LikeLiked by 1 person
I am currently looking into that.
I stand corrected.
Thanks a lot.
LikeLiked by 2 people
My usage of openSUSE KDE :
– Oyranos for color management.
– Clight for monitor light and gamma management based on the ambient light.
– With Firefox, surfing, buying.
– PIM suite kontact.
– Digikam only as a bank of photos and exporting to G Photo.
– Kdocker for minimizing in the systray Chrome web app as Facebook
– MS Windows app captvty with wine
I briefly tested Plasma Wayland with success.
Is there a mature replacement for Oyranos ?
For Kdocker, there is no compliant version, but I found a workaround. Launch kdocker as the following:
QT_QPA_PLATFORM=xcb kdocker
How long this will work ? I don’t know.
LikeLike
xdg-desktop-portal is coded to only work with snaps and flatpaks as sandboxes.
Lets say you want to run an application as a different user (not that uncommon) and have it use portals… it is not possible.
And the issue isn’t dbus or wayland (both can be configured to allow specific other users) , it’s on the xdg-desktop-portal itself that refuses to function unless it has access to /proc/{pid}/root
Even if it wouldn’t strictly need it.
LikeLike
Mathematically speaking, it should be (PW)²
Grouping terms in Maths is important 😉
Many thanks for all your hard work, Nate!
LikeLiked by 1 person
Switched to wayland at least a year ago on openSuse Tumbleweed and it works beautifully (Intel GPU, hidpi screen). If people only ranted about wayland! But whatever new software, there are so many totally negative comments. I understand it this way: those rants usually say more about the author than the quality of the software they aim at.
LikeLiked by 1 person
Change is hard. 🙂
LikeLike
I agree with the concepts exposed in the article. Sincerely, I hope all Xorg stuff, Opengl and XWayland as well be deprecated as sooner as possible and Kwin be explicit sync in order to take benefit from Wayland, Vulkan and drivers. I don’t know if Pipewire will be the default audio server in Plasma 6, even if I have read it matches with Wayland. To reduce the complexity makes the operating system management more simple, reliable and efficient.
LikeLike
No, Nate, this sounds like PR to me, like the old Apple’s “You are holding it wrong” thing. Wayland has real problems and yes X11 does too, but your post doesn’t sound like a serious answer to any of those concerns; not even if the root problem were the perspective, as you are saying. And that metaphor between Wayland/Linux vs X11/Windows, stinks by its inaccuracy, to say the least.
For the record, I do believe that Wayland is the lesser of two evils, so yes, “Wayland is the future” for me too, but I find this entry pretty insulting.
That’s my feeling about the post, my argument would end pretty similar to what the Italian guy above is saying, so I will not extend further.
LikeLiked by 1 person
Where is the insult? I don’t think Nate wanted to insult, nor did he do so.
Most users don’t care what a burden it is to write software against old, unmaintained code base. I am happy for all the brave souls that hack basic services like display, sound etc. that they get at least modern interfaces.
LikeLike
Isn’t this “platform” already called freedesktop.org? Or not, as I went to their website. Since Flatpak apps necessarily need to install org.freedesktop libraries, I thought this was what the base platform was called. But AFAIU, they do publish lots of specs that provide common ground and publish Wayland protocols.
LikeLike
FDO is probably another part of it, yeah. I didn’t mention it because unfortunately it’s a bit moribund these days, and GNOME in particular is moving away from a bunch of the standards that FDO has come up, which I find a bit sad.
LikeLike
well, Nate, Gnome is not the world, other Platforms use the FDO and hold the Standards.. they are who not hold the Standards, go out of the Community and lives outlaw and support not really the community and hold together … I want explain the “Standard” for you Nate, Standard is this who have agreed the Community as normality and whant this common agreed, this is “Standard” whant this anyone not, it’s not in the community.. and agreed this not the common aragement , it is not in this community.. fullstop.. so, if you working together with a Community have you Standards with the whole common community and this is then Standard and agree in the Community .. ?right? 🙂
best
LikeLike
Don’t forget about systemd. Long before any of the others systemd started this path of modernizing Linux, of streamlining apps, APIs, configs etc.
And even on those systems that (for whatever reason) don’t include systemd, they’ll likely include some of the APIs it introduced, likely the logind part.
LikeLike
Yes, ultimately I expect Systemd to end up as a de facto part of this de facto platform.
LikeLike
WTF is Portals? Though a long time Linux user, I’ve never heard of it. It would be nice to have a link or something since, as the Wikipedia disambiguation page shows, a @$#*-ton of things have been named “Portals”.
LikeLike
Here’s the repo for it. The docs are linked from the README:
https://github.com/flatpak/xdg-desktop-portal/
LikeLike
Ah yes the old tale about software being able to position their own windows causes unspecific issues. To this day there has not been a single bug report or forum post of a ‘normal’ user complaining about GIMP having this functionality – or any other software.
It’s part of the same fairytale that programs shouldn’t be recorded because ‘that causes issues’ or that global hotkeys are bad because ‘they cause issues’ or that copy & paste should not be supported because somehow that causes – you guessed it – ‘issues’. Weirdly nobody knows what these issues are…
LikeLiked by 1 person
I don’t think anyone’s against Wayland IN PRINCIPLE, or thinks X11 is flawless.
The impression I get from having hung out in the comments of Probonopd’s post for ages is that they’re usually pushing back against the following:
1. The attempt to jettison “mechanism, not policy” in the name of security.
(i.e. The attempt to kill off their ability to shell-script just about anything they want using things like wmctrl and xdotool. Last I checked, ydotool only does things that can be accomplished by circumventing Wayland’s security model using /dev/uinput)
2. The balkanization of desktops due to a lack of a comprehensive set of APIs that can be guaranteed to be available across all DEs. (Forget KWin vs. Mutter vs. wlroots… many functions that used to be achievable either via wmctrl or xdotool or by switching WMs are now not only specific to one compositor implementation, but may rely on something like swaymsg, which doesn’t work for other wlroots-based compositors.)
Yes, people like Probonopd consider Pipewire and XDG Portals to be an unacceptable way to claw some of that back, wanting the functionality to be guaranteed on systems without D-Bus, but the point remains.
3. The KDE 4-esque repeated “it works now”/WORKSFORME→”you just do this” dance for stuff that really did Just Work on X11. (I’m told OBS recording still has an element of this, with mysterious instances of “I was told this should work. Why isn’t it?”)
4. Fears stoked by already seeing zealots wanting to excise XWayland from their desktops and talking down to anyone who thinks it should be necessary… let alone that it should be supported in perpetuity.
That said, those certainly aren’t the only reasons. For example, the main reason I’m still on X11 is that I’m used to leaving desktop sessions logged in for months at a time on my nVidia binary drivers. (In fact, I just bought a new GeForce to CUDA faster because, for the software I need to run, people are still saying getting ROCm working is a crap-shoot and Intel Arc is too immature to rely on.)
While I do also depend on wmctrl and xdotool and don’t want to use Sway on UI paradigm grounds, I feel reasonably confident that, if I had to switch to Wayland tomorrow, I could get a still-maintained display stack by doing something like stacking rootful XWayland on top of cage or mutter kiosk-mode and running my usual X11 WM inside that… I haven’t yet tracked down a good choice for a Wayland compositor with an X11 backend that can run in rootless mode to allow said X11 WM to manage windows from Wayland-only applications.
That way, Flatpak’d applications (of which I use as many as I can) can be properly sandboxed and I can jerry-rig the “mechanism for granting standardized privileged APIs for whitelisted applications” that was promised in the Wayland design over a decade ago and never delivered on.
Bit of a shame that KWin as an X11 WM won’t be receiving updates, but I’ve resorted to other WMs before.
Longer-term, I’m hoping that Arcan will mature into what I need since I’m much more aligned with its architectural philosophy and it already has that whole privileged APIs thing figured out.
LikeLike
When informed of alternatives or asked whether the use case really makes sense, a lot of the Probonopd-style complaints kind of boil down to, “I don’t care, I wanna do it the way I wanna do it!” And that’s fine, do it the way you want to do it. Nobody’s forcing you to use Wayland (except for Fedora, so don’t use Fedora). Rather, the fear is about the future when change will be needed after no one’s shipping Xorg anymore. And I’m sorry to say it, but that’s just life. Change is a constant, nothing lasts forever, etc. You can fight and lose and feel frustrated, or you can accept, adapt, and help shape the future.
FWIW I wouldn’t say that KWin on X11 won’t be receiving updates. Most of KWin’s codebase is shared between the two, with X11 and Wayland being separate platform targets. Any changes to the shared code will absolutely affect (and hopefully benefit) kwin_x11 as well as kwin_wayland. It’s also not unrealistic that there will still be occasional X11-only bugfixes to go along with the more common scenario of Wayland-only bugfixes. At the minimum, because the Steam Deck defaults to X11 in Desktop Mode, anytime Valve sponsors a bugfix that only affects the X11 session, it’ll get merged.
LikeLike
well, but i am want be not the first, who use the changes, me and i bet a couples other oldest have learn to use a System more likely laters as the first, why, because the most errors and fails be terminated in the first time and only later are most of the errors and fails eliminated (like in Win95/98/me times 😉 ) .. this will shurely be also in Wayland.. i am want not be the first who want use the “fresh” programmed wayland because even be there some supports not existand and errors still exist.. This want change it if manny peoples of the community bring in mass of errors reports and spank the butt of the Programmers in Wayland *vbg* hehe…
Only then whant it change and become better.. and then become Wayland a good usable way.. imho..
best
LikeLike
I don’t feel strongly any reason to use Wayland, but I don’t feel any reason *not* to use Wayland. Unfortunately, every time I try to switch just to keep up, it inevitably ends up crashing or something and I put it off another six months. Also throw in the unfortunate gap of environments in the area between GNOME/KDE and the many tiling window managers… (XFCE user for 15 years.)
…at this point, I’ll either switch when XFCE’s on Wayland or I’m forced to on Arch, tbh. Know several other “I really hope I don’t have to move off XFCE”-types personally.
(PipeWire just dropped in place of PulseAudio without issue the first time I tried and fixed a bug I was having with PulseAudio at the time, so uh, good on that. 🙂 )
LikeLike
Wayland is really important for security. X11 is the largest security hole on modern sandboxes. Of course, it doesn’t matter for unsandboxed apps, but those will go away just like X11. But probably even slower than X.
LikeLike
> Because from a certain perspective, he’s right: Wayland really does break everything that directly uses X11 functionality!
It would be ok if it really broke only X11-specific functionality but the reality is it breaks the expectations of cross-platform applications. I’d understand such a move if Linux had >50% of the marketshare but designing protocol APIs incompatible with ALL other desktop platforms (Windows, macOS, X11) while having a part of the 2% marketshare is like asking to be dead. How much applications will we lose because managers would decide that spending development time to port application to a platform that is a part of 2% of their userbase is not profitable and would get rid of Linux support instead (or just use Xwayland until it’s buried and once it’s buried due to the lack of maintanance or whatever, lose the ability to run them). How much new proprietary applications won’t support Linux just because Wayland is way different than Windows and macOS now while with X11 you can re-use your cross-platform toolkit-based code without any changes?
Moreover, even if you would like to port your application to Wayland, both Qt and Electron still don’t provide Wayland-centric APIs, you have only Windows/macOS/X11-like global position APIs that don’t work on Wayland so you can’t make your application feel as a first-class citizen in the Wayland world even if you want so. The only toolkit that probably would let you do so is gtk. Even SDL is global position-based I believe.
The QTBUG-99618 was opened only at the beginning of 2022 and there’s still no action about it. For whatever reason, Qt refuses to change its public APIs for the sake of Wayland. Why? I can’t know for sure but something suggests me that risks of prototyping APIs around platform that is only a part of 2% marketshare are high and commercial advantage is low that makes it a low priority. And I haven’t seen a similar bug of Electron so apparently no one worries about being a firrst-class Wayland citizen there. idk about SDL, perhaps they don’t have plans for such a move as well. Wine wouldn’t be able to properly position menus as well because they can’t change the Win32 API which has only global positioning, nothing like the xdg-positioner and Windows applications actively use the information about the screens and global position for various features which wouldn’t work as well. Oh, and there’s also Flutter, what about it?
> so we ended up with a lot of “KDE apps” and “GNOME apps.”
Cross-platform applications written in Qt, Electron, SDL and Flutter are neither of these. And there are also little Rust toolkits now.
> which won’t work because lacking standardization means they won’t become a part of the platform that app developers can reliably target
Having an alternative standards body doesn’t sound bad to me given that the already existing one has proven to be very unproductive and inadequately opinionated in being able to force the world to be rewritten.
LikeLiked by 1 person
Just remembered there’s also wxWidgets holding amazing cross-platform apps like FileZilla
LikeLike
> I think this is the platform: Portals-and-Wayland-and-PipeWire.
I had a negative experience in contributing to Qt with such mindset. They claimed they don’t recognize this as a platform, only as a badly maintained way to work in flatpak, and have rejected my patch, suggesting I should port QGtk3Theme to gtk4 instead if I want a proper no-preference value support for the portal’s dark mode protocol.
LikeLike
Can’t please, just make video acceleration work on my Skylake mobile with Vivaldi? I’m not asking for much (I think this is the problem with Wayland for me, just one more thing preventing absolute “basic” functionality from working on Linux).
I’m hoping that by Plasma 6 launch most things will be working with little bugs, because I’m getting anxious to use it already after giving it a look on Neon Unstable.
LikeLike
> I think this is the platform: Portals-and-Wayland-and-PipeWire. Clearly we need to come up with a better name. 🙂 Maybe PW2.
Hrm. Pawap -> Pawpaw -> Papaya. Lets call it “papaya”. 🙂
LikeLike
what, papya? then rather Pizzawork2!!
damn, i become hungry again..
LikeLike
Out of curiosity:
Why didn’t KDE join Canonicals Mir back in the day?
Xorg could have been replaced 10 years ago.
LikeLike
In this kind of discussions I see some recurring patterns:
– X11 is bad
– Wayland is the future
– Change is hard
– A long discussion about which is (and not is) X11 / Wayland
Start from a real question: will XEyes run in Wayland ?
No it is not a joke, it is a real question: Wayland, as protocol, after 15 years (wikipedia dates Wayland 2008), is not capable to support this simple kind of application. Is a security concern ? A part the fact that is unclear to me how two [or more] eyes toward a mouse pointer can be considered a security concern, this should be easily solved allowing some applications (white list) to access an extended version of the protocol. I hope that nobody would answer saying that XEyes is a bad application (like “You are holding it wrong” Apple answer)
So back to the original points:
– X11 is bad: it is only a 40 years old code, yes it has a lot of “technical debit” but it just works. Is un-maintenable ? May be, but this doesn’t mean that an alternative is the right path only because it is an alternative …
– Wayland is the future: after 15 years, we should question why is not the present
– Change is hard: true, but it is harder if the proposed solution is not very good (more below)
– A long discussion about which is (and not is) X11 / Wayland: this would led why wayland mixes the mechanics with the polices.
My impression is that the weakness point of wayland is that because the protocol took too many time to develop (15 years !!, and we are not near the end) each group (KDE, gnome, wlroot … ) developed an its own display server+ window manager to bypass the limits of the “official” protocols. Unfortunately each implementation is slightly incompatible with each other (like mutter not supporting SSD).
I don’t think that wayland is better or worse than X11, I think that the develop model is too slow and the status quo is very unsatisfactory for both the parties (users and developers).
Possible solution ? In the past this kind of issues where solved by forking; may be decoupling mechanics from the policies would help too.
LikeLiked by 1 person
It’s a combination of a bit of everything, that turned this whole Wayland and “future of Linux on desktop” into a downward spiral. Hopefully there is still a silver bullet, and somebody does it. Linux on desktop deserves better then what we got. In this post X11era and so far.
LikeLike
Wayland is definitely step forward that solves a lot of historical issues with X11. But there are just a few things that basically makes third-party app developers stay away from it:
– That approach to not add pretty basic extensions like ‘windows placement/movement’ until “it’s done right way”.
– Be too restrictive and ‘insanely secure’. I’m not saying about screen capture or that XGrabKeyboard calls. But just count amount of projects that now manipulate with `/dev/uinput` for being able to do pretty basic thing like password autotype or hotkeys. For example this one: https://keepass.info/help/kb/autotype_wayland.html
From end-user point of view it’ll not add security at all.. I’m sure that this `/dev/uinput` API usage raised significantly with ‘wayland porting’ effort. And finally we’ll just get more hacks in app ‘installers’ like`curl http://my-app.com/install.sh | sudo sh -` that will just `chmod 666 /dev/uinput` to make it work. Luckly not everybody is aware that it’s possible to get screen content with something like `kmsgrab`
All of this ‘relative windows placement’ and ‘let all apps be compatible with tiling/3d/whatever window managers with radial coordinates’ stuff is cool thing, but Linux is not Apple. We don’t have enough user base to force developers to support that. So we definitely need to have feature parity with other desktops. And there should be no such thing as ‘wayland is ready’ until that basic stuff is done.
And still we’ve that ‘advanced’ linux users that uses linux desktop because of scripting/customization/etc. So we definitely need that `xdotool` stuff to be supported.
LikeLike
I am super happy KDE is always embracing new technology. Can’t wait for the Megarelease. 🙂
LikeLiked by 1 person
I disagree with the whole premise of the article. Whether you like it or not, people want to run existing applications like Photoshop, and it’s the operating system’s job to enable them to do that, rather than telling people that they need to have their software ported to (the new version of) their operating system. The Linux Kernel people recognize this, and that’s why we have futex2/futex_waitv: it was added specifically to better support Windows applications using WaitForMultipleObjects running on Wine. That’s the right attitude.
I understand that some of the APIs required by some applications are in conflict with Wayland’s security aims. But honestly I don’t care: just ask me if I want to allow it to do those security sensitive things. Yes, some people are going to hand out these permissions when they shouldn’t, but that’s their problem, and those of us who know what they’re doing shouldn’t be punished for the ignorance of those who don’t. That’s the entire point of free software.
LikeLiked by 1 person
You will be able to use X11 after release Plasma 6. I think nobody to force you to use Wayland session session.
Quoting user “Scias”:
But Xorg support isn’t being removed at all. In all distros you can use your Xorg session just fine and if not you have XWayland and this isn’t going away anytime soon (if ever). All Xorg apps continue to work just fine and don’t need a rework so this scenario is disingenuous at best.
LikeLiked by 1 person
It is shame that Plasma 6 will be released without very important (for many users) function like save session and its restore. Instead of that we will meet obsolete function like hold on shutting down/reset the system, so the ask for close opened documents/sessions in konsole. In this function even is missing closing all applications automatcally after givern time, what has Microsoft Windows since long time.
“The cutting edge should be fun! If it isn’t, try something else).”
Yes, but not with limited functionality, so I need to stay with X11 to have save and resore Plasma session, till this function will be implemented in Plasma working on Wayland.
LikeLike
Plasma 6 will be released with those features in the X11 session. If those features are important to you, then go ahead and keep using the Plasma X11 session
LikeLike
Now it’s time for Wayland, explicit sync and Vulkan.
LikeLike
Wayland still lacks functionality compared to X11, and it still has a lot of bugs in KDE and GNOME. That’s why I still use X11 instead of Wayland. Besides, I think that everything you wrote here about X11 will be written about Wayland someday.
P.S. Please fix the logo size on invent.kde.org.
LikeLike
Plasma 5 is Xorg made. Wayland is not meant to work in Plasma 5 because the software Wayland has to interface is not Wayland ready. We need to wait for Plasma6 since now it is possible just to look at the first Wayland integration.
LikeLike
X server was designed so that it did not provide a widget toolkit, rather just drawing surfaces. It was the intent for Widgets to be separate, client side, and evolve from the start. Widgets not being in the server was intentional for future proofing, widgets were separate projects to adapt to new needs. Xaw was just the first widget set, was not meant to be an end all or be all, it was the intent that more advanced widgets like Motif Qt etc would come along. X’s philosophies such as mechanism not policy, a client server architecture etc are correct. X has an extension mechanism to address evolving needs. X is well designed and has its merits such as remote desktop through network transparency
LikeLiked by 1 person
the only real limitation is the superiority of Weston compositor to Kwin in Wayland management. Kwin should integrate all the modernity Weston expresses.
LikeLike
That’s just a lie and the whole post is unfair. You can’t port “Photoshop” to “Linux” unless “Linux” has the functionality that “Photoshop” needs. The essence of the “Wayland breaks everything!” is that “Wayland” not only doesn’t yet have the necessary protocols to port some applications, but that it won’t even have them. Because “security”, or “KDE doesn’t need them”. I’m all for finally getting rid of X11. But applications under it need to be able to be ported. Don’t piss users like GNOME liked to do when it removed features without any replacement.
LikeLike
I’d just like to interject for a moment. What you’re referring to as GNU+Linux,
is in fact, PW²+GNU+Linux, or as I’ve recently taken to calling it, PW² and GNU and Linux.
GNU and Linux is not a platform unto itself, but rather another free component
of a fully functioning operating system made useful by the Wayland protocol, PipeWire and Portals comprising a full development target as defined by freedesktop.org. 😉
LikeLiked by 2 people
Best comment award
LikeLike
I’d love to move to Wayland, but just can’t, because I use a KWin rule as an accessibility aid (https://bugs.kde.org/show_bug.cgi?id=470535) and it still doesn’t work on Wayland.
LikeLiked by 1 person
Although I agree with what you wrote, the topic is more complicated and not so nice. Correct me if I’m wrong, but I see Wayland as a two stage project:
1. On Wayland it is the compositors that take a role of window manager, so to switch to Wayland, Kwin and Mutter had to take on this hard job and implement a ton of complicated code. This created a big hurdle for smaller projects, but currently, we are at a better place. Meaning, that Kwin and Mutter are up-to date and Wayland ready, while there are many ready libraries, that can be used by smaller projects to support Wayland. They don’t have to do the work from scratch like Kwin and Mutter had to, and that is why things can go faster from now on.
2. Wayland is just a bunch of protocols, if I understand it correctly. The problem here, and in my opinion this is the biggest issue of the whole project, is that it doesn’t contain all protocols needed and used by modern desktops. Sure, most basic things are there, but there are a lot of obscure things that apps on desktop must do in order to do their jobs. The reason Wayland seems broken and why it is progressing so slowly is because Wayland devs are often acting like small children fighting against new protocols, instead asking “how we are going to do it”, or “when”.
Now that the pressure and deadlines are coming, they need to up their game and stop wasting tiAlthough I agree with what you wrote, the topic is more complicated and not so nice. Correct me if I’m wrong, but I see Wayland as a two stage project:
1. On Wayland it is the compositors that take a role of window manager, so to switch to Wayland, Kwin and Mutter had to take on this hard job and implement a ton of complicated code. This created a big hurdle for smaller projects, but currently, we are at a better place. Meaning, that Kwin and Mutter are up-to date and Wayland ready, while there are many ready libraries, that can be used by smaller projects to support Wayland. They don’t have to do the work from scratch like Kwin and Mutter had to, and that is why things can go faster from now on.
2. Wayland is just a bunch of protocols, if I understand it correctly. The problem here, and in my opinion this is the biggest issue of the whole project, is that it doesn’t contain all protocols needed and used by modern desktops. Sure, most basic things are there, but there are a lot of obscure things that apps on desktop must do in order to do their jobs. The reason Wayland seems broken and why it is progressing so slowly is because Wayland devs are often acting like small children fighting against new protocols, instead asking “how we are going to do it”, or “when”.
Now that the pressure and deadlines are coming, they need to up their game and stop wasting time discussing whether they need to do anything, but how and when to do it, and start making a roadmap.
While protocols are added, compositors will need to update to them, but since compositors are in a good shape and the only thing that needs to catch up is the Wayland project itself.
It is a good that the big guys like RedHat and others are creating pressure. Without it, Wayland devs would still be arguing for infinite hours. Infinite amount of time is not a good thing if you have a job to do. This came to an end, which is a good thing. We enter the awkward phase, where Wayland is being pushed when not being ready, but without it, it would never be ready. We must endure that transition phase. Complaining that it’s broken is just a pretext to not do anything, but that is no longer an option. X11 is still there, but its days are finite.
If you are a dev who see lacks in Wayland protocols, say aloud what is needed and why. Wayland devs require this kind of pressure to see that those things are important.me discussing whether they need to do anything, but how and when to do it, and start making a roadmap.
While protocols are added, compositors will need to update to them, but since compositors are in a good shape and the only thing that needs to catch up is the Wayland project itself.
It is a good that the big guys like RedHat and others are creating pressure. Without it, Wayland devs would still be arguing for infinite hours. Infinite amount of time is not a good thing if you have a job to do. This came to an end, which is a good thing. We enter the awkward phase, where Wayland is being pushed when not being ready, but without it, it would never be ready. We must endure that transition phase. Complaining that it’s broken is just a pretext to not do anything, but that is no longer an option. X11 is still there, but its days are finite.
If you are a dev who see lacks in Wayland protocols, say aloud what is needed and why, so this will be added to the roadmap.
LikeLiked by 2 people
I love your perspective here. While I’m all for Wayland, using it without many issues for years (GNOME on Fedora), reading the negative comments is a bit uncomfortable, but I think it’s all very good during this stage since it creates the necessary pressure and time limit. It’s not only Wayland, but almost every product in life would never exist if we kept chasing perfection without time/cost constraints, so this is a useful thing to see.
Now what we’ve perfected over the course of 15 years, it’s about time we bring it to life. While X11 was generally hacks on top of hacks on top of obsolete one-man decisions made somewhere by some random person, Wayland has been well designed for 15 years now, so it’s time to use all of that work that went into making sure everything is right and build a complete, solid app platform on top of it, with a complete set of standards that cover all common real-world use-cases, as well as extension standards for other niche things, and also start being harsh when core standards aren’t being implemented (e.g. if some compositor refuses to implement some protocol after it has been agreed on, the official Wayland website (whatever it is) could go as far as marking it “non-compliant” and show that to the world of app developers so they know whose fault is that, and to put pressure to respect the core standards).
I think that with the current transition, we’ll see a lot more user-visible progress in the upcoming 2~3 years than there has been in the past 15 years, and we’re already seeing that happen right now with new protocols being pushed, as well as surrounding tools like Portals and PipeWire moving really well alongside Wayland.
I’m a developer myself and I LOVE working on codebases that are well-designed, use modern practices and where the teams behind them communicate very well about everything, and I’m sure this movement in the Linux world in general is gonna bring in a lot more contributors that are excited to contribute to the future of the platform, which could get Linux to a place that macOS and Windows would have to work very hard to reach!
LikeLiked by 1 person
Thanks for sharing your perspective. It’s one I generally agree with, and I also agree with your prediction that we’ll see phenomenal progress in the next 2-3 years as a result of this new more stable and extensible base to build on.
LikeLiked by 1 person
Apple and Microsoft had the good sense to use the consulting services of color management expert Andrew Rodney. I’m guessing Apple and Microsoft product managers made their engineers listen to him, whether they wanted to or not. By contrast, in Linux it has been an multi-year battle to get color management incorporated in Wayland. Is it unfair to say that some key Wayland developers simply didn’t understand what color management experts were trying to communicate to them for several years? Probably not. A most unfortunate situation, from my perspective. It’s a real shame industry leaders did not step up and mandate built-in color management from the beginning of Wayland’s development.
LikeLiked by 1 person
The good thing about X11 was that it had decent inter-operational standards. We had ICCCM and NetWM I was able to run a different window manager within KDE and it just worked. kwin having a history of removing nice features (such as tabs and tiling) was easy to be replaced by something else. This is no longer possible.
I was able to control windows (e.g. resize them, move and center them …) from the command line in a standardized way. If I wrote a script, it worked in KDE (Plasma), in GNOME, in XFCE, with fluxbox, with whatever have you. I was able to do things that window managers were either not capable of or did wrong, and I was sure that it would work, for everyone. We had scriptable tools that could read out properties of windows and they worked, no matter what window manager was currently running. With Wayland this is gone. I am limited by what the compositor exposes, and I can’t write any solutions that will work under different environments. Of course there are base libraries and standards that would support that, such as wlroots, but of course kwin is not based on that (unless kwin-ft, which did the right thing), so obviously all of these tools, libraries and scripts won’t work under KDE Plasma. Wrote a neat little helper? Shame, you have to re-do it for every single environment out there.
X11 was stable as in: it rarely ever crashed. And if more crash prone applications, such as plasma or kwin, crashed, it did not take all my applications and unsaved work with them. They just either auto-restarted or you would restart them. Now of course people say “but Qt6 recenty fixed this”. Yes, for Qt6 applications. Using GIMP to edit your pictures and kwin crashes? Too bad, all your work is gone, forever.
And this, I am afraid, is simply not acceptable. Some people use their computers to do actual work, not to watch pretty animations or the fifth rework of a theme, where this is not a simple “you need to accept this during the transition”. No, no we don’t. If this were cars, industrial machines or anything like that, it would be unacceptable. But unfortunately in the IT world, it somehow became OK that software matures and ripens in (productive) use at the customer/user. And until that is resolved, and I mean all of that, and not just parts and the rest is “work in progress”, X11 is not only not a bad platform, it is the only acceptable platform.
LikeLiked by 2 people
> I was able to control windows (e.g. resize them, move and center them …) from the command line in a standardized way. If I wrote a script, it worked in KDE (Plasma), in GNOME, in XFCE, with fluxbox, with whatever have you. I was able to do things that window managers were either not capable of or did wrong, and I was sure that it would work, for everyone. We had scriptable tools that could read out properties of windows and they worked, no matter what window manager was currently running. With Wayland this is gone. I am limited by what the compositor exposes, and I can’t write any solutions that will work under different environments. Of course there are base libraries and standards that would support that, such as wlroots, but of course kwin is not based on that (unless kwin-ft, which did the right thing), so obviously all of these tools, libraries and scripts won’t work under KDE Plasma. Wrote a neat little helper? Shame, you have to re-do it for every single environment out there.
I will miss that. Xorg seems much more like something made for developers, and Wayland for end users who are only interested in boosting the FPS of their favorite game or need a nanny to grant permissions to features of apps they install themselves.
LikeLiked by 1 person
“I was able to control windows (e.g. resize them, move and center them …) from the command line in a standardized way. If I wrote a script, it worked in KDE (Plasma), in GNOME, in XFCE, with fluxbox, with whatever have you. I was able to do things that window managers were either not capable of or did wrong, and I was sure that it would work, for everyone. We had scriptable tools that could read out properties of windows and they worked, no matter what window manager was currently running. With Wayland this is gone. I am limited by what the compositor exposes, and I can’t write any solutions that will work under different environments. Of course there are base libraries and standards that would support that, such as wlroots, but of course kwin is not based on that (unless kwin-ft, which did the right thing), so obviously all of these tools, libraries and scripts won’t work under KDE Plasma. Wrote a neat little helper? Shame, you have to re-do it for every single environment out there.”
One of the reasons Wayland is supposed to be better than X11 is because programs written for one Wayland compositor behave exactly the same on any Wayland compositors. All mature Wayland compositors (like those of KDE and GNOME) implement the same set of protocols. You either haven’t identified yet how to leverage the Wayland protocols to do what you need, or they are still standardizing the protocols you need. Regarding window positioning, the original post notes that “there are a lot of recent proposals and work around things like remote control, color management, drawing tablet support, and *window positioning*”
LikeLike
Maybe a good name for the platform would be “XDG App Platform” or just FreeDesktop App Platform
LikeLike
Maybe a good name for the PW² platform could be “XDG App Platform” or “FreeDesktop App Platform” or maybe even without the word “app”, although that might be confusing given all the other related things from FreeDesktop
LikeLike
Lets assume that Photoshop would natively run on Linux and Wayland. Color people would still not use it, because you can’t calibrate your monitor with Wayland. For color work you need accurate color display. Wayland doesn’t allow an application to have direct access to the hardware, but you need that for color calibration. There is a long thread on pixls.us about Wayland color management:
https://discuss.pixls.us/t/wayland-color-management/10804
If you have calibrated your monitor with X, it is still a mess getting it working with Wayland.
https://discuss.pixls.us/t/using-darktable-in-wayland-with-color-management/19501
The next thing is, if Distributions are removing X11, you don’t have a way to calibrate your monitor anymore.
LikeLiked by 1 person