this post was submitted on 05 Feb 2025
114 points (97.5% liked)
Linux
49731 readers
1894 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It is kinda simple. X.org and older Wayland compositors use the legacy KMS API, while modern compositors use the atomic API. The atomic API lets a compositor update everything for all planes in one go, this is a good thing because either all changes apply or none at all. The legacy API only lets things be updated individually.
Now why does atomic have more latency when it comes to mousing around? It's because in a single atomic commit all properties have to be set, including cursor X & Y positions. Once an atomic commit has been sent to the kernel, it is locked and can't be changed until the next monitor vblank. This means the cursor position is ever so slightly outdated. The legacy API does not have this limit, compositors can immediately move the cursor no problem, so less perceived latency. You can particularly see this while dragging windows around, on a modern Wayland compositor the cursor will be perfectly attached to the window, but in X.org it'll be slightly ahead because of the reduced latency. Unless you don't have a compositor running, of course.
There were proposed changes to address this years ago, but those seem to have fizzled out.
Oh and this is also why the cursor movement might visibly start stuttering during heavy GPU load. This is a problem that was solved back in the 80s but here we are...
To be honest, I switched to Wayland years ago precisely because of the better perceived input/cursor experience.
Change my mind, but having an average of half a frame input latency is much preferred when in return I gain that the cursor position on the screen actually aligns with all the other content displayed.
Plus, I'm very sensitive to tearing, so whenever it happens I get the impression that there was a huge rendering error.
Well and on the note that the cursor might visibly stutter, sure. But it's a bit misleading. A game pinning the GPU to 100 % and running on 5 FPS doesn't mean that your cursor will be rendered with 5 FPS. So far I've only noticed cursor lag/stutters in OOM situations, but neither under heavy GPU or CPU load.
Thanks for the detailed answers. So we can say that Wayland sacrifices lower latency in exchange for higher accuracy.
According to this post Gnome allows you to change this behavior through an environment variable (
MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0on Ubuntu 22.04). It should be a configurable option, considering the amount of people complaining about this mouse behavior.Sad, but does this problem only affect Wayland or also Xorg?
Note that depending on compositor switching to the legacy API might not help due to how they are designed. And with legacy you'll also probably lose the fancy modern crap like HDR. A workaround I did in my own not-public fork of sway is to use the legacy API for cursor stuff and atomic for everything else. Seems to work well enough in getting the best of both worlds.
Wayland compositors only in my experience.