Re: [gentoo-user] Re: Wayland - too early to try?

[Mart Raudsepp]

Random information dump on the subject.

Wayland is no program, it is a protocol, that's it. dev-libs/wayland is
essentially a helper library to speak that IPC protocol.

The window manager has to be the compositor and other things as well
and do the input handling, window drawing, screenshot support, screen
capture support, etc etc.
Random programs can not take screenshots, listen to keys (think global
keys, e.g outside desktop shortcuts/push2talk voip) without some
protocol between the WM and the program. The Xorg programs for that
essentially make use of Xorg design security issues to do stuff like
take screenshots (random program can see your whole desktop screen with
Xorg), listen to input (keyloggers are trivial with Xorg), etc.
There are some standardization efforts going on between the desktop in
various areas of this, to define wayland protocols to more securely
support these things for applications. In some areas things are still
lacking.

To detect native wayland vs Xwayland or Xorg I like to use xprop.
Running that command and clicking it on a window will give information
about that window IFF it's using Xwayland or your whole session is in
Xorg.
But if you are still using Xorg, then you'll have a /usr/bin/X running.
There is no X running with a wayland WM, just Xwayland at most for
programs that don't support wayland natively.
Xwayland is a rootless X server to run on top of a wayland supporting
compositor. It's conceptually the same like Xquartz or Xming to run X11
clients in some other environment.

Wayland strives towards the "every frame is perfect" mantra. It is very
hard for toolkits and other things to draw things halfway on monitor
scan-out, so things like tearing are rather hard to accomplish, albeit
possible still in certain situations.

With wayland your programs need to do all the drawing themselves, which
actually means often pure software rendering, but thanks to the
smoothness of "every frame is perfect", it'll feel faster on your
common system. You don't have RENDER extension to do some acceleration
like you do in Xorg with many toolkits knowing about X RENDER (cairo in
the gtk+ world). To get hardware acceleration, the toolkit itself needs
to be able to use OpenGL (full or GLES), Vulkan, or similar. GTK+ 4
will be able to do both. Games typically already use OpenGL or Vulkan
and if they run natively on Wayland, they are still accelerated, often
with some things out of the way compared to Xorg. Programs that don't
run natively and end up using Xwayland are also accelerated via RENDER,
as Xwayland makes use of GLAMOR, which implements RENDER in the
(Xwayland rootless) X server on top of OpenGL. But as said, in practice
things are fast and smooth already as-is, even if software rendering.

One caveat of Wayland is that if the WM/compositor crashes, your whole
graphical session dies, while with Xorg the WM typically just restarts
and for the session to die, Xorg itself would have to die (and that's
been ironed out over the decades to very rarely do).

GNOME is indeed one of the leaders in adoption and implementing various
extra features on top of it (even middle-click PRIMARY paste,
seriously). EFL is probably another, and I think plasma is getting
there. And then you have the dedicated wayland compositors like Sway (a
i3-compatible approach). I bet there are something similar openbox-like 
out there as well, but openbox itself definitely won't work, as it'd
have to be the compositor and not talk libX11..


HTH,
but probably you should have just googled ;)


Mart