It's not intended to be anything other than a basic desktop environment, providing a working implementation of a Wayland compositor ie a display server using the Wayland protocol.

It also includes a library called libweston (a Wayland compositor library) which provides an API allowing users build their own custom full-featured environments on top of
Weston's core.

Well of course. Wayland is a protocol. KDE and Gnome desktop environments are Wayland compositors in their own rights.

2 members found this post helpful.

This thread has yielded some very interesting observations. Recognizing that my own experience is with an old graphics card, and that I really don't care whether "wayland" works on it or not :
But I do care about understanding the hardware and software requirements for wayland-the-protocol and ditto for any commonly-use wayland-compositor.
And I have not been able to track down any definitive statement about either.

Here is a fact : with a very recent (31 March 2024) build of Xorg, including its xf86-video-intel driver, all graphics functions including hardware acceleration and GLX/mesa work just fine on my old graphics card.

But somehow, to me, that fact is inconsistent with the statements I've quoted that Wayland uses the very same drivers as Xorg and yet Wayland does not support this old card. To me, if some high-level piece of software uses a hardware driver which works, then the high-level piece of software should work with that hardware shouldn't it?

As I said, I couldn't care less about wayland on this computer, but I'd like to understand what dependencies it does have.

Cheers, John

1 members found this post helpful.

Okay, let me to try to explain why the Wayland implementations usually needs a certain minimal OpenGL support... Excuse the wall of text, BUT you asked for.

From what I have understand from the Wayland evangelists, Wayland works in the server/clients way. That's right, we have a Wayland server implemented by your DE of choice (i.e. kwin_wayland for Plasma5 or Mutter for GNOME4) and one or more Wayland clients (your graphical programs) which of course needs to connect to the server. Via a socket, BTW.

The Wayland Design itself does not talk about OpenGL, because for the Wayland server your screen is composed from one or more areas (windows), where each window is an area allocated to a program to draw its business and when it received focus, to receive the mouse or keyboard events. BUT, those screen areas (windows) may overlap, some windows may be hidden, and the Wayland server has the duty to "compose" the final screen (the desktop) presented to user, from these various windows with various states and dimensions.

Like I have said already, the The Wayland Design itself does not talk at all about OpenGL and neither require it. There are Wayland servers capable to use for this composition job just a dumb and not accelerated Linux framebuffer, or even a memory area, which is later encoded in a network stream - like a VNC or RDP connection. And as example of Wayland server which is capable to use a dumb Linux framebuffer, memory areas (for VNC or RDP connections) or even the area of a window on a X11 server, we have the Weston reference compositor.

HOWEVER, contrary to a X11 server, for a Wayland server the Wayland Design does not provide drawing tools (for points, lines or rectangles) or even a method to calculate the position, intersection or overlapping of various Wayland windows present in a Wayland screen. The Wayland server needs to allocate a memory area for window drawing for every Wayland client, to manage these memory areas and most importantly, to "compose" everything on the desktop screen - basically pixel with pixel. Yep, you can do this and the Weston (alternatively) do this, but the end result is terrible slow, even slower than a screen presented by a X11 server using the VESA driver.

BUT, there is a method which permits super-fast management of the overlapping screen areas and also for super-fast drawing of them in a final user interface screen - it's the hardware accelerated OpenGL(ES) which provides all these features for the Wayland server, if it is properly used.

So, for responsiveness reasons, any civilized Wayland server (be it the one from Plasma5, the one from GNOME4 or even Weston) will transform the screen presented to user in a full screen 3D game, where everything is drawn using extensively the OpenGL(ES) hardware accelerated APIs. However, the OpenGL(ES) usage takes a tool, by requiring a certain minimal OpenGL(ES) version, which happens to be OpenGL 2.1 - just like for the Glamor acceleration from X11.

BUT, this does NOT mean that Wayland Design itself requires OpenGL 2.1 , only that the currently major Wayland servers implementations requires it for a reasonable responsiveness. How the Wayland is about Freedom, I believe that a wise programmer can write a blazing fast Wayland server in Assembler - which Wayland server does not require OpenGL for doing its usual tasks. Or even, some wise company can make a PCI Wayland accelerator card - along with the associated Wayland server, which can be even with greater performances than the OpenGL based solutions. Just like there are PCI express cards for hardware video decoding.

