Wayland vs. Full Wayland

Brilliant diagram - good find.

I like the graphical overview. The associated wiki page…

That latest wikimedia image is good but is no better than the other diagrams describing whether the compositor is in the X server or Full Wayland, I found something better…

Although I asked in several places but got no definitive answer from a Wayland developer,
I found the following article

The last line in the above article is

Weston listens on the X socket until a client attempts to connect, then launches the X server.

That statement is definitive because Weston exists nowhere else than in Full Wayland…
Full Wayland actually is the main graphics renderer except when traffic is detected through the X Server.
This means that Full Wayland has to be installed and “normal” socket traffic has higher priority except when a connection through the X server is detected.

So, it seems that there should not be any penalty installing XWayland vs Wayland, If the DE fully supports Full Wayland, then whether you install or configure to use XWayland or Full Wayland, your system will operate the same… the X Server would be left dormant and traffic will be only over sockets and things like the WM would not be used (Weston has its own).


That’s debatable.

Although I asked in several places but got no definitive answer from a Wayland developer,
I found the following article

That article already linked to earlier in this thread.

Sorry, I really don’t know what you’re trying to convey here anyway. I think it has already been well enough explained.

‘Full Wayland’ is not a component. There is a Wayland compositor and Xwayland for legacy apps.

I mean no offence, but what you’ve written above is a very confused interpretation of documentation. Admittedly the documents assume quite a lot of familiarity with X11 and especially its history and evolution.

In terms of the big picture, I think my past responses in this thread are accurate and backed up with experiments that can be run from shell scripts.

I think part of the difficulty in understanding Wayland is you need to understand there is no Wayland code in the way there is X11 code. Wayland is only a protocol specification. When running KWin-wayland, there is no Wayland code running, just KWin-wayland code implementing a server for the Wayland protocol, it’s code written 100% by the KDE folk. Don’t get confused by Weston, it’s a totally separate reference implementation of the Wayland specification, and the KDE folk don’t use any of it. There is no Weston in KDE full-Wayland, only KWin-wayland.

Don’t think of Wayland as a full alternative or equivalent to X11, it’s a specification for only a small part of what X11 does. Wayland only specifies the protocols around window management and compositing. The Wayland specification can confine itself to this area because many modern X11 programs don’t use X11 for much more than that. Modern applications do all their 2D/3D drawing via libraries such as Qt/GTK or at a lower level via libraries such as OpenGL/Vulkan, none of these libraries do drawing via X11. That’s why its feasible for KWin to separately implement all of the Wayland protocol, it’s not the same big ugly mess that would need to implement all of X11. That’s why it makes sense to implement a Wayland server inside KDE’s KWin, it’s the logical place for it, it’s the part of KDE responsible for window management and compositing.

As with many (all?) Wayland server implementations, KWin-wayland does use XWayland. Unlike the Wayland protocol specification, XWayland is actual code, it’s xorg code modified to be a Wayland client. XWayland has been created so that any implementation of Wayland can also support programs using more of X11 than Wayland provides (stuff like drawing window content, fonts stuff, and heaps of other stuff no longer in common/universal use). XWayland also helps with the transition to Wayland, if an application trips over too many bugs in the Wayland code paths of Qt/GTK, then just run the X11 code paths under XWayland. Any implementation of a Wayland server, such as Kwin-wayland, can optionally fire up XWayland which then becomes a client of the Kwin-wayland server.

I’m coming at this from the point of a retired UNIX C/C++ developer with some X11, Qt, OpenGL experience. Even a couple of decades ago, many of the services offered by X11 had become of marginal due to the advent of libraries such as Qt and OpenGL. Even back then, all my X11 coding books were gathering dust (I finally got around to giving them to the local dump’s recycling shop last year). I hadn’t previously read much about Wayland. I had the impression Wayland was a bit like fusion power, always decades away, it looks more promising now that I’ve read more about it and run KWin-wayland+XWayland, so perhaps not decades (but maybe years).

I guess we should just agree we cannot agree on our understandings of what Wayland is and leave it at that.

Well said/re-clarified…along with your further explanation. It’s consistent with everything I’ve tested and read about. :slight_smile:

I just tried running KDE with Wayland.
I am on OpenSUSE Leap 15.3 and KDE 5.18

First Plasma (Wayland Full), then I tried Plasma (Wayland).

My multi monitor configuration did not work well with Wayland, in either Partial or Full session.
In Full Wayland even though one of the monitors was configured with a 90 degrees clockwiese orientation, it was still horizontal, and some parts of the main ultrawide monitor leaked into it.

With the partial Wayland session, it even got worse. There I could not even get Spectacle to take a screenshot.

This shows a screenshot when running in Full Wayland.

This being a Tumbleweed thread and also rather old (thus another much older Tumbleweed version) asking here about Leap 15.3 is at least confusing for people thinking they are reading a TW thread and probably also not very useful for you, because who will read a new post at the end of such an old thread (yes, me, but I am a mod reading everything to find spammers).

Better start a fresh thread with a title that hopefully triggers those who may be able to help you to open it.

Also, as I can detect no information from your image, consider uploading images to paste.opensuse.org

Agreed. Closing this thread.