Can I finally start using Wayland in 2026?
Wayland is the successor to the X server (X11, Xorg) to implement the graphics stack on Linux. The Wayland project was actually started in 2008, a year before I created the i3 tiling window manager for X11 in 2009 — but for the last 18 years (!), Wayland was never usable on my computers. I don’t want to be stuck on deprecated software, so I try to start using Wayland each year, and this articles outlines what keeps me from migrating to Wayland in 2026. For the first few years, Wayland rarely even started on my machines. When I was lucky enough for something to show up, I could start some toy demo apps in the demo compositor Weston. Around 2014, GNOME started supporting Wayland. KDE followed a few years later. Major applications (like Firefox, Chrome or Emacs) have been slower to adopt Wayland and needed users to opt into experimental implementations via custom flags or environment variables, until very recently, or — in some cases, like — still as of today. Unfortunately, the driver support situation remained poor for many years. With nVidia graphics cards, which are the only cards that support my 8K monitor , Wayland would either not work at all or exhibit heavy graphics glitches and crashes. In the 2020s, more and more distributions announced looking to switch to Wayland by default or even drop their X11 sessions , and RHEL is winding down their contributions to the X server . Modern Linux distributions like Asahi Linux (for Macs, with their own GPU driver!) clearly consider Wayland their primary desktop stack, and only support X11 on a best-effort basis. So the pressure to switch to Wayland is mounting! Is it ready now? What’s missing? I’m testing with my lab PC, which is a slightly upgraded version of my 2022 high-end Linux PC . I describe my setup in more details in stapelberg uses this: my 2020 desk setup . Most importantly for this article, I use a Dell 8K 32" monitor (resolution: 7680x4320!), which, in my experience, is only compatible with nVidia graphics cards (I try other cards sometimes). Hence, both the lab PC and my main PC contain an nVidia GPU: (In case you’re wondering why I use the older card in my PC: I had a crash once where I suspected the GPU, so I switched back from the 4070 to my older 3060.) For many years, nVidia drivers were entirely unsupported under Wayland. Apparently, nVidia refused to support the API that Wayland was using, insisting that their EGLStreams approach was superior. Luckily, with nVidia driver 495 (late 2021), they added support for GBM (Generic Buffer Manager). But, even with GBM support, while you could now start many Wayland sessions, the session wouldn’t run smoothly: You would see severe graphics glitches and artifacts, preventing you from getting any work done. The solution for the glitches was explicit sync support: because the nVidia driver does not support implicit sync (like AMD or Intel), Wayland (and wlroots, and sway) needed to get explicit sync support . Sway 1.11 (June 2025) and wlroots 0.19.0 are the first version with explicit sync support. With the nVidia driver now working per se with Wayland, unfortunately that’s still not good enough to use Wayland in my setup: my Dell UP3218K monitor requires two DisplayPort 1.4 connections with MST (Multi Stream Transport) and support. This combination worked just fine under X11 for the last 8+ years. While GNOME successfully configures the monitor with its native resolution of 7680x4320@60, the monitor incorrectly shows up as two separate monitors in sway. The reason behind this behavior is that wlroots does not support the property (issue #1580 from 2019) . Luckily, in 2023, contributor sent draft merge request !4154 , which adds support for the property. But, even with the patch, my monitor would not work correctly: The right half of the monitor would just stay black. The full picture is visible when taking a screenshot with , so it seems like an output issue. I had a few exchanges about this with starting in August 2025 (thanks for taking a look!), but we couldn’t figure out the issue. A quarter later, I had made good experiences regarding debugging complex issues with the coding assistant Claude Code (Opus 4.5 at the time of writing), so I decided to give it another try. Over two days, I ran a number of tests to narrow down the issue, letting Claude analyze source code (of sway, wlroots, Xorg, mesa, …) and produce test programs that I could run manually. Ultimately, I ended up with a minimal reproducer program (independent of Wayland) that shows how the DRM property does not work on nVidia (but does work on Intel, for example!): I posted a bug report with a video in the nVidia forum and hope an nVidia engineer will take a look! Crucially, with the bug now identified, I had Claude implement a workaround: copy the right half of the screen (at ) to another buffer, and then display that buffer , but with . With that patch applied, for the first time, I can use Sway on my 8K monitor! 🥳 By the way, when I mentioned that GNOME successfully configures the native resolution, that doesn’t mean the monitor is usable with GNOME! While GNOME supports tiled displays, the updates of individual tiles are not synchronized, so you see heavy tearing in the middle of the screen, much worse than anything I have ever observed under X11. GNOME/mutter merge request !4822 should hopefully address this. During 2025, I switched all my computers to NixOS . Its declarative approach is really nice for doing such tests, because you can reliably restore your system to an earlier version. To make a Wayland/sway session available on my NixOS 25.11 installation, I added the following lines to my NixOS configuration file ( ): I also added the following Wayland-specific programs to : Note that activating this configuration kills your running X11 session, if any. Just to be sure, I rebooted the entire machine after changing the configuration. With this setup, I spent about one full work day in a Wayland session. Trying to actually get some work done uncovers issues that might not show in casual testing. Most of the day was spent trying to fix Wayland issues 😅. The following sections explain what I have learned/observed. Many years ago, when Wayland became more popular, people asked on the i3 issue tracker if i3 would be ported to Wayland. I said no: How could I port a program to an environment that doesn’t even run on any of my computers? But also, I knew that with working a full-time job, I wouldn’t have time to be an early adopter and shape Wayland development. This attitude resulted in Drew DeVault starting the Sway project around 2016, which aims to be a Wayland version of i3. I don’t see Sway as competition. Rather, I thought it was amazing that people liked the i3 project so much that they would go through the trouble of creating a similar program for other environments! What a nice compliment! 😊 Sway aims to be compatible with i3 configuration files, and it mostly is. If you’re curious, here is what I changed from the Sway defaults, mostly moving key bindings around for the NEO keyboard layout I use, and configuring / blocks that I formerly configured in my file : I encountered the following issues with Sway: I don’t know how I can configure the same libinput settings that I had before. See for what I have on X11. Sway’s available settings do not seem to match what I used before. The mouse cursor / pointer seems laggy, somehow?! It seems to take longer to react when I move the trackball, and it also seems to move less smoothly across the screen. Simon Ser suspects that this might be because hardware cursor support might not work with the nVidia drivers currently. No Xwayland scaling: programs started via Xwayland are blurry (by default) or double-scaled (when setting ). This is a Sway-specific limitation: KDE fixed this in 2022 . From Sway issue #2966 , I can tell that Sway developers do not seem to like this approach for some reason, but that’s very unfortunate for my migration: The backwards compatibility option of running older programs through Xwayland is effectively unavailable to me. Sometimes, keyboard shortcuts seem to be executed twice! Like, when I focused the first of five Chrome windows in a stack and moved that window to another workspace, two windows would be moved instead of one. I also see messages like this one (not exactly correlated with the double-shortcut problem, though): …and that seems wrong to me. My high-end Linux PC certainly isn’t slow by any measure. When I first started GTK programs like GIMP or Emacs, I noticed all fonts were way too large! Apparently, I still had some scaling-related settings that I needed to reset like so: Debugging tip: Display GNOME settings using (stored in ). Some programs like apparently need an explicit environment variable, otherwise they run in Xwayland. Weird. I also noticed that font rendering is different between X11 and Wayland! The difference is visible in Chrome browser tab titles and the URL bar, for example: At first I thought that maybe Wayland defaults to different font-antialiasing and font-hinting settings, but I tried experimenting with the following settings (which default to and ), but couldn’t get things to render like they did before: Update : Thanks to Hugo for pointing out that under Wayland, GTK3 ignores the configuration file and uses dconf exclusively! Setting the following dconf setting makes the font rendering match: The obvious replacement for is . I quickly ran into a difference in architecture between the two programs: i3lock shows a screen locker window. When you kill i3lock, the screen is unlocked. When you kill swaylock, you end up in a Red Screen Of Death . To get out of this state, you need to restart swaylock and unlock. You can unlock from the command line by sending to the process. This was very surprising to me, but is by (Wayland) design! See Sway issue #7046 for details, and this quote from the Wayland protocol : “The compositor must stop rendering and provide input to normal clients. Instead the compositor must blank all outputs with an opaque color such that their normal content is fully hidden.” OK, so when you start via SSH for testing, remember to always unlock instead of just cancelling with Ctrl+C. And hope it never crashes. I used to start via a wrapper script, which turns off the monitor (input wakes it up): With Wayland, the DPMS behavior has to be implemented differently, with : The i3 window manager can be extended via its IPC interface (interprocess communication) . I use a few small tools that use this interface. I noticed the following issues when using these tools with Sway: Tools using the Go package need a special socket path hook currently . We should probably include transparent handling in the package to ease the transition. Tools started with from the Sway config unexpectedly keep running even when you exit Sway ( ) and log into a new session! My workspace-populate-for-i3 did not work: My wsmgr-for-i3 worked partially: On X11, I use the rxvt-unicode (URxvt) terminal emulator. It has a couple of quality-of-life features that I don’t want to lose, aside from being fast and coming with a minimal look: In earlier experiments, I tried Alacritty or Kitty, but wasn’t happy with either. Thanks to anarcat’s blog post “Wayland: i3 to Sway migration” , I discovered the terminal emulator , which looks like a really nice option! I started a config file to match my URxvt config, but later I noticed that at least some colors don’t seem to match (some text lines with green/red background looked different). I’m not sure why and have not yet looked into it any further. I noticed the following issues using : Pressing Ctrl+Enter (which I seem to do by mistake quite a bit) results in escape sequences, whereas URxvt just treats Ctrl+Enter like Enter. This can be worked around in your shell (Zsh, in my case), see foot issue #628 for details. Double-clicking on part of a URL with the mouse selects the URL (as expected), but without the scheme prefix! Annoying when you do want to use the mouse. I can hold Ctrl to work around this, which will make select everything under the pointer up to, and until, the next space characters. Starting in results in not having color support for programs running inside the session. Probably a terminfo-related problem somehow…? I can also reproduce this issue with GNOME terminal. But with URxvt or xterm , it works. Selecting text highlights the text within the line, but not the entire line. This is different from other terminal emulators I am used to, but I don’t see an option to change it. Here’s a screenshot showing after triple-clicking on the right of “kthreadd”: But triple-clicking on an echo output line highlights only the contents, not the whole line: I find Emacs’s Wayland support rather disappointing. The standard version of Emacs only supports X11, so on Sway, it starts in Xwayland. Because Sway does not support scaling with Xwayland, Emacs shows up blurry (top/background window): Native Wayland support (bottom/foreground window) is only available in the Emacs version ( on NixOS). used to be a separate branch, but was merged in Emacs 29 (July 2023). There seem to be issues with on X11 (you get a warning when starting Emacs-pgtk on X11), so there have to be two separate versions for now… Unfortunately, the text rendering looks different than native X11 text rendering! The line height and letter spacing seems different: I’m not sure why it’s different! Does anybody know how to make it match the old behavior? Aside from the different text rendering, the other major issue for me is input latency: Emacs-pgtk feels significantly slower (less responsive) than Emacs. This was reported on Reddit multiple times ( thread 1 , thread 2 ) and Emacs bug #71591 , but there doesn’t seem to be any solution. I’ll also need a solution for running Emacs remotely. Thus far, I use X11 forwarding over SSH (which works fine and with low latency over fiber connections). I should probably check out waypipe, but have not yet had a chance. When starting Chrome and checking the debug page, things look good: But rather quickly, after moving and resizing browser windows, the GPU process dies with messages like the following and, for example, WebGL is no longer hardware accelerated: Of course, using a browser without hardware acceleration is very frustrating, especially at high resolutions. Starting Chrome with seems to work around the GPU process exiting, but Chrome still does not feel as smooth as on X11. Another big issue for me is that Sway does not open Chrome windows on the workspace on which I closed them. Support for tracking and restoring the EWMH atom was added to i3 in January 2016 and to Chrome in May 2016 and Firefox in March 2020 . I typically have 5+ workspaces and even more Chrome windows at any given point, so having to sort through 10+ Chrome windows every day (when I boot my work computer) is very annoying . Simon Ser said that this would be addressed with a new Wayland protocol ( , merge request !18 ). I work remotely a lot, so screen sharing is a table-stakes feature for me. I use screen sharing in my browser almost every day, in different scenarios and with different requirements. In X11, I am used to the following experience with Chrome. I click the “Window” tab and see previews of my windows. When I select the window and confirm, its contents get shared: To get screen sharing to work in Wayland/sway, you need to install and (the latter is specific to wlroots, which sway uses). With these packages set up, this is the behavior I see: This is a limitation of (and others) , which should be addressed with the upcoming Sway 1.12 release. I changed my NixOS configuration to use sway and wlroots from git to try it out. When I click on the “Window” tab, I see a chooser in which I need to select a window: After selecting the window, I see only that window’s contents previewed in Chrome: After confirming, I get another chooser and need to select the window again. Notably, there is no connection between the previewed window and the chosen window in this second step — if I chose a different window, that’s what will be shared: Now that window is screenshared (so the feature now works; nice!), but unfortunately in low resolution, meaning the text is blurry for my co-workers. I reported this as xdg-desktop-portal-wlr issue #364 and it seems like the issue is that the wrong scale factor is applied. The patch provided in the issue works for me. But, on a high level, the whole flow seems wrong: I shouldn’t see a chooser when clicking on Chrome’s “Window” tab. I should see previews of all windows. I should be able to select the window in Chrome, not with a separate chooser. I also noticed a very annoying glitch when output scaling is enabled: the contents of (some!) windows would “jump around” as I was switching between windows (in a tabbed or stacked container) or between workspaces. I first noticed this in the terminal emulator, where the behavior is as follows: I captured the following frame with my iPhone just as the content was moving a few pixels, shortly after switching focus to this window: Later, I also noticed that Chrome windows briefly show up blurry after switching . My guess is that because Sway sets the scale factor to 1 for invisible windows, when switching focus you see a scale-1 content buffer until the application provided its scale-3 content buffer. dunst supports Wayland natively. I tried dunst 1.13 and did not notice any issues. rofi works on Wayland since v2.0.0 (2025-09-01). I use rofi with rofimoji as my Emoji picker. For text input, instead of , seems to work. I didn’t notice any issues. Instead of my usual choice , I tried , but unfortunately ’s flag to select the window to capture is rather cumbersome to use (and captures in 1x scale). Does anyone have any suggestions for a good alternative? Finally I made some progress on getting a Wayland session to work in my environment! Before giving my verdict on this Wayland/sway experiment, let me explain that my experience on X11/i3 is really good. I don’t see any tearing or other artifacts or glitches in my day-to-day computer usage. I don’t use a compositor, so my input latency is really good: I once measured it to approximately 763 μs in Emacs on X11 with my custom-built keyboard (plus output latency), see kinX: latency measurement (2018) . So from my perspective, switching from this existing, flawlessly working stack (for me) to Sway only brings downsides. I observe new graphical glitches that I didn’t have before. The programs I spend most time in (Chrome and Emacs) run noticeably worse. Because of the different implementations, or because I need to switch programs entirely, I encounter a ton of new bugs. For the first time, an on-par Wayland experience seems within reach, but realistically it will require weeks or even months of work still. In my experience, debugging sessions quickly take hours as I need to switch graphics cards and rewire monitors to narrow down bugs. I don’t have the time to contribute much to fixing these numerous issues unfortunately, so I’ll keep using X11/i3 for now. For me, a Wayland/Sway session will be ready as my daily driver when: The lab PC contains a nVidia GeForce RTX 4070 Ti. The main PC contains a nVidia GeForce RTX 3060 Ti. I don’t know how I can configure the same libinput settings that I had before. See for what I have on X11. Sway’s available settings do not seem to match what I used before. The mouse cursor / pointer seems laggy, somehow?! It seems to take longer to react when I move the trackball, and it also seems to move less smoothly across the screen. Simon Ser suspects that this might be because hardware cursor support might not work with the nVidia drivers currently. No Xwayland scaling: programs started via Xwayland are blurry (by default) or double-scaled (when setting ). This is a Sway-specific limitation: KDE fixed this in 2022 . From Sway issue #2966 , I can tell that Sway developers do not seem to like this approach for some reason, but that’s very unfortunate for my migration: The backwards compatibility option of running older programs through Xwayland is effectively unavailable to me. Sometimes, keyboard shortcuts seem to be executed twice! Like, when I focused the first of five Chrome windows in a stack and moved that window to another workspace, two windows would be moved instead of one. I also see messages like this one (not exactly correlated with the double-shortcut problem, though): …and that seems wrong to me. My high-end Linux PC certainly isn’t slow by any measure. i3lock shows a screen locker window. When you kill i3lock, the screen is unlocked. When you kill swaylock, you end up in a Red Screen Of Death . To get out of this state, you need to restart swaylock and unlock. You can unlock from the command line by sending to the process. Tools using the Go package need a special socket path hook currently . We should probably include transparent handling in the package to ease the transition. Tools started with from the Sway config unexpectedly keep running even when you exit Sway ( ) and log into a new session! My workspace-populate-for-i3 did not work: Sway does not implement i3’s layout saving/restoring because Drew decided in 2017 that the feature is “too complicated and hacky for too little benefit” . Too bad. I have a couple of layouts I liked that I’ll need to replicate differently. Sway does not match workspace nodes with criteria. There’s pull request #8980 (posted independently, five days ago) to fix that. My wsmgr-for-i3 worked partially: Restoring workspaces ( ) worked. Sway’s command implementation does not seem to pick up workspace numbers from the target name. Backwards search through your scrollback (= command output) Opening URLs in your scrollback using keyboard shortcuts Opening a new terminal window in the same working directory Updating the terminal title from your shell Pressing Ctrl+Enter (which I seem to do by mistake quite a bit) results in escape sequences, whereas URxvt just treats Ctrl+Enter like Enter. This can be worked around in your shell (Zsh, in my case), see foot issue #628 for details. Double-clicking on part of a URL with the mouse selects the URL (as expected), but without the scheme prefix! Annoying when you do want to use the mouse. I can hold Ctrl to work around this, which will make select everything under the pointer up to, and until, the next space characters. Starting in results in not having color support for programs running inside the session. Probably a terminfo-related problem somehow…? I can also reproduce this issue with GNOME terminal. But with URxvt or xterm , it works. Selecting text highlights the text within the line, but not the entire line. This is different from other terminal emulators I am used to, but I don’t see an option to change it. Here’s a screenshot showing after triple-clicking on the right of “kthreadd”: But triple-clicking on an echo output line highlights only the contents, not the whole line: I can share a Chrome tab. I can share the entire monitor. I cannot share a specific window (the entire monitor shows up as a single window). Switch focus to another terminal by changing workspaces, or by switching focus within a stacked or tabbed container. The new terminal shows up with its text contents slightly offset. Within a few milliseconds, ’s text jumps to the correct position. Sway no longer triggers some key bindings twice some times (“ghost key presses”) I no longer see glitches when switching between windows or workspaces in Sway. Chrome is continuously hardware-accelerated. Chrome windows are restored to their previous workspace when starting. Emacs either: Runs via Xwayland and Sway makes scaling work. Or if its variant fixes its input latency issues and can be made to render text the same as before somehow.
Programming
Linux
Open Source
DevOps
Go
Shell
JavaScript
Tutorial
Hardware
Gaming
Rust
Python
C#
Performance
C++
JSON