So let’s talk about this Wayland thing

Planning 6 Minutes

Wayland. It comes up a lot: “Bug X fixed in the Plasma Wayland session.” “The Plasma Wayland session has now gained support for feature Y.” And it’s in the news quite a bit lately with the announcement that Fedora KDE is proposing to drop the Plasma X11 session for version 40 and only ship the Plasma Wayland session. I’ve read a lot of nervousness and fear about it lately.

So today, let’s talk about it!

What is Wayland?

Wayland is a set of protocols that govern how a compositor draws stuff on the screen, and how apps interact with the compositor’s drawing-stuff-on-the-screen infrastructure. It’s similar to the HTTP and SMTP protocols that govern how web browsers and email clients send and receive web pages and data.

Wayland also includes an implementation of those protocols in a set of extremely lightweight libraries called libwayland-client and libwayland-server that offer stable and versioned APIs. Apps and compositors such as KDE’s KWin and GNOME’s Mutter use those APIs to do stuff.

Why does Wayland exist?

In a nutshell, because X11–the thing it’s replacing–is dead.

X11 has been in maintenance mode for years, and recently has gotten no real development at all other than changes to the XWayland compatibility system that allows X11 apps to use a Wayland compositor. Having something as central as the window server being unmaintained is a major issue, as it means no bug fixes, no security patches, and no new features to let it keep up with a changing world.

Why did X die?

The fundamental X11 development model was to have a heavyweight window server–called Xorg–which would handle everything, and everyone would use it. Well, in theory there could be others, and at various points in time there were, but in practice writing a new one that isn’t a fork of an old one is nearly impossible. Everyone strongly preferred to standardize on a single X server and migrated in unison from one to another when a better fork became available, because it was convenient. And it was convenient because because it centralized limited development resources, and when a feature was added to the X server, everyone gained access to it automatically.

But there was a drawback: because everyone was using Xorg, any feature added to support any use case could break everything else that everyone else used, and this happened frequently. Bug fixes frequently regressed obscure functionality that others were using.

In essence, Xorg became too large, too complicated, and too fragile to touch without risking breaking the entire Linux ecosystem. It’s stable today because it’s been essentially frozen for years. But that stability has come hand-in-hand with stagnation. As we all know in the tech world, projects that can’t adapt die. Projects that depend on them then die as well.

How is Wayland any better?

Wayland was conceived of by X developers who wanted to avoid repeating their own mistakes. In addition to a lot of technical differences, by being a minimal set of protocols and two extremely thin client and server libraries, all the heavy lifting was delegated to individual compositors, which became the window servers of their environments. A new feature added to one would not destabilize any other compositors. Compositors were also free to implement new features via private protocols outside of the standard ones that apps only targeting that compositor could use.

Wait, that sounds like it sucks

Wayland has not been without its problems, it’s true. Because it was invented by shell-shocked X developers, in my opinion it went too far in the other direction. Wayland’s minimal core protocols are lacking most of the features that non-trivial apps and desktops actually need to work–such as screen locking, screen sharing, cross-app window activation, non-integer scaling, and so on. Compositors all needed to come up with ways to do these things themselves. And that need for each compositor to implement everything itself fragments development efforts and disadvantages small teams without the expertise of heavy-hitting graphics developers. These are real problems and we shouldn’t sweep them under the rug.

Yes, but there are solutions

Over time the minimal core protocols have been extended to cover what’s needed for a Linux desktop and sophisticated apps to work. Much of this work is very recent, driven by KDE, and funded by Blue Systems and Valve Software. So most complaints you read about Wayland missing this or that (such as fractional scaling, or screen sharing, or global shortcuts) from over a year or two ago are likely to be wrong today.

In addition, the problem of fragmentation of effort is being solved by wlroots, a library of Wayland implementations that you can use to build a Wayland compositor. We don’t use it in KDE’s KWin compositor because we already did most of that work ourselves before wlroots existed, but it’s a big benefit to anyone writing a new compositor from scratch today. And there’s a chance we might port KWin to use wlroots in the future.

Why is the adoption taking so long?

The fact that Wayland’s minimal core protocol made it unable to fully replace the thing it aimed to replace was a bad architectural design decision on the part of its authors that crippled the prospect of its rapid adoption when it was released in 2008. We didn’t see the same problem with other newer projects like Systemd and PipeWire which were adopted much faster.

And unfortunately, shepherding new protocols through the approval process to fix this problem is a grueling political exercise. It demands empathy and compromise with people from other projects who approach the problem you’re trying to solve from a fundamentally different perspective. Someone may disagree that the problem is even worth solving. Bikeshedding derails the discussion and everyone gets demoralized and stops working on it. For a long time, the urgency of pushing through it was low because X wasn’t dead yet.

So it took over a 15 years and resulted in Wayland’s dirty laundry being aired in public for that whole time. And that sucks. But… we’re there now. Standard protocols now exist for just about everything anyone needs. The few remaining obvious omissions (like screen color calibration) are being actively worked on as a matter of priority.

“Are we there yet?”

Plasma and KDE apps work great on Wayland, especially in the upcoming Plasma 6 release. Like I said, there are still a few omissions, but those holes are being plugged very quickly these days.

Most 3rd-party apps that aren’t Wayland-native also work fine via the XWayland compatibility layer. But there are some that don’t, because they integrate very deeply into some part of the system in a way that requires X11 support. These need to be ported to use new Wayland APIs.

