KDE On Wayland: "The Biggest Thing Needed Now Is Adoption By 3rd Party Apps"

[avis]

- Pipewire is a 100% drop-in replacement for Pulseaudio. No effort is needed to make the transition. Transiting from ALSA to Pulseaudio, now that was another story written in flamewars.
- Vulkan does not care about compatibility at all, nor does it have to.
- Glibc used to be at the core of many heated arguments, especially when it was maintained by Ulrich Drepper. In fact, birdie/avis/<***> used to quote a technically incompetent report how glibc is so bad that it leaks memory by design (no, it does not).
- Problems that Wine/DXVK have to solve have zero technical parallels with those of Wayland. Therefore, it does not work as an example here.

Don't worry, this is just birdie posting fake-news kind of arguments and you took the bait. It happened to the best of us.

Heated arguments or not about glibc, it maintained perfect backward compatibility. And you still remember that glibc story, lol. The issue is, glibc does leak memory when it becomes fragmented, the issue has never been resolved. Some applications have changed the memory allocator, some changed allocations, but the issue is still there.

PulseAudio transition was rough because RedHat tried to push something which was far from ready. PipeWire transition on the other hand was a walk in the park.

What's funny and sad about your weak "rebuttal" is that you tried to use the word "fake-news" and there was nothing fake-newsy in my post. None. Try to find the courage to talk strictly about technical details - there's no need to involve tropes and cheap platitudes like fake-news or anything like that.

I try to be technical whenever possible but I make mistakes and I happily admit that.

[mSparks]

Heated arguments or not about glibc, it maintained perfect backward compatibility. And you still remember that glibc story, lol. The issue is, glibc does leak memory when it becomes fragmented, the issue has never been resolved. Some applications have changed the memory allocator, some changed allocations, but the issue is still there.

PulseAudio transition was rough because RedHat tried to push something which was far from ready. PipeWire transition on the other hand was a walk in the park.

What's funny and sad about your weak "rebuttal" is that you tried to use the word "fake-news" and there was nothing fake-newsy in my post. None. Try to find the courage to talk strictly about technical details - there's no need to involve tropes and cheap platitudes like fake-news or anything like that.

I try to be technical whenever possible but I make mistakes and I happily admit that.

Fun fact
I still have to use a nasty alsa console gui to configure my audio. because configuring 5.1 out setup isn't supported by pulseaudio or pipiewire (you can now chose it once it is setup, just not actually enable it initially)

[billyswong]

But its adoption by the bigger players with enough resources does imply it is better. So should the whole desktop stack never migrate to a superior solution because some projects don't have the resources?

There is a 4. option that you did not list:
4. Migrate to Wayland in a longer timeframe they can manage with their limited resources (e.g. the same approach that XFCE is taking). It's not like X is going to magically stop working when Wayland becomes the standard. At most it will need a couple of one-liner patches from time to time to keep it working with newer compilers, maybe a security fix or two. Distros will probably do this work.

EDIT:
One more thing. If "X.Org is warning everyone for their end of support", then it is not Wayland killing off X, it is X killing itself. It is not like Wayland devs can force X devs to stop working on their own project. If X devs are giving up support, it means they themselves think X has been finally superseded.

Wayland devs and X.Org devs are the same group of people since the beginning. You are right that "X killing itself". There is no "force" behind as Wayland is an attempt for old X.Org devs to self-suicide the project right from the start. But then also because of this, there is bias in determining if Wayland is really good enough for the abandonment of X to truly occur.

[mSparks]

Wayland devs and X.Org devs are the same group of people since the beginning. You are right that "X killing itself". There is no "force" behind as Wayland is an attempt for old X.Org devs to self-suicide the project right from the start. But then also because of this, there is bias in determining if Wayland is really good enough for the abandonment of X to truly occur.

They absolutely know it isnt good enough to abandon X.
The politics here is they are 100% willing to break everyones systems using FC40 in an attempt to understand why only 5 or 6 people who post on phoronix are using it.

[ultimA]

Wayland devs and X.Org devs are the same group of people since the beginning. You are right that "X killing itself". There is no "force" behind as Wayland is an attempt for old X.Org devs to self-suicide the project right from the start. But then also because of this, there is bias in determining if Wayland is really good enough for the abandonment of X to truly occur.

I don't think that's quite true. It is true that Wayland was started by former X-developer Kristian Hogsberg, and I'm sure there are other overlaps too (like Peter Hutterer), but if you look at the list of changes within release announcements of Wayland and the various X-subprojects, there is surprisingly little in common among the people.

[kiffmet]

Color calibration support
multiple screen support
VR support
screen recording and streaming support
nvidia support
remote application and ssh forwarding support
high fps support
not requiring a reboot because it crashes every 5 minutes support
mouse cursor support (it doesnt tear, but it does take 3 seconds to move)
actually being better than X11 in any way support

