This question turns up a lot, on the irc channel, mailing lists, forums, your local Stammtisch and at weddings. The correct answer is: this is the wrong question. And I'll explain why in this post. Note that I'll be skipping over a couple of technical bits, if you notice those then you're probably not the person that needs to ask the question in the first place. The X server is responsible for rendering things to the screen and handling your input.
The window manager is responsible for telling the X server where to render the web browser window. Your web browser is responsible for displaying this post. The X server and the window manager communicate over the X protocol, the X server and the web browser do so too. The browser and the window manager communicate through X properties using the X server as a middle man.
That too is done via the X protocol. Note: This is of course a very simplified view. Wayland is a protocol and it replaces the X protocol. Under Wayland, you only need two processes: a compositor and your web browser. The compositor is effectively equivalent to the X server and window manager merged into one thing, and it communicates with the web browser over the Wayland protocol.
For this to work you need the compositor and the web browser to be able to understand the Wayland protocol. This is why the question "is wayland ready yet" does not make a lot of sense. Wayland is the communication protocol and says very little about the implementation of the two sides that you want to communicate.
Let's assume a scenario where we all decide to switch from English to French because it sounds nicer and English was designed in the 80s when ASCII was king so it doesn't support those funky squiggles that the French like to put on every second character. In this scenario, you wouldn't ask "Is French ready yet? Maybe you can use French in a restaurant, but not yet in the supermarket.
Maybe one waiter speaks both English and French, but the other one French only. So whether you can use French depends very much on the situation. But everyone agrees that eventually we'll all speak French, even though English will hang around for ages until it finally falls out of use.
And those squiggles are so cute! Wayland is the same.Then maybe this is a better question:. It has been our goal for a while to get to a point where the Wayland port can be declared complete and ready to be enabled by default. With this weeks releases of Wayland 1. Can you help me? With Wayland, gnome-shell is the compositor, and all clients are directly connected to it unlike X, where clients are directly connected to the display server, and the shell is off to the side.
While it is in principle possible to preserve client connections while restarting the compositor doing similar tricks to what systemctl daemon-reexec doesit is far from trivial, and nobody has looked seriously at implementing it so far.
That means separating the session state from the compositor connection…. The same. I think that the main culprit for crashing GS sessions past 3. Unfortunately, a quick look at e. Not a big deal if the consequence is only some screen flickering, but much more serious if the whole session goes down. I have gnome-shell crash once in a while and yes, bugs are filed.
Alt-F2, r This is very useful when it starts acting a bit funny or when modifying extensions. On top of what Matthias said: on most distros these days the output of gnome-shell is in the journal. There is this for me on Fedora 23, it happens on every boot, and it seems that gdm falls back to plain xserver:. Please do keep us updated on this front! I presume this test was done on a local network, how will it fare over the web, on fairly slow consumer broadband connections?
How to debug Wayland problems
With SDL 2. A discussion should happen whether it would be ok to potentially break games for the entire Fedora 24 lifecycle. In my opinion, if Fedora wants to be a true competitor to Ubuntu and grab marketshare, then it should play the conservative card. Wait until Fedora 25 and get an extremely polished and mature release for all the major use cases. I thought VNC is the old tech, and the latter two are the current trend? Jonas is working on a remoting daemon which gets frames passed from gnome-shell via a pinos pipeline.
I hope this can be fixed by gnome 3. I think the non drawing of desktop icons is a known bug in gnome, due to the tight coupling of that part of gnome to xorg. Other than that, gnome works quite nicely under wayland, especially with AT tools such as orca, the on screen keyboard, etc. We also try to handle dialogs without transient parent as good as we can. Kinetic scrolling now works as well under Wayland as under X11 — or even better at least as far as the protocol is involved; Wayland has explicit support for this while we are relying on driver-specific heuristics under X.
Drag-and-Drop under Wayland is now comparable to X Whats next? This is being driven by the team working on the Mir backend, but it will benefit Wayland just as well. Here are some for you, just from Fedora 23! It is good to hear that wacom support is considered too. Which vnc server was used in the video? I try to run latest vine 3.Wayland is a communication protocol that specifies the communication between a display server and its clients, as well as a C library implementation of that protocol.
As part of its efforts, the Wayland project also develops a reference implementation of a Wayland compositor called Weston. Starting aroundLinux desktop graphics has moved from having "a pile of rendering interfaces This will be "a much-simplified graphics system offering more flexibility and better performance".
For many things we've been able to keep the X. With Wayland we can move the X server and all its legacy technology to an optional code path. Wayland consists of a protocol and a reference implementation named Weston. Most applications are expected to gain support for Wayland through one of these libraries without modification to the application. Wayland protocol follows a client—server model in which clients are the graphical applications requesting the display of pixel buffers on the screen, and the server compositor is the service provider controlling the display of these buffers.
The Wayland reference implementation has been designed as a two-layer protocol: . While the low-level layer was written manually in Cthe high-level layer is automatically generated from a description of the elements of the protocol stored in XML format.
The reference implementation of Wayland protocol is split in two libraries : a library to be used by Wayland clients called libwayland-client and a library to be used by Wayland compositors called libwayland-server.
The Wayland protocol is described as an "asynchronous object-oriented protocol". Each object implements an interface which has a name, a number of methods called requests as well as several associated events.
Every request and event has zero or more arguments, each one with a name and a data type. The protocol is asynchronous in the sense that requests do not have to wait for synchronized replies or ACKsavoiding round-trip delay time and achieving improved performance.
The Wayland clients can make a request a method invocation on some object if the object's interface supports that request. The client must also supply the required data for the arguments of such request. This is the way the clients request services from the compositor. The compositor in turn sends information back to the client by causing the object to emit events probably with arguments too. These events can be emitted by the compositor as a response to a certain request, or asynchronously, subject to the occurrence of internal events such as one from an input device or state changes.
The error conditions are also signaled as events by the compositor.Yes, I know Wayland has made some controversial design choices. The fact is, Wayland is the only viable X11 successor, which will hopefully bring more security and stability to the Linux desktop. Regardless of how it pans out, there's nothing like a bit of competition to drive innovation. I won't discuss any more politics in this post.
Also a disclaimer: I'm no systems programming expert though I aspire to beneither am I an expert in X11, Wayland, or their associated protocols or codebases. This post merely draws on my experiences as an end user that enjoys a highly customised workflow.
I've been a long time user of the i3 window manager, but also peering over the fence at this hyped and somewhat controversial modern X11 replacement called Wayland. Every year or so I do some mad web searching to determine the state of Wayland and whether it would be feasible to port my workflow to it yet. I was hooked. So config for these must be added to the sway config. I actually enjoyed this. It was more declarative and felt less hacky than playing with a bunch of X11 utilities.
The downside is that none of that is portable; if you want to switch window managers, you must then hope that window manager implements support for configuring all this.
There was a bug that meant fullscreen scratchpads had to be implemented differently than for i3. On to general applications. Wayland has xwayland, which somehow provides mini embedded X server s for GUI apps that don't support wayland yet.
I kept this disabled when switching, going for the "pure" Wayland experience. So the pure Wayland experience didn't last long.
I soon discovered that many many apps either only supported X11, or crashed on Wayland. List of notable apps that required XWayland to work:.Wayland is a protocol for a compositing window manager to talk to its clients, as well as a library implementing the protocol. There is also a compositor reference implementation called Weston.
XWayland provides a compatibility layer to seamlessly run legacy X11 applications in Wayland. Most Wayland compositors only work on systems using Kernel mode setting. Wayland by itself does not provide a graphical environment; for this you also need a compositor such as Weston or Swayor a desktop environment that includes a compositor like GNOME or KDE.
Some of the above may support display managers. Below listed display managers which supports running Wayland compositors. The Type column indicates whether the display manager supports running on Wayland or not. See details on the official website. The gtk3 package has the Wayland backend enabled. To enable Wayland support in Qt 5, install the qt5-wayland package. This might be necessary for some proprietary applications that do not use the system's implementation of Qt, such as zoom AUR.
On some compositors, for example swayQt applications running natively might have missing functionality. For example, KeepassXC will be unable to minimize to tray. The Clutter toolkit has a Wayland backend that allows it to run as a Wayland client.
The backend is enabled in the clutter package. EFL has complete Wayland support. Winit is window handling library in Rust. See Backlight Color correction. Gnome-shell users may experience display issues when they switch to Wayland from X. In contrast to Xorg, Wayland does not allow exclusive input device grabbing, also known as active or explicit grab e. Wayland solves this by adding protocol extensions for Wayland and XWayland. Support for these extensions is needed to be added to the Wayland compositors.
In the case of native Wayland clients, the used widget toolkits e. In the case of Xorg applications, no changes in the applications or widget toolkits are needed as the XWayland support is enough. These extensions are already included in wayland-protocolsand supported by xorg-server-xwayland 1.
A Wayland status update
Logging in Remember me. Log in. Forgot password or user name? Hutterer: Is Wayland Ready Yet? Posts Latest Activity. Page of 2. Filtered by:. Previous 1 2 template Next. Org project vs. Org Foundation post from a few days ago. Today he looks at the question of "is Wayland ready yet?
As soon as auto-rotation with iio-sensor-proxy works maybe it does already? Comment Post Cancel. That's a lot of words to say no. Some very welcome clarifications, but it's clear that you're going to miss some stuff from X if you switch to Wayland today. That's not even unexpected, I'm not sure why most people act like Wayland should have been production ready after a couple of years in development. If you need a foundation for the next 30 years, it needs to be solid. And that takes time. It looks like they finally agreed on a pointer confinement and locking protocol, which now will be implemented to check the real world feedback.
I'd love to see this finalized and stable in Gnome 3.
Originally posted by bug77 View Post. Originally posted by t. View Post. I'm using Wayland with Gnome 3. Still several issues, so I switch back to X11 every now and then. Especially regarding pointer confinement, L4D2 is hard to play without it. Still no tablet support? I am very disappoint. When I ask about some new hardware I don't care if it exists as a prototype somewhere, what I care about is if I can order it, get it delivered and if there are drivers available.
In human languages you make simplifications because people understand what you talk about anyway, you don't go down and specify every little aspect of what you are saying.
All rights reserved. Yes No.Once the document is live, go to the original wiki page and replace its text with the following macro:. This page has been converted from the Fedora Project Wiki and cleaned up for publishing here on the Fedora Docs Portal, but it has not yet been reviewed for technical accuracy. This means any information on this page may be outdated or inaccurate.
Reviews for technical accuracy are greatly appreciated. Wayland is intended as a simpler replacement for X Wayland changes the design of a Linux desktop architecture considerably. Unlike X11, there is no dedicated standalone server in Wayland. What was previously done between the app, its toolkit, the Xserver and the window manager is now shared between the app, its toolkit and the Wayland compositor which manages the compositing, input, windows management, etc. The apps and toolkits are now in charge of their own rendering and decorations client side decorationsso any issues usually sit between the toolkit e.
You can read more about the current state of Wayland features on Wayland features page. If you want to start your session in a different way, read the advanced techniques for trying Wayland. First run loginctl and find your session number if should be an integer number, with your username and seat assigned. Then look at the session type x11 or wayland :. It is important to know whether the problematic application is a native Wayland application, or runs through XWayland, which allows legacy applications to still run on top of Xorg server, but display in a Wayland session.
Now click anywhere inside the app window you want to test. If the xwininfo command finishes it should print window properties into the terminalthe app under test is running under XWayland.
You can also use xprop command using the same instructions. If you see MetaWindowWayland in the first line, this app is running under Wayland. If you see MetaWindowX11 in the first line, this app is running under X If you have identified the problem to be in a XWayland application, try to reproduce the issue in a standard X11 session. If the problem happens only under XWayland but not in an X11 session, it should still be reported against Xorg server packagebecause XWayland is included in it as xorg-xserver-Xwayland subpackage.
Wayland itself is a protocol and the problem is rarely in the protocol itself. Rather, the problem is likely to be in the app or its toolkit, or in the compositor. QT 5 - many apps in KDE environment use this toolkit.
Please note that apps using older QT 4 are not Wayland-ready. Kwin - compositor in KDE. If you run KDE, it is using this compositor. Please run your session with the reference Weston compositor and try to reproduce the issue. You can either run Weston as a nested window, or as a full session. First, install package you can read many useful information in its man page :.
Then create a config file which will specify that you want to have XWayland support enabled in your weston sessions. A Weston window should open and you should see and a terminal icon in its top left corner. Use that icon to launch a terminal and from that you can run apps and other commands using Weston. Exit the compositor by simply closing the window or killing the weston process. Otherwise file the issue against the compositor your environment uses mutter, kwin, etc.
If the problem occurs only with XWayland apps but not native Wayland apps, report a bug against Xorg server. Before reporting the bug, please make sure you use the latest available software.