How to tell if you're using X11 or Wayland on Linux

If you use Linux It's quite likely that at some point on a daily basis you've wondered if your system is pulling from X11 or Wayland as a window serverIt's not just a curiosity: it influences how your graphical applications behave, their performance, compatibility with older programs, and even details as silly (but annoying) as a remote key combination switching windows on your own desktop.

Many users experience the same problem as with the typical Pop!_OS or Fedora users: they open Firefox, look in about:support and see "x11"But they're in a session that, in theory, is Wayland. Furthermore, programs like xeyes stop following the mouse within certain windows, leading to suspicions that something different is going on under the hood. Let's calmly break down why this happens, how the Xwayland compatibility layer works, and, above all, How to know for sure if you're using X or Wayland in your favorite distro.

What are Xorg/X11 and Wayland and why should you care?

When we talk about Xorg or X11 we are referring to the classic window system Unix and LinuxXorg, which has been ruling the desktop for decades, is a free implementation of the X Window System version 11 protocol (hence the X11) and has become a de facto standard for graphical user interface (GUI) applications. Most legacy programs expect to encounter an X server and connect to it to draw windows, receive keyboard and mouse events, and so on.

This omnipresence has made Xorg what it is for years. an almost mandatory requirement in desktop distributions. As a result, much of the Linux ecosystem was designed with X11 in mind: from lightweight window managers like Openbox to full desktops like KDE Plasma or GNOME in their older versions. Even today, many internal tools still assume that an X server is available.

Wayland, on the other hand, is a much more modern architecture which aims to simplify this whole setup. Instead of maintaining a gigantic server with decades of patches and extensions, it proposes a more direct protocol between the compositor (GNOME Shell, KWin, Sway…) and the applications. The idea is to reduce complexity, improve security (preventing one app from spying on what others are doing), and offer a cleaner foundation for animations, scaling to HiDPI displays, and other modern graphical features.

Despite having been among us for quite a few years now, Wayland is still not widespread. like X11. Distributions like Fedora adopted it by default in GNOME, while Ubuntu made the leap, backtracked for a while, and then gradually returned to Wayland. Other systems, such as many Manjaro editions or more conservative distributions, continue to prioritize Xorg or maintain both options simultaneously.

There are even very specific distributions, such as Rebecca Black Linux, that have focused almost entirely on explore and showcase the possibilities of WaylandThey are a good proof of concept, but in our day-to-day work we still coexist with both worlds, and therefore, knowing which one you are using at any given moment is quite relevant.

Why does it sometimes seem like you're using X11 even though you're on Wayland?

A very common case is starting a Wayland session (for example, GNOME on Wayland in Fedora or Pop!_OS with the specific Wayland session) and discover that, when opening Firefox or consulting certain technical information, X11 is mentioned. Or that an old graphical tool works as if nothing is wrong, even though it is supposed to only know how to speak the X protocol.

The trick is in Xwayland, which acts as compatibility layer for legacy X11 applicationsIn GNOME Shell on Wayland, Xwayland starts automatically at session beginning. This component acts simultaneously as an X11 server for legacy applications and as a Wayland client for the modern compositor. In other words, it translates everything that X apps request (windows, events, graphics acceleration) into the language that Wayland understands, and vice versa.

Thus, when a legacy application such as an old CAD program, a classic window manager, or even utilities like xeyes, xterm, or certain versions of Firefox They run, thinking they're talking to a traditional X server. In reality, they're connecting to Xwayland, which in turn communicates with your desktop's Wayland compositor. That's why many internal diagnostic tools still report "x11": that's what they see, even though the system is using Wayland underneath.

This mechanism explains curious things such as Xeyes' eyes don't follow your cursor within a native Wayland application, although they do so in X11 windows. Wayland deliberately limits an app's ability to spy on the global pointer, whereas under Xorg any client could easily find out what you were doing on the screen. From a security and privacy standpoint, this is a considerable improvement.

However, it's not all advantages: some programs depend on very specific features of X11 (For example, certain global shortcuts or very deep integrations with the window manager) may behave strangely under Xwayland. In such cases, many guides recommend explicitly logging into a full Xorg server instead of using Wayland, at least until that application has native Wayland support.

How to find out what type of session you're using with loginctl

Beyond what a browser or a specific tool might say, if you want a fairly reliable way to find out What protocol is being used in your graphical session?One of the most practical options is to pull loginctlThis utility is part of the systemd ecosystem and allows, among other things, the consultation of detailed information about active user sessions.

loginctl This is the initial command to list sessions

The general method is very simple: first you find out Your session ID and then you ask loginctl that shows you the type. In a terminalYou can do something like:

loginctl

This will give you a list of active sessionsSomething like this:

SESSION UID USER SEAT TTY
2 1000 cr0n0s seat0 tty2
sessions listed.