That being said, the Wayland servers are usually named "Wayland compositors" because their main task is to "compose" the various screen areas which represents the windows allocated to Wayland client applications.

And NOPE, they does NOT use the same drivers like X11. Usually they use directly the KMS or dumb Linux framebuffers (or even memory areas) for drawing the screen and libinput to grab the mouse and keyboard data.

9 members found this post helpful.

I think the misunderstanding comes from confusing the kernel graphics drivers and the Xorg (userspace) drivers. Only the former is relevant to Wayland compositors.

2 members found this post helpful.

Thanks for pointing that out -- but my question remains the same, where, just for the purposes of considering "what does wayland depend on?", we can consider *all* of those drivers (plus a third group, the glamor/EGL/mesa libraries) to be one large bundle of low-level code in direct communication with the graphics card.
And I am still wondering why :
the Xorg server works perfectly well when using this bundle to operate my card
any attempt to run a wayland compositor with this exact same bundle does not work

Cheers, John

Using what desktop? What compositor? What are you running on TOP of X.org or Wayland?

There are debugging methods available to help pinpoint the underlying problem, and you'd need to share compositor and graphics hardware details to begin with. Best to start a dedicated thread requesting assistance if you're serious about getting such help.

Interesting comment from Drew Devault on GNOME being a big blocker for Wayland improvements, taken from about three years ago.


https://old.reddit.com/r/linux/comme...om_running_on/

https://old.reddit.com/r/linux/comme...ng_on/fxfax76/

This is rich. Look in the mirror. You'll be shocked to learn that this wouldn't be a problem with X11. The protocol-based nature of X11 allows new features and extensions added to an X server without sacrificing backwards compatibility. "Here's hardware-accelerated blending and composition, and here's how to do it, you don't feel like using it, that's ok, everyone else who wants to, can".

1 members found this post helpful.

Curious. I thought wayland was primarily a protocol, then secondarily a library derived from this protocol, and only thirdly a server for calls using this library.

I get exactly where Drew is coming from. I abandoned GNOME LONG ago, and part of the reason was that they kept breaking the standards instead of USING the standards. I ran Windowmaker and fluxbox for a LONG time before KDE trimmed down their overhead and got small and fast enough to satisfy me. The KDE team USE the standards, as (I assume) do most other teams. X.Org is a huge mess BECAUSE it includes so many shims and special cases to adjust for those who could not or would not follow the plan. IT is a work of art, but also a nasty hot mess! We needed something trimmer, cleaner, and more pure. Wayland is as close to that as I have seen in a long while.
As for Gnome, X.Org is not going away any time soon. IF they want Wayland to be adjusted to them instead of them coding for Wayland, I am fine if they stay on X.Org until they figure this out.
Or they could spin off one of the projects and code their own display server optimized for Gnome desktops: call it X.Gnome!

Curious. I thought protocols were intended to be implemented by 3rd party projects, and that there will be differences in how different projects implement the protocol.

If wayland truly is a protocol, why does it matter how GNOME implements it? That is their choice. From the rant that was linked it sounds like the wayland team gets mad when people don't implement their protocol/API exactly the way they envisioned it. So one project walking up to another project, telling them what to do, then getting upset and crying on social media when nobody listens?

<sarcasm> I am shocked. What kind of monster would refuse to implement the wayland protocol EXACTLY as intended? </sarcasm>

Hey 2008 called, it's for you... They want their talking points back.

Curious is only that you cannot make the difference between a protocol (as specification, interface or method of communication) and its implementation.

Yes, does NOT matter how GNOME implements the Wayland protocols (there are many) as long they accurately implement them.

Just like does not matter how you implement a HTTP web-server (be it in C/C++, Rust or even Bash) as long it accurately implements the HTTP protocol which it has advertised, and it responds accurately to the HTTP requests issued by an web-browser.

However, apparently for you the HTTP protocol and the Apache web-server or Firefox are the same thing.

You, Sir, with this "sarcasm" you won the Internet for this year, if not century.

1 members found this post helpful.

Although you may or may not realize it, you have hit upon exactly the point. The GNOME team (or SOME of them to be more precise) want the desktop team to adjust Wayland the protocol to what THEY want to code instead of Gnome coding for Wayland. In particular if it would violate their standards, why would the desktop team want to change the protocol that other WM teams have already coded to and that works just fine?

I wouldn't!