But hey, no one needs any of that right, so ditch X11 now and bet your house on writing wayland apps, because.....

(...)

Out of those, these work perfectly fine by now:

• multiple screen support - currently using a mixed-DPI setup, both screens receive different scale factors
• screen recording and streaming support - has been working for a good year and a half now
• remote application and ssh forwarding support - waypipe…
• high fps support - has never been an issue
• not requiring a reboot because it crashes every 5 minutes support - currently 10 days of continuous uptime without a single crash
• mouse cursor support (it doesnt tear, but it does take 3 seconds to move) - don't use a 24hz display then or use a compositor that doesn't use tripple buffering and/or let you prefer latency
• actually being better than X11 in any way - Xorg can't do different scale factors simultanously, nor can it support VRR on multiple screens with different refresh rates

Maybe get a less outdated list of issues the next time, instead of regurgitating half-truths from over 2 years ago.

[ultimA]

Out of those, these work perfectly fine by now:

• multiple screen support - currently using a mixed-DPI setup, both screens receive different scale factors
• screen recording and streaming support - has been working for a good year and a half now
• remote application and ssh forwarding support - waypipe…
• high fps support - has never been an issue
• not requiring a reboot because it crashes every 5 minutes support - currently 10 days of continuous uptime without a single crash
• mouse cursor support (it doesnt tear, but it does take 3 seconds to move) - don't use a 24hz display then or use a compositor that doesn't use tripple buffering and/or let you prefer latency
• actually being better than X11 in any way - Xorg can't do different scale factors simultanously, nor can it support VRR on multiple screens with different refresh rates

Maybe get a less outdated list of issues the next time, instead of regurgitating half-truths from over 2 years ago.

The Arch wiki states that even color calibration works in Wayland now if you're not afraid to use the commandline. Only a GUI is missing to manage it. Haven't tried it myself.

[MorrisS.]

Many thanks for the X11/Xorg obliteration, finally! Now it's time for Vulkan and explicit sync, making Opengl deprecated.

Users provided by legacy hardware will be able to preserve legacy operating system based on X11. So, no dramatization but Linux Oses cannot be compromised because of antiquates hardware preventing Linux from a proper evolution.

[oiaohm]

Sounds like the ops problem is already solved then, there is plenty of chromeos 3rd party apps.

mSparks you missed something.
surfaceflinger api to wayland backend exists in Android code. This is what used under chromeos and waydriod. Google if they wanted could ship a wayland compositor instead of surfaceflinger on all future android phones and have this work.

The android userspace has no problems working in Wayland environment.

Yes back before 2019 running android applications on top of wayland you had to run surfaceflinger because the hardware compositor backed code was being replaced not the compositor itself. Google with chromeos to support android applications did something surprisingly different of making android applications work without android compositor. Of course you still need a container around android applications because it still uses Linux kernel features different to normal Linux desktop applications.

mSparks should have been when major android device vendors decide to ship with a custom Wayland compositor instead of the google provided android compositor.

Android AOSP level already support Wayland. Installed out the box configurations you don't see Wayland compositors a lot. So like it or not mSpark what you wrote was in fact wrong. What you wrote is like saying KDE/Gnome back in day did not have Wayland support because all distributions were by default shipping with X11. Yes the android case is by default majority of distributions being device makers are shipping with surfaceflinger instead of the Wayland option the android code has.

[oiaohm]

Many thanks for the X11/Xorg obliteration, finally! Now it's time for Vulkan and explicit sync, making Opengl deprecated.

There is a problem

https://www.supergoodcode.com/presenting/

Now one thing to note here is that the DRI frontend uses implicit sync, which means drivers are allowed to do some tricks to avoid extra operations related to swapchain fencing. VK WSI, however, uses explicit sync, which means all these tricks are still totally legalNOT AT ALL LEGAL. This means that, in a sense, VK WSI will always be slightly slower. Probably less than 10,000ns per frame, but, again, this is significant when running at extreme framerates.

Yes from June 23, 2023.

Something that is not talked about that explicit sync is not always faster. Explicit sync forbids the kernel mode driver from doing particular operation optimizations. Yes handing all the stuff to the kernel driver and saying here order them how you like you know what order I gave them to your you know when they should appear because of implicit sync can give some horrible amounts of performance advantage due to not requiring application to track sync data or application developer to get sync data correct..

Yes developer of Zink has found a few problems with explicit sync. There is upside and downsides to explicit sync. The upside and downside of implicit sync is that you allow the kernel graphics driver to order the operations of rendering how ever it sees as the best allocation of GPU time.

Explicit sync has the same problem as "micromanaging boss" up to a point this improves performance but past a particular point this massively hurts performance.

Yes Implicit sync is like "lack of boss management"(opengl) and Explicit sync is a "micromanaging boss"(vulkan) we don't have the good middle ground of just right amount of management.