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
