Wayland Protocols v1.0 Released

[ElectricPrism]

Despite having spent quite a bit of time reading up on this, I'm still confused by the whole Wayland concept. For example, I thought Wayland was the protocol, but now the Wayland protocol has been split off from Wayland? What is Wayland then? I also find that when I'm trying to explain what Wayland is to other linux users not familiar with graphics I don't do a good job of explaining what the role of the protocol is. This indicates that I don't really understand it myself. Does anyone have a reference that explains all this in detail, or is this another case of you have to read the code to get it?

Wayland is likened to TCP/IP or UDP or HTTP or FTP or SSH all of which are protocols - my understanding is that it's like a blueprint for a house, however in this case it defines a data structure.

Weston is a compositor, KWin is the Compositor for KDE. Mutter is the Compositor for Gnome, SteamOS has its own custom Compositor (I forgot the name.)

It's like how POP/IMAP are protcols shared by Yahoo, Gmail, etc... and yet the user experience is 100% different.

X is not a protocol (as I understand it.) X is a display server designed to have displays that are local and remote - meaning a Client - say a Jolla Tablet could run a display connected via the Network to a Mainframe where all the files / processing & gpu calculations are done.

Another comparison might be how SSH is a protocol and OpenSSH is a binary application that implements SSH protocol specifications.

(My statement may contain errors, if so feel free to quote me and cross out or bold fixes.)

[ssokolow]

X is not a protocol (as I understand it.) X is a display server designed to have displays that are local and remote - meaning a Client - say a Jolla Tablet could run a display connected via the Network to a Mainframe where all the files / processing & gpu calculations are done.

X is a protocol... it's just suffered under so much politicking that it's an ancient core protocol bodged into semi-modernity by a forest of extensions and 99% of users rely on a single vendor (X.org) for their implementation.

This YouTube vid explains the difference between the X and Wayland protocols well.

https://www.youtube.com/watch?v=RIctzAQOe44

(The short version is, they've replaced so much of X's functionality with extensions that, on composited desktops with modern widget toolkits and a shared memory transport, the X server has become nothing more than an IPC system that's terrible by any possible metric and which allows any application to snoop on or manipulate any other application.)

[Daktyl198]

Wait wait wait... Isn't there:
Wayland: the set of protocols. Similar to X11

libwayland: the code that actually implements the core Wayland protocols. Mostly IPC and data moving stuff between the compositor and the graphics stack, right? This is what most people forget about. Similar to X.org in terms of where it stands in the ladder.

Weston: The reference compositor. The code that other compositors can use to see how to properly interact with libwayland and the Wayland protocols on a basic level. This is on the same level as Mutter, KWin, etc.

At least that's how I've always seen it. If anybody who's actually looked over their git and thus knows wtf they're talking about could correct me if I'm wrong, that'd be great... because I'm seeing a lot of posts that are conflicting, or just straight up wrong on this site and it's starting to make me sad knowing people might walk away with the wrong info.

[giucam]

libwayland: the code that actually implements the core Wayland protocols. Mostly IPC and data moving stuff between the compositor and the graphics stack, right? This is what most people forget about. Similar to X.org in terms of where it stands in the ladder.

No, that's similar to xlib/xcb. What used to be done by the Xorg process is now done by the compositors, i.e. weston, mutter, ...

[Daktyl198]

No, that's similar to xlib/xcb. What used to be done by the Xorg process is now done by the compositors, i.e. weston, mutter, ...

Yeah, that's why I said "where it stands in the ladder" meaning it's place in the structure. Not really talking about functionality.

E.g. now it's something like (very roughly):
$screen = everything hardware/buffer related to get a picture on your monitor

$screen <> X.org (implementing X11 spec) <> WM/Compositor (KWin, Mutter, etc)

And with Wayland it's something like:
$screen <> libwayland (implementing Wayland spec) <> Compositor (Weston, KWin, Mutter, etc)

Right? Though the compositor is more involved in what libwayland does than the compositor is with X.org right now, so it'd probably be more accurate to have those "levels" overlapped a bit.

Or I could be talking out my ass. This is what I've been able to pick up so far within all of the articles and comments contradicting each other *shrug*

[pjezek]

Anything in git is not a production version! Separate development of wayland independent on its demonstrator Weston is the only reasonable way how to speed up for reaching a stable Wayland not only for non-PC applications. Those having developed some crutial SW could understand...

[pq__]

And with Wayland it's something like:
$screen <> libwayland (implementing Wayland spec) <> Compositor (Weston, KWin, Mutter, etc)

Libwayland (neither server nor client side library) has nothing to do with hardware, or drivers, or rendering. It is merely an IPC between a Wayland compositor (a display server) and a Wayland client (an application). Every compositor talks to the display and input hardware through everything *except* Wayland or libwayland.

So your stack looks like this:
hardware <-> Linux kernel/drivers <-> libinput, Mesa/drivers, libdrm, ... <-> compositor
No Wayland there at all.

Wayland comes up here:
compositor <-> application
Wayland is the IPC system between a compositor and an application. Furthermore, libwayland does not actually implement anything, it is only a helper to pass messages from one process to another without any actual execution of these messages. Wayland provides a common language, and libwayland provides a nice way to speak that language. All the action is elsewhere.

If that makes Wayland look like a tiny piece in the whole picture, that's because it is. At least in lines of code. It is very important to have a common language.