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

[MrCooper]

But applications cannot, applications can't even get any detail about the basic graphic environment they run in (at least not from the wayland protocol).

It won't work like that. Instead, Wayland clients will tell the compositor how to interpret the colour values of a Wayland surface via the colour management protocol being worked on. Then the compositor can display the surface contents correctly under all circumstances.

In the meantime, surface colour values are always interpreted as sRGB.

Aint that the biscuit. Which wayland compositor exactly, and does it run KDE and gnome? does anyone know or care?[...]

KDE and GNOME each have their own Wayland compositors. GNOME's mutter doesn't support DRM leasing yet, there are people working on it though. Don't know the status of KDE's kwin offhand.

From my testing mid June this year.
"no tearing wayland" adds a minimum cap to the input latancy,

The Wayland protocol doesn't incur any latency other than for sending and processing protocol messages via a UNIX domain socket between compositor and client. This should be comparable to a local X11 display connection.

The effective latency is determined mostly by the display refresh rate and the compositor and client implementations.

typically in the 20 to 30ms range, depending on how fast the CPU is.
tearing wayland adds about 10ms

It's unclear what exactly you measured, but that doesn't sound anywhere near what's possible.

Note that the nvidia driver is known not to work great with Wayland at this point. In particular, it doesn't report usable timestamps via the KMS API (which aren't really optional), so a Wayland compositor has to "fly blind" in terms of frame scheduling, which likely results in higher latency than possible.

X11 input latency runs in the nanosecond range always,

Do tell how you measured that nanosecond latency.

That's just not possible in any way for application window updates with today's hardware.

If you mean the latency between movement of the mouse and cursor, the latest releases of mutter & kwin have improvements for that specifically.

vsync on or not

With vsync, the average input → output latency can't be lower than half the duration of a display refresh cycle, i.e. >= 8-9 ms at 60 Hz refresh rate.

[schmidtbag]

Xorg upstream is dead (anyone can easily confirm that by checking the xserver Git history) and can be uninstalled without most Fedora users noticing it's gone. X clients will be supported on Wayland forever via Xwayland.

But Xwayland depends on xserver. So, not even Fedora users could uninstall xserver without issues. There are still too many programs that depend on Xwayland. Just because Xorg is no longer actively developing, doesn't mean it's dead.

[mSparks]

KDE and GNOME each have their own Wayland compositors. GNOME's mutter doesn't support DRM leasing yet, there are people working on it though. Don't know the status of KDE's kwin offhand.

Which is probably the #1 reason 3rd party apps are so disinterested.
There needs to be a very compelling reason to support multiple targets. "IBM execs that probably don't even know how to code would like to replace X11 with Wayland" is not a compelling reason, especially when "build it for X11 and it runs flawlessly with zero support overhead pretty much everywhere" is the alternative.

[royce]

My personal experience after nearly 4 years using Sway is that everything I need to work, works. Screen recording and sharing, inputs, clipboard, all fine. Mixed spec monitors working well without tearing and without scaling problems. I just have done a quick review of all the graphical apps I use and only the Jetbrains IDEs aren't wayland-native, and that's changing as we speak. All in all I stopped working around issues a good 2 years ago if I look at my dotfile history, and the last ones were mostly for apps that work weird with tiling window managers, not wayland or xorg related.

[avis]

But Xwayland depends on xserver. So, not even Fedora users could uninstall xserver without issues. There are still too many programs that depend on Xwayland. Just because Xorg is no longer actively developing, doesn't mean it's dead.

XWayland doesn't depend on the Xorg server at all. The first one can be installed alone.

[mSparks]

XWayland doesn't depend on the Xorg server at all. The first one can be installed alone.

xwayland is xorg-server, but recompiled to draw to a wayland compositor instead of directly to the screen.

[avis]

xwayland is xorg-server, but recompiled to draw to a wayland compositor instead of directly to the screen.

Compiled with Wayland flags working only under Wayland. The standalone server drives real hardware instead.

[mSparks]

Compiled with Wayland flags working only under Wayland. The standalone server drives real hardware instead.

Compiled with all the bugs and CVEs of xorg-server, but NONE of the advantages - like low latency and independant compositor.

In fact, reflecting on it, the #1 fundamental problem with wayland is no one developing for it seems to know what the "unix philosophy" is. Which is almost certainly why development is taking orders of magnitude longer than it did for X and it is such a buggy POS.

[avis]

Compiled with all the bugs and CVEs of xorg-server, but NONE of the advantages - like low latency and independant compositor.

In fact, reflecting on it, the #1 fundamental problem with wayland is no one developing for it seems to know what the "unix philosophy" is. Which is almost certainly why development is taking orders of magnitude longer than it did for X and it is such a buggy POS.

Now that XWayland is a userspace application there's a lot less to worry about. In the past hacking it would give you root credentials.

[mSparks]

Now that XWayland is a userspace application there's a lot less to worry about. In the past hacking it would give you root credentials.

A perfect demonstration of a complete lack of understanding of the POSIX architecture.

That is a linux permissions problem (if it was true, which is highly controversial), not a display server problem. You can't fix POSIX permission problems by changing the display server, any more than you can change the tire on your car by having the local authority resurface the road.