A lot of app developers became accustomed to tuning out Wayland news while it was still a toy, and didn’t do the porting work. Well, it’s not a toy anymore, and now many are now feeling blindsided by the sudden urgency to port their apps to use Wayland. That’s understandable. But this time it’s for real, and the time to port is now. For any protocols that still aren’t good enough and need revision, app developers’ input is needed to revise them or even propose new ones. This process takes a long time, so better to start sooner rather than later. But it’s not just gonna go away.

Which brings us to Fedora KDE

Fedora has always been a “leading edge” distro that pushes forward the technical state of the art on Linux by adopting new technology once it’s mostly ready, thus causing it rapidly improve in a way that it otherwise would not have. Fedora was the first distro to adopt Systemd, PulseAudio, and PipeWire. It was the first to use the Plasma Wayland session by default. And now Fedora KDE wants to be the first to drop the Plasma X11 session entirely and make everyone use the Plasma Wayland session.

It should be clear that Fedora’s target audience consists of people who are excited about change. If this is you, all of these projects should seem exciting and cool! If not… then Fedora isn’t for you. And that’s fine. The Linux world has approximately five hundred bajillion distros. What’s that you say? Only about 20 of them are any good? Well, fair enough, but even if that pulled-out-of-someone’s-butt number is accurate, there are still 19 distros that aren’t Fedora! Reinstalling your OS is unpleasant, but it’s important to choose the right one that suits your needs and preferences. Choice comes with the responsibility of choosing wisely.

Maybe you’re afraid that Fedora is a “canary in the coalmine” that shows the way everything is going to go. And you wouldn’t be wrong about that, but transitions still take time. Distros that intentionally ship old software like Ubuntu LTS or Debian Stable will let you keep using X11 for years and years. Arch will probably keep shipping X11 for a while too. You have options. By the time Ubuntu LTS removes X11 too, everything will be fully ready.

Putting it all together

Wayland is a replacement for X11, which is dead. Despite a rocky development process, it’s ready enough for Plasma and KDE apps that Fedora KDE is pushing it pretty hard. Many 3rd-party apps are already Wayland-native, but many are not, and they need to put in the work to port to Wayland. If anything they need is still missing, they need to step up to be part of the process of adding it. This process is happening, and isn’t going to stop happening. We need to work together to make it happen faster and more smoothly.

Published by Nate

Published