Look at the first column: that's where the session number appears.

In this example, the session identifier is 2With that information, you can ask about the type of session with:

With that information in hand, you can check the Type parameter with:

loginctl show-session 2 -p Type Executes the query and returns the parameter

The typical exit It will be something like:

Type=x11 indicates use of X11

Type=wayland indicates use of Wayland

This way you know for sure if you are running on [something] at that moment an Xorg (X11) server or a pure Wayland sessionThis trick is very useful on desktops like GNOME or KDE Plasma, where you can choose the session type on the login screen but then it's easy to forget which one you selected last time.

Check the XDG_SESSION_TYPE environment variable

Another fairly direct way is to look at the environment variable XDG_SESSION_TYPE, which many distributions configure to indicate if the current chart session is "x11" or "wayland"Simply open a terminal and run:

Simply open a terminal and run: check the environment variable

echo $XDG_SESSION_TYPE displays the defined value

In many cases, the answer will simply be:

x11

o:

wayland

For example, a Manjaro KDE user commented that when applying this method obtained "x11" as a resultHe confirmed that his desktop was still using the X server, even though he was curious to try Wayland. Although he would have been excited to see Wayland, he admitted that, at least for the time being, he didn't plan to dedicate time to installing and configuring everything in that new environment.

However, there is one thing to keep in mind: Not all configurations set this variable Similarly, they either update it correctly or not. In some unusual systems, highly customized sessions, or lightweight window managers, the value may not be reliable or may not even be defined. Therefore, it's a good idea to combine this method with others, such as using... loginctl or process inspection.

Additional checks with WAYLAND_DISPLAY variables and processes

In addition to XDG_SESSION_TYPEThere are a couple of variables and quick tests that can help you confirm whether you're on Wayland or X11, or at least There is an active Wayland server in your surroundings. One of the most interesting is WAYLAND_DISPLAYwhich is normally set when a Wayland compositor is running.

In a terminal you can run: Check if there is a Wayland composer.

echo $WAYLAND_DISPLAY shows the Wayland socket

If you're in a Wayland session or have an active Wayland composer, you'll likely see something similar to:

wayland-0 example of active socket

or a similar identifier. This indicates that there is a Wayland socket available to which native Wayland applications connect. If, on the other hand, the result is empty, you are most likely in a purely X11 session without a main Wayland compositor (although you could be running Wayland applications in a very particular way in some container or similar, but that is another topic).

Another classic tactic, which many users apply with tools such as htop, ps or pgrepIt consists of directly searching for processes such as Xorg, Xwayland or the composer Wayland himself (for example, gnome-shell in Wayland mode, kwin_wayland, swayetc.). If you see that there is a process Xorg In full-screen mode, your primary session is usually X11. If, however, you detect Xwayland But not Xorg, that's a pretty clear clue that The system runs on Wayland and only maintains an X layer for compatibility..

This form of inspect processes It may be a bit more technical, but it is very illustrative, especially when you want to understand exactly what is being set up when logging in with different options in the display manager (GDM, SDDM, LightDM, etc.).

Limitations, nuances, and the importance of combining methods

One thing that should always be kept in mind is that no single method is infallible in all scenarios. The reading of about:support In Firefox, it can indicate X11 even if you're using Wayland with Xwayland. The variable XDG_SESSION_TYPE It may not be correctly defined in highly customized environments. Even the result of loginctl show-session This can lead to confusion if you work with remote sessions, containers with their own graphical server, or unusual configurations.

Therefore, the most sensible thing is combine several indicators: check the session type with loginctl, check $XDG_SESSION_TYPE, check if there is a $WAYLAND_DISPLAY active, inspect processes such as Xorg, Xwayland or the corresponding Wayland compositor and, if necessary, rely on the specific documentation for your distribution or desktop environment.

It's also helpful to know which options you choose in the login manager: GDM, SDDM, and others usually let you choose between "Plasma (Wayland)" and "Plasma (X11)," or between "GNOME" and "GNOME on Xorg." Once you know what you've selected, it will be much easier to interpret. what the variables and commands spit out at you when you investigate what's happening in your system.

As can be seen from the experiences of users of Fedora, Pop!_OS, Manjaro KDE, and other distributions, these details are not just textbook theory: they influence the behavior of remote desktop tools, browsers, older applications, and keyboard shortcutsUnderstanding how Xorg, Wayland, and Xwayland fit together saves you time when something doesn't work as expected.

If you know how to use commands like loginctl, Consult $XDG_SESSION_TYPE, review $WAYLAND_DISPLAY And observe what graphic processes are running, you'll have it in your hand a pretty clear picture of which windowing system governs your Linux at any given time. With that information, it becomes much easier to decide whether it's worth trying Wayland, sticking with X11 a little longer, or switching depending on the needs of your more demanding applications.