Chapter 2. Graphics stacks in RHEL 8
In Red Hat Enterprise Linux 8, you can choose between two protocols to build a graphical user interface:
The X11 protocol uses X.Org as the display server. Displaying graphics based on this protocol works the same way as in Red Hat Enterprise Linux 7, where this was the only option.
The Wayland protocol on Red Hat Enterprise Linux 8 uses GNOME Shell as its compositor and display server, which is further referred as GNOME Shell on Wayland. Displaying graphics based on the Wayland protocol has some differences and limitation compared to X11.
New installations of Red Hat Enterprise Linux 8 automatically select GNOME Shell on Wayland. However, you can switch to X.Org, or select the required combination of GNOME environment and display server as described in Section 1.4, “Selecting GNOME environment and display protocol”.
Note that there are also a few environments where X.Org is preferred over GNOME Shell on Wayland, such as:
- Cirrus graphics used in a VM environment
- Matrox graphics
- Aspeed graphics
- QXL graphics used in a VM environment
- Nvidia graphics when used with the proprietary driver
The Nvidia graphics by default use
nouveau, which is an open source driver.
nouveau is supported on Wayland, hence you can use Nvidia graphics with
nouveau on GNOME Shell on Wayland without any limitations. However, using Nvidia graphics with proprietary Nvidia binary drivers is not supported on GNOME Shell on Wayland. In this case, you need to switch to X.Org as described in Section 1.4, “Selecting GNOME environment and display protocol”.
2.1. Key differences between the Wayland and X11 protocol
Client applications need to be ported to the Wayland protocol or use a graphical toolkit that has a Wayland backend, such as GTK, to be able to work natively with the compositor and display server based on Wayland.
Legacy X11 applications that cannot be ported to Wayland automatically use Xwayland as a proxy between the X11 legacy clients and the Wayland compositor. Xwayland functions both as an X11 server and a Wayland client. The role of Xwayland is to translate the X11 protocol into the Wayland protocol and reversely, so that X11 legacy applications can work with the display server based on Wayland.
On GNOME Shell on Wayland, Xwayland is started automatically at startup, which ensures that most X11 legacy applications work as expected when using GNOME Shell on Wayland. However, the X11 and Wayland protocols are different, and hence some clients relying on X11-specific features may behave differently under Xwayland. For such specific clients, you can switch to the X.Org display server as described in Section 1.4, “Selecting GNOME environment and display protocol”.
Red Hat Enterprise Linux 8 uses a new unified input stack,
libinput, which manages all common device types, such as mice, touchpads, touchscreens, tablets, trackballs and pointing sticks. This unified stack is used both by the X.Org and by the GNOME Shell on Wayland compositor.
GNOME Shell on Wayland uses
libinput directly for all devices, and no switchable driver support is available. Under
libinput is implemented as the
X.Org libinput driver, and driver support is outlined below.
- Mice, touchscreens, trackballs, pointing sticks
Red Hat Enterprise Linux 8 uses the
X.Org libinputdriver for these devices. The
X.Org evdevdriver, which was used in Red Hat Enterprise Linux 7, is available as fallback where required.
Red Hat Enterprise Linux 8 uses the
X.Org libinputdriver for touchpads. The
X.Org synapticsdriver, which was used for touchpads in Red Hat Enterprise Linux 7, is no longer available.
- Graphics tablets
Red Hat Enterprise Linux 8 continues using the
X.Org wacomdriver, which was used for tablet devices in Red Hat Enterprise Linux 7. However, the
X.Orglibinput driver is available where required.
- Other input devices
Red Hat Enterprise Linux 7 used the
X.Org evdevdriver for other input devices that are not included in the above categories. Red Hat Enterprise Linux 8 uses the
X.Org libinputdriver by default but can fall back to the
X.Org evdevdriver if a device is incompatible with
GNOME Shell on Wayland supports new touchpad and touchscreen gestures. These gestures include:
- Switching workspaces by dragging up or down with four fingers.
Activities Overviewby bringing three fingers closer together.
2.2. Current Wayland limitations
Proprietary Nvidia binary drivers are not supported with GNOME Shell on Wayland. To avoid any complications while using the Nvidia GPU, GNOME Shell automatically falls back to X.Org, which means that the login screen does not provide any option based on the Wayland protocol.
nouveau driver is still supported and is the default driver for Nvidia graphics.
With GNOME Shell on Wayland, VNC support is provided by the
gnome-remote-desktop package. Remote access using VNC via
gnome-remote-desktop currently requires an already logged in session, and only the primary monitor is accessible. Screen sharing with GNOME Shell on Wayland is possible using the PipeWire media server. For more details on the PipeWire media server, see PipeWire project.
For more advanced VNC usage, you need to switch to X.org, where traditional VNC tools are available. For more information, see Section 1.4, “Selecting GNOME environment and display protocol” .
X Display Manager
The X Display Manager Control Protocol (XDMCP) is not supported with GNOME Shell on Wayland.
Hence, it is not possible to use the X display manager to start a session on the X.Org display server from the same or another computer.
The following additional limitations related to the Wayland protocol should be noted:
- X.Org screen manipulation utilities are not available.
xrandrutility is not supported because Wayland handles layout, rotations, and resolutions differently.
- GNOME Shell cannot be restarted using the Alt+F2 r shortcut.
- Due to stability issues, using X.org instead of Wayland is recommended in virtual environments.
Wayland does not support the custom or niche input devices that cannot be handled by the
2.3. Additional resources
You can find the current list of environments for which Wayland is not available in the
- For additional information on the Wayland project, see Wayland documentation.