104 thoughts on “So let’s talk about this Wayland thing”

  1. I’m not a developer, so genuine question: do devs need to port their apps when XWayland exists? It seems to work fine for, like, Steam games, or so I’ve heard, and they seem very complex graphics-wise, in what ways does it still fall short?

    Don’t get me wrong, obviously new apps should be written for Wayland and large code changes in old ones might as well prompt a port, but why should devs care to do the port for the sake of the port itself when there’s a compatibility layer?

    Liked by 1 person

    Reply

    1. Good question: if you’re not doing anything special and largely relying on a toolkit, you probably don’t need to do anything and it’ll just happen for you “for free”. Usually porting comes into play when you run against the edges of what XWayland is allowed to do (or not do, for that matter) and you need to access privileged operations.

      Liked by 1 person

    2. Good question indeed.

      Games are complex graphically, but generally not complex in terms of system integration: they don’t need to do things like pass focus to other windows, register global shortcuts, share the screen to another machine, and so on. Porting to be a native Wayland app lets you use the full set of Wayland desktop integration pieces in a way that either works at all, or is more robust than going through XWayland.

      Liked by 1 person

    4. Nowadays apps are not usually written ‘for X11’ or ‘for wayland’. Most use a toolkit like QT, adwaita unless they do raw display server management job.

      In that case porting is easy. And once ported apps can make use of newer improvements in wayland protocols and in the toolkits. Given X11 is dead, only wayland implementations of comnon tookit libs will get feature updates like gestures.

      Like

    5. Is there any overhead by using XWayland, like does that use more resources from the computer compared to an app written for Wayland? What about XWayland itself, I know zero about it, will it be updated and maintained forever alongside Plasma or is that also old and messy code?

      Like

  3. “the announcement that Fedora KDE 40 will drop the Plasma X11 session” should read “the announcement that the Fedora KDE SIG wants to drop the Plasma X11 session from Fedora KDE 40”. What is the purpose of even having a change approval process if everyone takes the outcome for granted? The proposal is still in the feedback phase. (And that means actually gathering community feedback, which so far has been all negative, as opposed to pre-filling the “Feedback” section of the proposal with rhetorical strawman questions as was done here, resulting in a section that would better be described as “Rationale”.)

    Like

    Reply

    1. In addition, even if the change were to end up approved, the Fedora KDE SIG admitted that they have no authority to prevent others (like me) from packaging Plasma X11 separately, so even then, “Fedora KDE 40 will drop the Plasma X11 session” will likely be false.

      Like

    3. This is not true really. There was some feedback, mainly accessibility and Artist stuff like Graphic Tablet Configuration and color management missing in some pieces. Also lacking support of many especially proprietary Apps lik RealVNC, TeamViewer, etc. really sucks. But the pressure by Fedora etc. is needed, otherwise nothing changes.

      So there are valid points against it, but many approvals.

      Like

  5. > as it means … no security patches

    This is not completely correct. Developers do come and fix some security issues, like that endianess thing.

    > Wayland’s minimal core protocols are lacking most of the features that non-trivial apps and desktops actually need to work…

    This Drew DeVault’s article [1] gives the following perspective: the core is very conservative in order to accomodate various use cases other than Linux desktop and everything else is left to various extensions. I like this design point, since it may open us horizons we’ve never dreamt of in X11 times.

    > We don’t use it in KDE’s KWin compositor

    It may be worth mentioning that there’s KWinFT project which uses wlroots.

    On “Why is the adoption taking so long?” section:

    I think it’s actually good part of the process.

    Firstly, X11 is hard to replace anyway, since porting stuff to Wayland is quite radical change.

    Secondly, as you said, various important extensions need to be worked on. Here, to merge a bunch of ill-defined and broken protocols just for the sake of having them means someone will need to look for some town name for the next windowing system. I see long discussions as proper engineering process. However, Gnome people really need to change their attitude toward other projects.

    Thirdly, there’s indeed no urgency. X11 is still there and works decently for many people. You don’t have any deadlines to meet, so just make good designs that will work for many years ahead. And don’t listen those phoronix/hackernews/lobsters “experts” who claim that long adoption process implies “wayland bad”.

    On Fedora’s decision:

    In their place, I’d to delay this until Fedora 41 or even 42. Plasma 6 is new generation, and I think there will be issues due to massive amount of changes you’ve made, even with all the work you’ve put into ironing things out. So X11 may be useful as a fallback if 6.0 turns to have some crippling issues in Wayland session.

    [1]: https://drewdevault.com/2019/02/10/Wayland-misconceptions-debunked.html

    Like

    Reply

  6. I use the latest LTS of Ubuntu (22.04) but use the default Gnome desktop, not Plasma/KDE. I’m using an LTS because I require a stable, reliable system.

    The install defaulted to use Wayland and it would hard crash the whole system after random periods of several hours. I tried switching the session back to use X11 and it stopped the problem.

    Maybe in 24.04 it will be reliable enough not to regularly tank everything. Until then, I’ll stick with an X11 session.

    Like

    Reply

    1. Similar here – I also use Ubuntu LTS, though Kubuntu here, on an Optimus laptop (Ryzen APU + Nvidia GPU). With the latest HWE stack (with Mesa 23 and Nvidia 435), Wayland doesn’t crash on startup, which is progress. It does however crash upon unplugging a monitor, which happens a lot as my main charger is a USB-C + displayport connected monitor.
      Hopefully that will be fixed by 24.04

      Like

    1. The real fun is reading AMD users complaints on various drivers’ issues and them trying to do machine learning with ROCm.
      Then they take a break to curse Nvidia.

      And btw: removing X session from Fedora sure will make their users who happen to use Nvidia hardware drop… Fedora in favor of any distro run by sane developers.

      Like

    2. Actually I just dropped my nVidia card and bought a cheap second hand AMD FirePro just because I got tired of being “special” with all the nVidia binary driver crap.
      Every time I needed to find how to install this nVidia wonder and every time it was … well this is not supported with nVidia so I was like … screw that.

      Liked by 1 person

  8. You were right about fear. I use Easystroke for gestures, I have hundreds of gestures because I suck with remembering keyboard shortcuts.

    So, for example, if I’m listening to music I can draw an S to open or close Strawberry, I can draw an S with a line through to hide or show it. I can draw a ‘V’ with an attached ‘7’ to set volume to 70%.

    Such a massive part of my desktop experience started with Opera back in maybe 2013 with gestures, which I soon after started using with Gnome and now with KDE…

    But everyone just talks about laptops with touchpads – so I guess I’ll be dead soon too.

    Like

    Reply

  9. As a user who is trying to make the switch, I’m realizing how many “essential” X11-only tools are essentially dead projects, and are unlikely to be ported, but will need re-implemented. Two examples that I use are x11vnc and Redshift (which I use instead of Night Color because it lets me do software brightness on a display that doesn’t properly support DDC/CI – although I’ve seen proposals for some level of software brightness for Plasma 6, which would be fantastic if that happens). It’s one of those things though, where you don’t know what’s missing if you don’t make the jump and try it. And it might be painful for a bit, but it’s just going to take getting people to use it to find and solve those pain points.

    Like

    Reply

  10. I’ve tried Wayland a few months ago – in general it worked very good, no bugs or issues. But screen sharing and recording didn’t work, so I had to switch back to Xorg 😦
    Good to know this is being actively worked on, I’ll try again when new version of Kubuntu comes out.

    Like

    Reply

  11. I’ve frequently seen fedora equated with ubuntu and even recommended to newbies, has fedora ever defined itself as an EXCLUSIVE for “enthusiastic” fanatics to see itself legitimized to kick out the rest so casually?

    Wasn’t mentioned here that the problem is not just some apps not working so many users want to use x11, but that some really need it or even wayland is completely broken for them (*look at the usual culprit, nvidia).

    I think it’s rash and unnecessarily radical, but it’s definitely clear to me that it’s extremely disrespectful to users. Wayland is the future, and it should be the sooner the better, but unfortunately it’s not today.

    Like

    Reply

    1. Spare us your histrionics. Fedora’s policies aren’t “disrespectful” to users let alone “extremely”, and if this proposal passes it will be in line with Fedora’s approach to other technologies as Nate explained. If you think this proposal is too rash and radical, relax and use another distro.

      Liked by 1 person

    2. @skierpage

      lol, obviously yes they are extremely disrespectful, suddenly they want to turn their back on a remarkable part of their users in an arbitrary and senseless way. If you don’t think this is the case, just go to any social media like reddit and see any topic about wayland, there are always a multitude of users with problems including critical ones; also on sites dedicated to fedora or by users with high-end computers.

      But I guess I’m wasting my time with a troll who, far from arguing, essentially just said “, you’re wrong, get lost.” It’s quite pathetic to see that this is what nate likes.

      Like

  12. I’m curious about How far can Wayland go before it becomes the new X that have to be replaced with a new one in the far future cuz the rocky development process that it had.

    Like

    Reply

    1. Yeah, that’s the cycle of computer software in general.

      However Wayland was designed to be easily extensible, which is one of its advantages over X11. It’s just a shame that this extensibility was over-used at launch-time to justify a half-baked core protocol that didn’t have enough in it to replace X11 quickly.

      Liked by 1 person

    2. KWinFT is a hostile fork of KWin authored by a former KWin developer who has irreconcilable differences with the rest of the KWin dev team. So future collaboration, while possible, seems unlikely. And no reinvention of the wheel happened because KWin gained Wayland support before wlroots existed.

      As I said, I think wlroots is a good project, especially for anyone wanting to write a new Wayland compositor today. But porting an old one that already works has a much poorer effort-to-reward ratio. It’s possible that it might make sense in some form, but it’s not on the roadmap right now.

      Like

    3. Reading your blog on how much effort it took to add Wayland features and fix Wayland bugs it appears to me that it would have been much cheaper to do the migration and find a lot of things already implemented and fixed by wlroots. Also KWinFT software development approach focusing on stability and reduction of complexity and maintenance seems much more desirable IMHO and sending money to KDE for KWin development feels like a huge waste.

      Like

    4. It may appear that way, but it’s not accurate, sorry. KWin has the same goals as KWinFT; its developers simply believe those goals are best accomplished in different ways at this point in time. Of course you’re welcome to use and contribute to whichever project you personally prefer.

      Like

  14. Hey thanks for the read. I’m just reporting a minor spelling error.

    After the subtopic Which brings us to Fedora KDE, in the last paragraph on the first sentence, you have it written as “…the way everything it going to go.”

    I believe you meant to say “…the way everything *is* going to go.”

    Thanks again for the article.

    Like

    Reply

  16. In a lot of the media, including print publications for audiences that are mostly retirees, Ubuntu and Fedora are both commonly promoted with the distinction that the latter is more for newer hardware. (Although to be fair, Mint tends to be a default recommendation). So yes, this is likely to be disruptive to a fair number of users running repurposed machines who aren’t technical and mostly just want their computers to work, and it may not be a positive experience for them.

    Like

    Reply

  18. Regarding the question why the adoption of Wayland took so long, for me it seems that the following two additional factors played a role in delaying it:

    1) If I remember this right, Nvidia made a statement at a very early point (maybe even before 2010?) that they didn’t have any plans to support Wayland in their proprietary driver. This eventually has changed only since the last years, and even then there was the problem/additional work caused by Nvidia implementing things in its driver in a different way than Mesa drivers (EGLStreams vs. GBM, see https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-or-not/ ). Since I’m not using Nvidia hardware anymore I can’t tell how well their proprietary driver supports Wayland by now, but my impression is that it’s still a problem for a significant amount of users, and has been a hindrance for many years in the adoption of Wayland, e.g. making it the default session instead of X11.

    2) Canonical/Ubuntu announced in 2013 that they are working on their own X11 successor (Mir), as a direct competition to Wayland. This caused quite some uncertainity about which project will actually establish itself as the successor of X11 for the next years (and which one to support or not), until in April 2017 Canonical eventually dropped their plans (Mir was refactored then to become another Wayland compositor, suited for embedded and kiosk systems etc.).

    So my impression over the years was that the adoption of Wayland may possible have happened faster if there wouldn’t have been that hesitant and peculiar attitude from Nvidia’s side and Canonical’s attempt to push Mir while ignoring Wayland.

    Liked by 2 people

    Reply

    1. I think it’s mainly that it’s ten times harder to sell something that’s been mis-sold in the past. KDE and Nate have the right approach of fixing as much as possible before bringing it back to the table.

      Liked by 1 person

    2. Definitely harder to re-sell something that’s been mis-sold in the past.

      It’s funny because I’m not actually trying to sell Wayland at all, and I feel quite frustrated with many elements of it as well.

      But the writing is on the wall, and it’s the imperfect solution we have, and it’s better than the even more imperfect solution it’s aiming to replace. I see far too many people avoiding getting on the bus and risking being run over by it instead. Even though that bus may not have every amenity you want, surely being on it is better than being under it. 🙂

      Liked by 1 person

    4. Yeah, there are definitely other factors as well. A KWin developer has also informed me that another part of it was the fact that GPU drivers in general needed to be re-done for the Wayland rendering model.

      I think these other factors are kind of side-effects of the other reasons, though. Because Wayland was not able to easily replace X11 immediately by being a superset of its important features and having compatibility with existing drivers, everyone hedged their bets and didn’t adopt it, which led to fragmentation and delay.

      I think it’s a very good lesson that if you want to replace X with Y, you need to make sure Y fully covers everything X can do–or at least, like 95% of it.

      Liked by 1 person

  19. Thanks, Nate, for the nice summary! And thanks for ALL your effort around KDE – much appreciated!

    I have been using KDE now for about 20 years, and the last 8 years or so on Fedora, thus I’m directly affected by this, and I have been through all the VERY rough major version upgrades of KDE as well. Yet, I’m still there and not planning to change any time soon.

    My biggest pain point with KDE on Wayland is the lack of session restore. This kept me for a long time on X11, but my current multiscreen setups with vastly different resolutions force me to use Wayland. I’m kind of between a rock and a hard place with this.

    I know all the bug reports on this in KDE, so I’m familiar with the issue, but I don’t have the capacity to contribute a solution myself. I believe that things like this lead to the overwhelmingly bad publicity that the topic receives – and this wasn’t on the list of issues that are fixed in the article, simply because there is no solution in sight yet! This was also one of the issues brought up in the discussion on the Fedora mailing list.

    Liked by 1 person

    Reply

    1. Well, If im not mistaken, they are already working to fix this issue. There were recent blog post by a KWin dev about a way to suspend applications to hard disk and restore them individually that might allow for even more robust Session Restoration capabilities and few other things too.

      The best part is, this even has an already working prototype implementation.

      Liked by 1 person

  20. I appreciate Fedora’s initiative of moving forward. They push and risk a bit to step in the future and that’s something awesome.

    Been using Plasma Wayland for about a year with amdgpu. No issues at all. Daily driver. I know that are cases which it doesn’t work as good but let’s move forward instead of waiting for everything to be perfect. This is the right pressure to make things to move! Can’t wait for a X11-less distro.

    Liked by 2 people

    Reply

  21. It stinks that there are several issues with Keepass(XC) with global shortcuts, window title detection, and a non-hack secure autotype solution. Keepass is what keeps me on X right now.

    Like

    Reply

    1. Same for me, if that is not solved. I guess I have to leave fedora, which is too bad. I really like fedora and KDE.

      Like

    3. I use KeepassXC in KDE under Wayland on Fedora. Now that clipboard operations work it’s being fine for me. I never adopted those cool-sounding features.

      By design in Wayland apps other than the compositor can’t read other windows’ contents or read/write their input, so the future seem hard to implement without yet more protocols

      Like

    4. I think rather than trying to hammer all those niche features into Wayland compositors, we should have a password manager protocol. It has worked well for mobile OS.

      Like

  22. I feel — probably like a large portion of users — I will going to be forced to do something I don’t feel any need to. Surely the x11->wayland transition will bring lots of problems, bugs, and for some time they could be totally unsolvable. Presently I have not a single problem with my x11 desktop setup, it does everything it should do in the way I expect it does it. Last week at work I’ve installed debian(testing version) from scratch on a PC, and it took me a while to understand that global shortcuts (fundamental feature) not working in plasma (version from last week, not years ago) was due to wayland. Switching to kwin-x11 solved everything. Also, recent benchmarks from phoronix show that wayland is actually slower than x11 in most of the tasks. It all feels like devs are blindly following lofty ideas due to lost of contact with the userbase. IMHO.

    Like

    Reply

    1. Global shortcuts work fine in Plasma Wayland, so I’m not sure what bug you ran into. I hope you submitted a bug report for it instead of bailing to X11 immediately. The fact that this is possible is a major factor that holds back our Wayland support; people encounter a problem, find a workaround, don’t report it, and then it remains a land mine for other people to encounter in the future until a random developer also encounters it.

      Like

  23. Awesome news about Wayland arise and X11 ending.
    Some feedbacks:
    1 KDe ISO Image Writer shows the message that ISO Neon image has not the signature verified because the signature is wrong, even if the signature file is in the same folder of the ISO image;
    2 I have deepened the matter about audio management when multiple audio devices are plugged in back and front audio panel ports. I’ve found that when 3 jacks of a 5.1 audio system are plugged in, the audio manager only shows the 5.1 audio line out system, even if an headphone provided by a mic is plugged into the audio front panel ports and another mic’s jack is plugged in the rear port. How to make visible these last audio devices? Switching the 5.1 surround analog of line out device (the 5.1 audio system) as duplex. Why duplex? Because duplex provides both output and front or rear audio input and just 2 channels of 5.1 audio system. Choosing only stereo profile, the audio manager doesn’t show the microphone or microphones attached. How to got again the line out 5.1 surround system? Switching to 5.1 surround analog profile.
    I don’t know if PIPEWIRE will fix these issues. In this case it is possible to wait for the implementation of this mainly Wayland based software. In any case, I can solve manually switching from 5.1 to duplex in order to avoid to plug an unplug the several jacks of the several audio devices used to make they visible.
    One of the main aim is to make Kwin explicit sync in order to avoid possible hardware issues.

    Like

    Reply

    1. Sorry, are any of those things related to the post? If not, please bring them up somewhere else so we can keep the comments here focus on the topic. Thanks!

      Like

  24. Hey Nate,

    Great job and massive thanks to you and the team!

    Maybe the wrong place to ask, but could the brightness adjuster be changed from exponential to linear?

    On field laptops (used for e.g. military/police/emergency services etc.), the brightness is often 1000 – 1400 nits to make the display readable in sunlight, and KDEs exponential brightness adjustment makes the lower brightness adjustments incredible sensitive. 30%-100% “brightness” setting is extremely bright for indoor use (hurts the eyes), and all the proper adjustments for indoor use occurs between 5%-15% (and therefore each increment (e.g. 5-10%) have too significant brightness change making it difficult to find a comfortable brightness).

    Thanks a lot!

    Like

    Reply

    1. Could you bring this up in a bug report, especially with your specific use case? That would be helpful. As a comment here, it’s likely to get lost since it’s not related to the topic at hand.

      Like

    3. Sorry for spamming, but to clarify. After reading the request, I realize it is like the author states, and the opposite to my initial perception:

      The brightness control is currently linear, but needs to be logarithmic. This since the eye is much more sensitive in dark environments than light.

      So for a normal business/consumer laptop with 350 nits display, each 10% represents a change of 35 nits when linear, which is ok. But for an field service laptop of 1400 nits display, each 10% represents 140 nits change!

      Therefore, 20% brightness on a field service laptop, is equal to a 100% setting for a normal business/consumer laptop, and in dark environments, 140 nits for each 10% change is just far too aggressive. So it needs to be logarithmic: small nits changes until your reach maybe 50%, and beyond 50% results in aggressive nit changes.

      Like

  25. This was a great read, thank you for sharing your perspective! I also appreciate your email reply on this very subject a day or two ago. It’s reassuring to hear that Wayland or more specifically the protocols (or lack thereof) even in the last year or two has improved leaps and bounds. It gives me a lot more confidence in the future of the Linux Desktop overall, that it won’t be hindered and there won’t be conventional use-cases that just “aren’t possible on Wayland, ever.” (such as screen recording/screen sharing, which was broken for a long time).

    The point about private protocols was very interesting as well. I hope in the interest of preventing fragmentation that, should Wayland refuse certain protocols (since Wayland is not necessarily Linux-specific, perhaps they may refuse some Linux-specific cases?), something like wlroots can end up with “common” private protocols that can be shared by Linux Desktops, or serve as a reference implementation for other Wayland compositors.

    I’m sure the transition to Wayland by default won’t be painless, but no transition ever is. Hell, even people transition from i3 to Sway complain, and that’s about as close to drop-in as you’ll get, and Sway is a lot lighter than the full KDE Plasma Desktop suite.

    I’ve been using Plasma Wayland for quite a while now, and really I only have three issues remaining without a workaround, and one extremely minor issue, and one *entirely* irrelevant to KDE Plasma:
    * Missing global menu for GTK Wayland applications (https://bugs.kde.org/show_bug.cgi?id=424485) – No workaround that I’m aware of, without using Xwayland
    * Fullscreen Xwayland applications (games) can’t render at native resolutions without the “Apply scaling themselves” display option, which doesn’t play nice with Wine applications windowed and some other GTK2 applications, and Steam has to be started with its scaling flag set – Workaround is to toggle between “Apply scaling themselves” and to have 2 Steam desktop entries: one with and one without the scale factor. Not really a big deal though. Another workaround is to use SDL_VIDEODRIVER=wayland for games which use newer versions of SDL2, such as Factorio.
    * Steam Overlay doesn’t work with Wayland native games, which will probably get fixed either when the Steam Client is ported to Wayland, or when Wine (and eventually Valve’s Wine fork) has full Wayland support.

    This list was *much* longer back in the Plasma 5.23 days, and it’s been shortened to 1 missing feature, 1 Xwayland limitation, and 1 third-party application limitation. All those issues with panels going missing, Plasma crashing, windows not displaying properly, crashing when waking from sleep, screen recording and screenshots not working, and for the vast majority of cases the artifacting on fractional scaling has all been fixed.

    This is just my perspective on Plasma Wayland, and how for my use-cases at least (heavily gaming, a bunch of programming, and streaming from my media server), Plasma Wayland is 95% of the way there, and outside of Wine and Steam, the huge majority of applications I use are now Wayland-native or can be forced to use Wayland with a launch option. Electron has better Wayland support these days, smooth mouse scrolling is available in VSCodium on Wayland now for example.

    I echo your sentiment, the time to port is now!

    Liked by 2 people

    Reply

  26. tl;dr:

    1. The young developers at X.org don’t understand how X.org works, so they stopped maintaining it
    2. Instead they created Wayland which doesn’t even have basic functions for a desktop
    3. After 15 years they realised Wayland sucked and in the last 2 years they created additional protocols
    4. Despite this, work is slow because the developers do not agree on what to include and what not to
    5. This continually causes bitter arguments and widespread fragmentation
    6. But X11 is dead, long live Wayland!

    The reality is that Wayland is a failed system that will reduce the reliability of Linux on the desktop.

    Like

    Reply

    1. I don’t think you should assume things about the X.Org and Wayland folks. Many of the current developers have been working on graphics since before Linux existed! They are more than qualified to understand the problem domain.

      Liked by 1 person

    3. Nice stand-up comedy. There are no young X11 developers +here are barely any X11 developers(, and the veteran X11 developers created the core Wayland protocol.

      Like

    4. When a single X11 developer created Wayland protocol, he was not so-veteran and Wayland was not intended to replace X11. In fact, then and for a long time, it did not implement basic functions to replace X11. It was just something designed for embedded devices, a much simpler use case.

      Like

  27. I’ve been using Plasma in Wayland most of the time for a few years now.
    For my uses, its advantages far outweigh its minor annoyances.
    In general, it’s a smoother experience and I want to congratulate all developers involved.
    When I still use X11 it’s when I use a wacom tablet with Krita, I feel more comfortable with the wacom X11 driver and also can be more fine-tuned than under Wayland right now.

    Liked by 2 people

    Reply

    1. > When I still use X11 it’s when I use a wacom tablet with Krita, I feel more comfortable with the wacom X11 driver

      Similar experience with the trackpoint of my ThinkPad. Under X11 with evdev, the trackpoint is working perfectly, I can easily hit targets, I can even use it in QGIS and Krita! With libinput and Wayland the behaviour is sluggish, to imprecise for clicking an icon or menu entry. I found an old series of blog posts from a few years ago about the trackpoint and libinput, but in the end no solution.

      The developers of libinput don’t know, how the input values of the trackpoint are processed in evdev and can’t replicate the behaviour in libinput/Wayland. On the other hand, my trackpad works great and better than with the synaptics driver!

      Like

    2. Synaptics and evdev are also dead, replaced with Libinput which was made by their former developer, so it’s a very similar situation. In this case the Synaptics and evdev drivers have been truly dead for years with no releases, no bugfixes, and no new features. Using software that’s bit-rotting is just not an advisable thing to do. It means you’ll be forced to switch at a random time in the future once it finally breaks or stops being shipped by your distro, rather than at a time of your choosing.

      I would strongly recommend submitting detailed bug reports at https://gitlab.freedesktop.org/libinput/libinput/-/issues so that the developer there can fix the issues and make life on Libinput better, not only for you, but also for everyone else.

      This is what I did when I first moved to Linux and found that trackpad movement with Libinput was much worse than it was on macOS. After a year of engagement upstream, it became so much better than I have no more complaints anymore. And back then I was a nobody, so there was no special reason for the developer to listen to me at all. Yet, he did! So there’s no reason why you couldn’t do the same thing.

      Liked by 1 person

    3. @Nate:

      I use Synaptic for two simple reasons:
      1. it has inertial scrolling
      2. it is easily configurable with KDE, much more so than libinput

      KDE on ‘modern’ Wayland does not have kinetic scrolling, whereas using ‘abandoned’ technologies from decades ago, I can have it.

      Among other things, I used to use the abandoned xorg-video-intel which worked fine, better than modesettings, being able to take advantage of 2D acceleration as well. Unfortunately changing computers, with a new intel graphics card, using that driver makes it impractical to take screenshots and screen captures, I am always forced to restart kwin (I do not know whether the problem is therefore more with kwin than with the driver). But if I could I would gladly swap modesetting for the ‘old’ driver, which was faster.

      New does not always mean better.

      Like

    4. guiodic, you’re welcome to use whatever software you want. But you have to accept that it’s unmaintained and might degrade or go away at any time. As long as you do, and don’t complain once it finally happens, I see no problems. 🙂

      Like

    5. Re: bit rot, it does depend on the scenario. Virtual environments, snaps, emulators, Wine, etc. offer a way forwards for quite a lot of cases. Integral parts of the OS or DE less so.

      Like

  28. Wayland remote desktop does not exist. KRFB is nowhere near of X11vnc in terms of performance, it lacks the support of keyboard input and requires local console interaction to get remote session working. How this is even possible in post-pandemic world!?
    Nobody should ever abandon X11 sessions unless they add sensible remote desktop support.

    Like

    Reply

  29. > Standard protocols now exist for just about everything anyone needs
    Ok, it’s enough for wayland to work somehow, but not enough for work effectively.
    Wayland cannot use 2D acceleration, cannot draw 2D effectively. There are numerous X11 implementations, which use hardware-assisted drawing for x11. Even if not and only OpenGL path availible, using Xorg/glamor is more effective, than create OpenGL context in EVERY SINGLE PROCESS.
    For now, to create just simple messagebox without writing every pixel with CPU you need to load mesa, LLVM, and big bloated tookit like qt6 or even gtk4!!! And load different versions if you use flatpak something similar…
    Ok, it is possible to make use wayland without big toolkits, using just cairo, but you will draw every pixel on CPU. While X11 allows all of this at least in single opengl context.
    I understand that most of users will use qt/gtk anyway, but wayland closes any ability to build system without all of this. My setup now uses tqt(TDE), gtk2 and qt5 with blocked glx platform. This renders very fast with X11 network transparency. Even remote browser works fast enough with 100mbit network. And migrating this setup to wayland would be very ineffecive, until wayland have some drawing/render extensions
    It would be possible to make all of this effective. Implement webgl-like rendering as AIGLX alternative. Implement basic drawing, enough to render pixmaps and fonts, cache pixmaps. Implement network transparency, but using drawing protocols, not video compression like waypipe

    Like

    Reply

    1. If you’re using such ancient software as TDE and GTK2, I don’t think you’re in the target audience of Wayland. So feel free to keep using and helping to maintain such an environment–or use it until the rest of the world stops maintaining it because it isn’t considered suitable for modern needs anymore.

      Liked by 1 person

    1. Basically just try it and find out – nobody can really tell you how it will run on your unspecified ancient device.

      Like

    2. I have been running Plasma Wayland on old hardware for some time now.
      My laptop from 2007 works very well with it, on the integrated intel graphics, so I think there is little to worry about.
      At least subjectively, the performance has improved on it after switching to the wayland session.

      Like

  31. Yeah, I use KDE Wayland on my uBlue Bazzite image (which is based on Fedora Kinoite, Nobara, and SteamOS). It’s been fine, I can do my work just fine, I even do Zoom meeting and screensharing my spreadsheet on WPS Office just fine through my Wavebox (Chromium) browser on Ozone Wayland. Screen recording works fine. Everything is smooth and there haven’t been any major crashes once KDE’s caches are done building.

    The only spotty point remains to be remote desktop. TeamViewer works fine in my testing, but TV often flags my setup as commercial (tbf, it kinda is since I use it to connect to the other laptop I have at office running Win10 or vice-versa to my Linux PC at home). RustDesk is a bit behind on that, and AnyDesk doesn’t really work. There’s also Steam with Remote Play and Remote Play Together, but considering Valve’s focus on KDE on Deck as well as wayland-based gamescope-session, it should hopefully be fixed by next year as well.

    Oh, and I guess Global Menu. Global Menu with GTK3, maybe GTK2 as well, would be nice. Qt6’s Global Menu doesn’t work yet, so I have to run OBS on XWayland whenever I need to remux my recording – but that should be fixed in Plasma 6.

    Overall, no ‘showstoppers’ for me anymore, just major annoyances but ones that’s not enough to even make me bother switching back to x11 session unless I really need to.

    Also, while I’m at it, I’m a huge fan of Edmundson’s work — xwaylandvideobridge is a nice stop-gap to have, and the input-method module sounds very exciting!

    Liked by 1 person

    Reply

  33. I’ve been using KDE with WAYLAND for few years now, and things are great for me. Global shortcuts work when I run discord / mumble as flatpak and in X11 window system and Legacy X11 keystrokes at always. It’s not ideal but still better than nothing.

    I’ve disabled capslock and use that as push to talk key, it is a shame that I ‘always’ option is only choise that works with that.

    One thing that I am waiting os input-leap to support wayland as well.

    Amazing work! Thanks 🙂

    Liked by 1 person

    Reply

  34. I’ve been using wayland for almost 2 years now and now I also very rarely ever need to login to an X11 session. I think its almost ready for prime time now. But I have some questions.

    You write:
    “Most 3rd-party apps that aren’t Wayland-native also work fine via the XWayland compatibility layer. But there are some that don’t, because they integrate very deeply into some part of the system in a way that requires X11 support. These need to be ported to use new Wayland APIs.”

    How deep are we talking?
    Will this mean that X11 apps wont be able to say screen share Wayland windows?
    Will it mean that apps like Barrier and Synergy wont work under XWayland?

    I get that X11 will be marked as depricated at some point. But developers need to have a transition period where their old apps are still supported. Otherwise you are sending a signal to app developers that they can expect their apps to suddently not work when the successor to Wayland is eventually released. I get that these very deep X11 integrations will make for some nasty hacky solutions in XWayland and it might even taint the Wayland implementation. But it really is needed. Otherwise app developers and users will ask if this platform is worth the effort.

    Like

    Reply

    1. I briefly answered this in https://pointieststick.com/2023/09/17/so-lets-talk-about-this-wayland-thing/comment-page-1/#comment-38044.

      Barrier and Synergy are examples of very deeply integrating apps will need to be ported or else they won’t work properly. There is a fork called input-leap that will be wayland native for its next release.

      As for screen-sharing Wayland windows from XWayland apps, that’s what we created https://invent.kde.org/system/xwaylandvideobridge for!

      Like

  35. I absolutely require a working cross-platform KVM like one in the barrier/input leap family which by and large have depended on X11. There are some experimental fixes in the works for wayland support but they are not ready yet and functionality routinely just drops.

    My feelings here are mixed as I would really like to go ahead and migrate since it is an eventuality. Plus many new applications are Wayland only. The Fedora decision will likely hold feet to the fire, but could be painful in the short term.

    Like

    Reply

  38. For me the biggest issue is features that require protocol extensions take to long. There’s to much talking and arguing, instead of talking about the specific issue they argue about the validity of the extension.
    I see such behavior especially on the GNOME or GTK side of things.

    One other issue is that GTK kills apps from the inside when it thinks that they have lost connection.
    GDK (part of GTK) calls _exit() which prevents apps from even saving their data before they exit.

    Like

    Reply

  39. This video is ten years old, but really interesting with regard to the background of both X and Wayland, and the logic behind replacing X. Also understandable by the non-programmer.

    [Linux.conf.au 2013] – The real story behind Wayland and X

    Liked by 1 person

    Reply

    1. An excellent video indeed.

      I think it probably needs an update, though. Daniel is mostly complaining about why X is bad (which is all true) and why Wayland is better, but he doesn’t really address any of the challenges involved in porting software to Wayland. That’s been the elephant in the room for years. A decade after he gave that talk, we’re still not in a position where Wayland has taken over the FOSS world; we’re only right now getting to the point where it’s even possible in the first place. It begs the obvious question of what wet wrong and why it took so long, and that’s what I’ve been trying to address in this blog post.

      Like

  40. I’m using Linux since 2004 and I’ve always used KDE/Plasma with X11. Since 2012 I’m using archlinux. Two years ago when I bought my first 2-in-1 laptop, Wayland was not working at all (from my point of view at least on that pc) and moreover the onboard virtual keyboard was and is way better than maliit (which is the only virtual keyboard that can be used on plasma Wayland due to current incompatibilities between different Wayland compositors). Now I bought a new 2-in-1 and I had to switch to Wayland again to be able to use different scaling for different monitor. I admit that now Wayland seems to work properly and to scale correctly the two monitors, but still the maliit issue is there and there is no alternative because kwin still doesn’t implements some protocols needed by other Wayland virtual keyboard to (for example squeekboard). On the other side onboard under xwayland does not work because typing has no effect.
    So it seems that at least for all users of surface like pc Wayland is still not there and more generally we have lost the possibility to use some tools from other de due to incompatibilities of Wayland compositors. How are you going to fix this virtual keyboard problem?

    Like

    Reply

    1. Yes, I totally get what you’re saying. We’re not super satisfied with Maliit ourselves. There’s a chance in the future that we’ll end up either supporting other virtual keyboards, or even writing our own.

      Like

  41. Sorry to up old discussion. Is there a way to start multiple XWayland’s for a KWin (:0, :1, etc)? The reasons are quite simple:

    This will allow to run some apps at native max screen resolution, some upscaled from 96 DPI.

    Running new XWayland after KWin launch will allow to start it with NVidia blob and stop it when it’s no longer needed with full nvidia off (modprobe -r). Right now I can do this only with Plasma session restart.

    Like

    Reply

Leave a comment