Artix Linux Forum

Wayland

Wayland is the newer display protocol designed to replace the X Window System. Many modern Linux distributions are using it as their default display server. It is meant to be lighter on system resources and have a smaller installation footprint than X. The project began in 2010 and is still undergoing active development, including work from active and former X.org developers.

Unlike the X Window System, there is no server instance that runs between the client and kernel. Instead, a client window works with its own code or that of a toolkit (such as Gtk+ or Qt) to provide the rendering. In order to do the rendering, a request is made to the Linux kernel via the Wayland protocol. The kernel forwards the request via the Wayland protocol to the Wayland compositor, which handles device input, window management and composition. The compositor is the part of the system that combines the rendered elements into visual output on the screen.

Most modern toolkits such Gtk+ 3 and Qt 5 have been updated to allow for rendering to either an X Window System or a computer running Wayland. Not all standalone applications have been written to support rendering in Wayland as of yet. For applications and frameworks that are still targeting the X Window System to run, the application can run within XWayland. The XWayland system is a separate X server that runs within a Wayland client and thus renders a client window’s contents within a standalone X server instance.

Just as the X Window System uses a DISPLAY environment variable to keep track of screens in use, the Wayland protocol uses a WAYLAND_DISPLAY environment variable. Below is sample output from a system running a Wayland display:

$ echo $WAYLAND_DISPLAY
wayland-0

This environment variable is not available on systems running X.

Quote from: mrbrklyn – on 07 June 2025, 08:15:34

Sure you don't want to clarify that?

I fail to follow your argument, but then that's nothing new.

That windowmaker link actually shows nicely how drawing is done thru Xlib; see appendix section 7: Xlib drawing.

As for doing it in wayland, see for example https://gaultier.github.io/blog/wayland_from_scratch.html

Since we're talking about API layers here, you need to actually look at the code behind the API to draw any conclusions on dependencies. Look at the source code of GTK3, not at a programmer's reference for using GTK3.

The compositor is the part of the system that combines the rendered elements into visual output on the screen.

Quote from: mrbrklyn – on 07 June 2025, 08:15:34

Sure you don't want to clarify that?

need to actually look at the code behind the API to draw any conclusions on dependencies. Look at the source code of GTK3, not at a programmer's reference for using GTK3.

Since we're talking about API layers here, you need to actually look at the code behind the API to draw any conclusions on dependencies. Look at the source code of GTK3, not at a programmer's reference for using GTK3.

Quote from: dpx – on 06 June 2025, 11:19:28

This is huge. I was really hoping that somebody will fork and continue developing X since it is still much better than wayland. It was all too obvious that they want to kill it artificially since it won't go away organically. Whole freedesktop story that I was monitoring from time to time did look a lot like systemd needless push.

When it goes public I hope we will switch to XLibre on Artix?

Unless this fork can use wayland-oriented video drivers from mesa, it'll be in trouble, unfortunately

Quote from: dpx – on 06 June 2025, 22:46:27

Desktops yes, can be a problem, but I believe window managers are less exposed. Of course if GTK intentionally breaks to be wayland only then we have a real problem.

What ARE YOU TALKING ABOUT.  ...

Quote from: phoenix_king_rus – on 06 June 2025, 11:22:55

Unless this fork can use wayland-oriented video drivers from mesa, it'll be in trouble, unfortunately

Why is that a problem?  I am just confused.  The video drivers are kernel based application and should work with anything.  I must not be understanding something.

X (through libX11) provides routines for drawing pixels and shapes on the screen. GTK uses these routines to draw its widgets when running with Xorg.

In wayland on the other hand, drawing is done on the client side.

So it's a completely different approach, requires separate segments of code for doing the actual drawing, and from a technical point of view, GTK could perfectly well drop support for one or the other. Same thing with QT.

I must not be understanding something.

Desktops yes, can be a problem, but I believe window managers are less exposed. Of course if GTK intentionally breaks to be wayland only then we have a real problem.

You expect them to BREAK GTK by purposely going out of their way and changing the code so that will not function on X

Matthias Clasen @matthiasc 2 years ago
When we discussed this issue at a recent gtk planning call, the outcome was:

    We should stop building the X11 backend by default in GTK 5
    As long as we aren't doing any major GDK refactorings, keeping it around in its current state does not cost us much

Quote from: lotuskip – on 07 June 2025, 07:59:08

In wayland on the other hand, drawing is done on the client side.

Sure you don't want to clarify that?

As for your personal comment.... if you have something personal to say, save it for email.  I have publicly available email and  phone numbers.  I will only say that comparing THIS CONVERSATION with people posting Nazi rants and political discussions outside of tech... is disingenuous .  We are still on the topic here.

I fail to follow your argument, but then that's nothing new.

Both window managers and GUI widget/toolkit libraries have to be specifically coded to support both X and wayland (and windows or anything else).
I don't think it was suggested that X support would be removed from pre-existing code. 'Sabotage' as you put it. It would be pointless as anyone could just fork the code and revert the changes.

However it's entirely possible that GTK 5 and/or QT 7 could drop support for X.
They won't just magically work on X unless support is specifically included.

Quote from: gripped – on 07 June 2025, 12:48:28

