X.Org's Modesetting Driver Flips Off Atomic By Default

[JMB9]

I am absolutely sure Red Hat would not dare to force RHEL/RHD users to use Wayland yet - as it is not mature and experts do know it.
Wayland may be suitable for a special workflow, and this is fine. And it is not astonishing that people working on Fedora are content.
I would never be able to work effectively with Fedora - even better with RHEL. And that is not coming by chance.
GNOME 3 was an extreme mess when well known people of the community must stand up and declare that this DE is not usable for effective workflows.
Maybe this has to repeat with Wayland, as extremely important features are still in the making and stability is not there.
Wayland may be the future - like it was said for IA-64 {Itanium} - a clean 64 bit system even I was interested to use it when first heard of.
Wayland must prove that it is capable of all workflows and is in all cases more stable than any existing X usage to be worth entering long term/enterprise usage (LTS, EL or ES) systems.
Maybe it will be decided and forced to users - but this would be a really bad idea at this stage and will damage desktop Linux further.
The current situation, that X is the standard and no one cares to get fixes through, is bad ... and harmful to Linux.
I hope that people step up and at least help to get necessary patches come thought even one year after Wayland got the skills it needs to become the new standard. And I guess we are more than two years from that point in time. Wayland can not be improved by forcing X to rotten.

[caligula]

It's fair to say that the crash rate is several times higher with Wayland compositors than vs. Xorg, likely even on Intel GPUs.
Currently, I just have to close some xwayland fullscreen games on Plasma, and everything hangs to death, leading to hard reset with potential data loss (already got some game savegames corrupted).

I'd blame the game devs. Even crappy spinning rust drives write 20 MB/s and many saved games are far less than 20 MB in size. So you could serialize everything in-memory, then store the blob to disk when the engine is hardly doing anything else. You can pretty much guarantee that it won't crash during writes.

[Britoid]

I think they have X-server support on the lxc's . Oh wait, it reports the displays XWAYLAND0 and XWAYLAND1.
And that's on an arm chromebook with chromeos.

ChromeOS ships with a Wayland display server for native-Linux apps.

[libv]

Atomic modesetting is not atomic at all. It is batched modesetting. And it is only a very limited property/attribute system to boot, only really meant to provide display compositing a-la hwcomposer.

[Vistaus]

It's sad that the X.Org codebase is wasting away when Wayland is still 2-3 years away from being remotely usable on a day-to-day basis. I run Wayland as my main session, but that's because the obvious responsiveness increase is worth the constant visual glitches and application crashes to me. Every time an application crashes because it failed to draw a popup properly, I think to myself "Wayland was stable 4-5 years ago" and sigh.

Wayland is technically superior, but at this point is it even worth all the freaking effort? It's like the entire community is trying to force vaporware into being reality, and it's not going very well.

Wayland is fine for the most part, but Plasma on Wayland is still very much unusable on my 2017/2018 Intel-only hardware.

[Vistaus]

I do use Wayland nowadays on all my devices, but at least Kwin's state is currently not really progressing, it is usable if you know how to avoid certain pitfalls, but bugs do not get addressed timely at all. Wayland itself is fine and it solves many issues of x11, but it should get proper first class support from all developers now. Several times I've received bad or no feedback from developers if asking for Wayland support in their application.

Exactly! However, KWin on X11 isn't really good either. kwis-lowlatency solves most of the issues, but not all of them. Trinity with its TWin window manager (based on KWin 3.x) is much, much leaner: there's no stutter, no lag, no nothing. Even Vivaldi performs 100% smooth (whereas it performs 97% smooth under KWin/Plasma 5).

[duby229]

JMB9 RHEL 8 moved to wayland.

Stability and features depend on the compositor, not wayland (protocol).

People should stop using experimental compositors and then blame the protocol.

Can I blame the protocol for not incorporating almost anything a compositor needs then? Maybe it shouldn't be the compositors job to re-invent every single wheel....

[duby229]

duby229 Not really. The wayland scope has always been limited. You can blame yourself for not realizing this.

You are free to use or hack alternative protocols..

Opinions vary I suppose. Waylands scope is far too limited, I realized that a long time ago. It's the whole reason why it took Gnome so long, why Plasma is still buggy and why even Weston, the reference compositor, is still incomplete.... (It's the reason why Xwayland is -still- the -only- way more or less every desktop application works on wayland.)

[johnc]

Awesome logic in this thread.

"Hey guys I'm a user and this thing is completely unusable."

"Hey that's your fault! Everything works great for me!"

This is why people use Windows and Mac. It's just a far, far superior user experience than any of the half-crippled, third-world Linux crap that's out there.

[duby229]

duby229 Mutter works for me. And I’m happy they didn’t need to engage with toxic devs from experimental compositors.

Of course that's only if you consider -every- compositor "experimental" (including the actual reference) (and every dev toxic) and choose to ignore that it took Mutter a -decade- to get this far...