Both window managers and GUI widget/toolkit libraries have to be specifically coded to support both X and wayland (and windows or anything else).
I don't think it was suggested that X support would be removed from pre-existing code. 'Sabotage' as you put it. It would be pointless as anyone could just fork the code and revert the changes.

However it's entirely possible that GTK 5 and/or QT 7 could drop support for X.
They won't just magically work on X unless support is specifically included.

This. If GTK 5 drops X support (or keeps it around, disabled and leaves it to rot), my favorite xyz application will work with GTK 3 or 4 while I can compile it that way. If it starts requiring GTK 5 then I must try compiling GTK 5 with X support, which can break at any moment since it may be entirely unmaintained.

User facing API and its stability have nothing to do with if GTK <version> can be used on X.

Quote from: dpx – on 07 June 2025, 13:15:26

This. If GTK 5 drops X support (or keeps it around, disabled and leaves it to rot), my favorite xyz application will work with GTK 3 or 4 while I can compile it that way. If it starts requiring GTK 5 then I must try compiling GTK 5 with X support, which can break at any moment since it may be entirely unmaintained.
User facing API and its stability have nothing to do with if GTK <version> can be used on X.

GTK5 is vaporware.

Quote from: mrbrklyn – on 07 June 2025, 10:29:53

Seemed like a valid point to me...

No it is not.  It was a personnel attack, and there was no shouting.

Quote

Everything in the window is drawn client side under wayland.
The titlebar, buttons and borders vary depending on the window manager you are using. Some do it client side. Some have the compositor handle it.

That is not the difference.  The difference is the end of the Client/Server and the end of the modular design of X.
In X the client is also drawing the windows.  Obviously, a remote X server can not send images to a client screen as that requires access to the GPU hardware...   Xlib is a CLIENT library

The data that controls the basics of the imagining the libX is contained and controlled by the Server.  That is the part that ticks off those that want X to die.  The rendering itself, strangely enough is local where the client is where it talks to the Kernel and Talks to the GPU.   The server says to the Client - Draw a Box and the Client, with the help of a variety of client libraries (like the DM and a compositor),  draws a box.  

Wayland stuffs everything into the compositor... which is why in the other thread simple IPC is problematic even after 16 years.

  https://upload.wikimedia.org/wikipedia/commons/d/dc/Xlib_and_XCB_in_the_X_Window_System_graphics_stack.svg


Historically, FWIW, we alway talk about the Server and Client in reverse in X11. 
https://upload.wikimedia.org/wikipedia/commons/b/b2/X11_display_server_protocol.svg

I remote program is run by a local X Server and displayed locally where it controls events (I/O etc)

So you connect remotely to a big server with ssh with X protocols on ssh -X and then run xterm.  An xterm, which is a client program on a remote machine, is displayed by your X server on your screen by local libX libraries that are local clients to your Xserver.

reversely, you can connect to a remote XServer and using the Display variable tell that remote client to display programs on the remote client using the remote libX library

All of this has been removed by Wayland.  They see no usecase... DESPITE the wide use of VNC, remote desktop protocols in Chome, and the increasing numbers of Chrombook clients and JSom Aps from phones using remote protocols to store your data in their DMCA protected remote applications... effectely stuffing X11 capability into the web browser and javascript aps.


As for the links to GTK5 - it is ALL vaporware.  I'll be dead before any decisions about it are made, but this X fork is all about those pushing for the death of X  and proposing the futre of GTK without X, which is not a fact at all.  It is not "news" that GTK API's can be written to Wayland.  They can be written to ANYTHING as long at the API is not broken.... of OS-2 Warp or BeOS.

Instead of killing X, it should had been the focus on intense development of remote  protocols to include IPSEC and Crypto and to speed up remote client/server over TCP/IP communications.

BTW - Just for fun, you can fun X programs in a browser with Broadway
https://docs.gtk.org/gtk3/broadway.html


X is so far more advanced than anything Wayland has even proposed that Broadway!!  was developed in 1996!!
http://www.faqs.org/faqs/x-faq/part3/section-23.html

Broadway, under development at the X Consortium in 1996, is a package of
technologies designed to provide what is termed "universal access to
interactive applications on the Web" -- the ability to locate and invoke
remote applications via the Web and have their displays, including both
graphics and audio, appear wherever you are (on your local desktop), either
as new top-level windows or embedded within your Web browser.


Lastly on the GTK5 issue:

From LWN

Quote

Matthias Clasen has written a short update on a GTK hackfest that took place at FOSDEM and what's coming in GTK 4.18. This includes fixes for pointer sizes in Wayland when fractional scaling is enabled, removal of the old GL renderer in favor of the GL renderer introduced in GTK 4.13.6, and deprecation of X11 and Broadway backends with intent to remove them in GTK 5.

The deprecated backends will remain available until then, and no action is required by developers at this time, Clasen wrote: ""There is no need to act on deprecations until you are actively porting your app to the next major version of GTK, which is not on the horizon yet"".

In other words it is pompous posturing about the far future for GTK in a future when the Desktop itself is a disappearing technology.  They are going to have their hands full of adopting to mobile devices using AI that are voice activated for the majority of functions with crippled and limited touch screen interfaces.