Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK
marco-nett.de
marco-nett.de
I recently switched to Linux after years on Windows desktop, mostly because the KDE Plasma desktop feels snappier than Windows 11. Also the feeling that if something isn't working right I can probably tinker and improve it. It's been really nice. If you haven't tried Linux desktops in awhile give Bazzite a whirl: it's a Fedora customized for gaming. Even if you don't game it's an easy way to get a very functional Linux desktop in no time at all.
If only they'd actually DO something with this meaningfulness. I love and use Linux as my daily driver, but desktop environments and everything around it have become so complicated yet worse than before.
In the past a simple config file with intuitive setting names inside of them could make you do anything you wanted.
Today they have all these layers of abstraction for themes, icon sets and light and dark mode and what not, but almost NO combination works!
If you set light mode, you'll get some light gray text on lighter gray background somewhere, but if you use dark mode, then you'll get some black text rendered on a black background elsewhere. And even if not involving light or dark mode, same misery with whatever themes like "Adwaita" and others, some things will work in one, other things in another, I've seen a PDF viewer that made everything black text on black background in some desktop themes... A PDF viewer can't even independently choose its own text and background color without the desktop environment messing with it?
No theme I found anywhere has _well visible_ scrollbars, they all seem to love making them as subtle as possible so you can hardly see where your scroll position actually is. No theme I found anywhere has a _clear visual distinction_ (different color, not just a subtle shade difference) for the selected window vs the non selected ones. This would be _extremely_ handy for knowing in what window you're typing now, even windows 3.11 got this (and the scrollbars, and the ability to customize your colors) better
While not latency, it's still a thing they just can't get right, and when things were less overdesigned it actually worked better, so what was all this for?
> If you set light mode, you'll get some light gray text on lighter gray background somewhere, but if you use dark mode, then you'll get some black text rendered on a black background elsewhere.
> a PDF viewer can't even independently choose its own text and background color without the desktop environment messing with it
It can, it just chose to reuse the theming settings of it's platform (be it QT or GTK, or whatever) instead of forcing them.
The desktop environment is simply setting the defaults for the platform and most applications use them instead of forcing colors and themes and font.
And you can just try many combinations of themes + window managers + whatever app that fits in a desktop environment you want.
Maybe what's exactly to your liking doesn't exist yet, but the beautiful part it that it's a lot easier to make it for Linux than for any other OS because everything is open.
Yes theming in particular has gotten complex, but that's largely because of the application domain. We now abuse electron for everything. And, if it's any consolation, it's still 100x better than Windows, which can't decide on less than 12 themes for its own built-in applications, let alone third-party apps.
It wouldn’t surprise me if Microsoft could turn a knob and get telemetry data from millions of devices, and feed that back to the software graphics authors.
Certainly both Intel (https://www.techpowerup.com/312122/psa-intel-graphics-driver...) and Nvidia (https://nateshoffner.com/blog/2017/05/disable-nvidia-telemet...) collect such data themselves (opt-in in both cases, so they may not get much data from the most hard-core gamers)
This is most obvious in places where a lot of coordination is required, for example in supporting proper color correction throughout all applications, or decent support for advanced printer functions.
There are many incremental changes, but we often get stuck in local minima for years.
Still, I personally like that one can (relatively) easily watch what happens under the hood. It's not entirely clear to me why Windows and MacOS must remain closed source.
It's really scary what you can do, to the point that I often asked myself 'why allow this?' - seeing as hits on certain APIs took me to blackhat forums and articles about writing exploits.
More power to Bazzite and Valve, the sooner games app run in other OS the better.
I'm pretty sure that Minecraft launcher was made since that (2014) acquisition?
Even better, most of the tech stack is open source and contributions are welcome!
I never really understood Bazzite's immutable fs thing. Can one install standard dev stuff (i.e. compilers, ides, etc) easily under bazzite?
This use case is the main reason why I lean towards maybe using cachyos
- IDEs are no problem. Editors will "just work" for anything you type into the app store - Bazzite handles the special cases for you and installs them through brew taps or Flatpaks.
- For development it's basically just like a Mac where you also can't install system-level packages: Node, Python etc work through brew / nvm / uv same as on Mac. Development that involves containers will be unchanged from a Mac. For compilers specifically, same as on Mac: Install it through brew, or if you need a Debian or Fedora base you do `distrobox create` and you can apt-install in a transparent podman container.
Immutable filesystem-based operating systems became fairly widely used as the "base" system for Kubernetes nodes. Because on a container-focused system, you never need to touch the rootfs.
This started as a project called CoreOS[2], which was eventually acquired by Red Hat for its OpenShift (Red Hat Kubernetes) platform.
On servers, immutable rootfs makes a lot of sense. Silverblue (et. al.) was an attempt to see if that concept translated to Desktop systems well. Reviews are mixed. Some people swear it's the best thing since bread. Other people claim it's worse than having dental work done.
I'm personally somewhere in the middle. I think the concept is good, but if you want to do anything to change the core system, like installing custom video drivers, it quickly becomes a pain. I like to equate it to the "n00b"-OS. People who "just want the damn computer to work", immutable is great, because neither they nor an application can do anything to really break the system. On the other hand, it really limits (without complex work-arounds that other systems don't need) what "power users" can do.
In "the perfect immutable OS world", you would never directly install any application; instead, you run everything in a container (i.e., Flatpak). So you have layers of protection: an immutable root and a container-based permission system; the worst* thing an application could do is blow up your home directory. But if you manage permissions correctly, the most damaging thing would be an application blowing up only itself.
[1] https://fedoraproject.org/atomic-desktops/silverblue/
[2] https://www.redhat.com/en/technologies/cloud-computing/opens...
(obviously you can modify the filesystem if you really really really want to).
Bazzite is gaming oriented version of Fedora CoreOs. There are many different versions. I am running bluefin.
I've tried a lot of desktop linux distros, and to be honest, immutable linux feels like the future. Anything you do can simply be rolled back. Break something? Just roll it back.
And if you run something like Bazzite, but want to try out Bluefin-Dx which is developer oriented, then you can rebase your existing installation. If you don't like it, just revert back to Bazzite with a single command.
However, it's desktop oriented. Don't run CoreOs on a server.
Why not, this kind of management seems ideal, A/B safe testing for boot.
Lots of containers to go around these days, people are familiar with them and how they work, seems like an obvious sane choice.
You can if you're going to target /usr/local, which should be where make install installs if it's following the FHS correctly.
Huh?? I think you meant something other than CoreOS there.
So I'm using Nobara instead. It's a different Fedora-for-gaming but has most of the same improvements. It is a traditional system, not immutable. CachyOS is also very popular and that gets you an Arch-for-gaming. Just yesterday I learned of PikaOS, a Debian-for-gaming.
The main thing all these gaming-customized systems are doing is getting graphics drivers and proprietary codecs installed for you easily.
There is also a risk that the person may be malicious from the start, sell out, or simply get malware. Given the nature of the ecosystem a malicious release to a previously safe package could propagate incredibly quickly.
Where there are multiple steps for a package to get from developers machine to yours and each is slow enough for malicious behavior to be noticed each step adds friction and decreases the chance of ultimate success. Where all steps are nearly simultaneous your risk multiplies with each step in which a different person has their hands in it and if any of them are malicious or compromised you are screwed.
Requires a different way of working with projects though, so understandable if that's not your thing.
Sometimes it feels like I'm just being asked to install a real linux distro inside my linux distro so I can actually do things. Here's you nice shiny desktop and app store! Oh you want to do more than browse the web? Better install linux again in a VM.
Maybe i'm just stuck in legacy paradigms, but I kind of like just booting IntelliJ and picking the project i'm on today.
Or sometimes I want to move stuff between projects i'm working on, that's a lot easier if my one IDE instance can hit them all at the same time.
I disagree. Immutable distros are great for developers, you set your dev env up in a container environment and when it goes pear shape you can just tear it down and start again without needing to worry about leaving a mess on your host OS.
For example i just need docker for webdev and there is bazzite-dx basically bazzite with docker and few things added. Works pretty great, sometimes when something goes bad i rollback the image and wait for future version.
https://docs.bazzite.gg/Installing_and_Managing_Software/rpm...
Outside of that there are commands to install packages directly and some things must be installed that way.
You can also use fedora toolboxes to create containers mounted on your home folder, though it is clunky.
And thats exactly where free software shines. Enough people fixing issues they deem worthy of spending time on means the overall software will only improve with time.
I bet if someone like him made enough noise, people at MS would pay attention.
TBH with the onslaught of LLM CLI’s like Claude I am a lot more promiscuous in my Linux OS choices as of late. I used to stick to Ubuntu because that was the Linux I knew, but the “interface” has become the same to me because I just ask Claude to help me achieve a semantic goal without having to score the web for the appropriate keys.
Who knows, maybe I’ll eventually swing the other way and give NixOS a try finally.
- brew
- podman
Here’s an example that bit me: I wanted to run k3s/k0s but both have issue with Bazzite. Those were hard stops for me.
I switched my daily driver / gaming rig to Fedora a few months back.
Everything seems snappier compared to Windows, but not sure if it’s in my head, and I’ve been very curious about gaming input latency. This helps answer some questions.
I recently switched to hyprland and I’m very interested how that fits in these results. hyprland uses Wayland so I hope the author might revisit now that hyprland is gaining in popularity.
I’ve considered using gamescope to hopefully get in front of some of these concerns, but I’m on nvidia and there is some discussion about it not working well there.
Now the author's got me thinking about gaming-optimized kernels, which I did not realize was a thing.
I play competitive fighting games so input latency is a huge concern. Would love to hear from anyone else who’s been down this path.
The difference could be much larger on a slower monitor. However the differences between Wayland and X11 as protocols is negligible. XWayland as an implementation looks to have a limitation.
And the non-xwayland numbers are all within a single ms of each other.
---
Not to undermine the measurements of the author (agree with you, it's a cool effort), but my read is that this was basically proof that it doesn't matter.
Imagine a game that's just a pistol duel. When the kerchief hits the ground, players press a button, first person to press the button wins.
In an ideal world, with no delay whatsover, the probability P(A) of player A shooting no later than player B is 100 (because both players shoot at exactly the same time). If we add 5 ms of delay to player A, then P(A) = 0 (he will always lose). If then we add 50 ms of network latency to both players, P(A) = 0 still, because 55 > 50. If we instead make that 50ms delay 50ms +- 10ms (ignoring normal distribution for the moment, pretending every value in that range is equally likely), there's a 25% chance of player A experiencing an unwinnable delay (any network delay value > 55ms results in a value greater than player B's max of 60ms), resulting in a probability of P(A) = 75% * 50* = 38%.
If we make the network delay 50ms +- 5ms, then P(A) drops to 25%.
The saying we have in bike racing marginal gains is "leave no stone unturned, but turn over the big ones first"
So sure, first make sure your internet connection is solid. Then make sure your hardware and game settings are optimizing FPS to a reasonable point of diminishing returns.
Then make sure you don't use XWayland
There are weird consequences of this, someone can shoot you after you duck behind a wall because you hadn't yet in their version of the game. An enemy moving left right repeatedly is likely vibrating in your version of the game faster than the rules of the game would otherwise allow. Etc. Ping matters, but it's not comparable to input latency. Input latency really does mean that you can click at the right time and miss your enemy. It really does delay how fast your camera spins when you move your mouse. Etc.
The visual latency on gaming could be different but I suspect not, I think it is more an issue that some people fixate on the latency, others just accept and adapt to it. Games do have more possible sources of latency, visual, audio and io, and if these can all be different that can be difficult; years ago I had an issue with this and midi, that one really threw me off. Games may also not model the physics of sound? does sound travel slower than light in games? That could worsen the problem since sound does travel slower in real life and we are used to that, we expect it.
Consider also that people neither run the latest thing nor the fastest software and remember potholes long after they are filled. EG it wasn't that long ago that wine was running on xwayland almost exclusively for instance and the majority of popular titles run via wine.
It’s possible that Gnome/KDE/whatever has wildly different latencies on X11 vs Wayland.
I’d be interested in seeing that test.
But it’s great to know the difference is so small here, which is what I’d expect.
Of course, the brain adapts. I played an online shooter at >100 FPS using my 144 Hz monitor (when that was the best). I visited a buddy who's PC could only muster 30-40 FPS, and he asked me to show me how I played, since he struggled.
I sucked so bad due to the extra input lag. Felt like my character was running in a pool of molasses. But after about 15-20 minutes my body adapted, and my performance started increasing and my hits started connecting more reliably. I got to about 90% of my regular performance after 30 or so minutes.
So while one could tell back to back, one could also compensate. But at some point the extra input lag will matter, and will get you killed or make you miss that shot. Hence why I could only get up to ~90% of my normal performance on my buddy's PC.
[1]: https://jov.arvojournals.org/article.aspx?articleid=2213289
If you can be accurate to below 5ms, an additional millisecond of input lag makes a big difference.
I'll concede that pure prediction absolutely exists in FPS games-like tracking a falling player with the LG in Quake 3 or landing a predictive mid-air rocket. In such cases smoothness of high FPS helps, but adding a 1ms drawing delay to those 500FPS (what the article is about) won't be noticeable at all because your brain naturally calibrates out constant hardware delay.
So yes I agree over time you wouldn't be able to tell 1 ms from 2 ms, but a skilled player doing back to back comparisons might be very different.
Adapting is doable, but after years of rhythm games, yeah, no.
I've been a fan of Hyprland for gaming so far. Much more configurable for things like VRR/tearing and other precise tweaks via Gamescope than when I was on AwesomeWM with X11. Been especially nice having Lua for configuration, which finally feels very familiar with my AwesomeWM roots.
I have very fast internet on both sides, both fiber to the home, with only the tablet running moonlight being on WiFi.
if [ -z "$DISPLAY" ]; then
/usr/bin/startx /usr/bin/dbus-launch "$(readlink -f $0)" "$1" -- -layout singleLayout
fi
pw-cli i || (pipewire & sleep .5 ;\
pipewire-media-session &\
pipewire-pulse &)
cd "$DIR"
exec unshare -rcn $ENGINE "$IMAGE" $ARGS
Gamescope replaces X or Wayland so you just run it and then the app you want it to open
The XWayland result is 3ms slower, which at refresh rates this high makes me wonder if it was one frame behind.
Running the tests at 120Hz or even 60Hz might be more interesting because we could start to separate out very small differences in timing from the much larger effects of being a full frame behind.
What's probably happening is that other wayland compositors are slower than KDE Plasma wayland which he tested. And people report that experience. Some other wayland compositors might even be faster than plasma. But what is for sure is that every wayland is very different from every other wayland.
In any case the methodology in the post is sound and should be used for benchmarking in the future.
Only xwayland showed that result. The difference was only a couple milliseconds. That’s in the range where I start to doubt that people are feeling the latency difference. If it was 10-20ms I could believe it, but not when it’s a couple milliseconds.
The author of this post did a good job of getting all of the other confounding settings out of the way. It’s possible that the people complaining that Wayland was slow were starting from an unoptimized situation and as part of switching to some low latency variant they set all the correct settings.
A better way to interpret this data is to normalize by the vsync interval or the swap chain depth. The slowest config is 2 frames slower than the fastest. At 500Hz this is 4ms extra which is likely imperceptible to everyone but elite pro gamers. At 60Hz this is 34ms extra which is pretty noticeable to even casual gamers.
I certainly want my latency as low as I can get it. But I'm pretty skeptical that anyone is truly feeling the difference of a couple ms.
Moving the mouse and then pressing a button, or pressing one key and then another, are both cases of predictive moves.
So it seems one shouldn't rely on framerate when talking about the limits of sensing input lag, at least in general.
[1]: https://jov.arvojournals.org/article.aspx?articleid=2213289
We notice latency. Neil Peart could almost get sample-precise timing, he was so godlike.
But I wouldn't necessarily say that people can notice it everywhere in every state of mind. The medium, context etc all matter a lot.
Compositing requires the GPU to do some extra work to draw the frame to be presented. This typically takes very little time (much less than a full frame period). Additionally, most wayland compositors will bypass that extra step if an application is full screen (wlroots calls it "direct scanout").
Also some wayland compositors keep track of timing and delay the final composition until right before it is time to present the frame in order to reduce latency.
Turning off compositing before launching a game is maybe a bit misguided, sort of like turning on the "classic theme" in Windows 7 before launching a game. It might save some memory, sure, but latency should be identical.
Should be, but very clearly isn't.
All of this hassle, forcing so much more work on DE/WM devs, for the sake of 'better security' in scenarios that don't really apply to 99% of linux users, with the promise of 'better latency' which this very article proves is false.
I tried to be an early adopter of wayland ~ 5 years ago. Found all sorts of things broken, and I'm now using linux mint xfce edition, as hopefully by the time xfce drags itself to wayland, all the bugs and tooling will be a solved problem.
Linux is about choice, but unless you're ready to write a lot of things yourself, it's outside your control how well parts of the ecosystem are supported. For an average user it's unacceptable for your entire GUI to suddenly change in a way that requires relearning, something that Mac and Windows have avoided doing at least since 2000. Even Win8 or Mac26 wasn't so disruptive. It's possibly worse for an average Linux user because they aren't just concerned with how it looks but also compatibility with advanced things like X forwarding or VNC or CRD.
It however isn't about all or indeed any of those devs being obligated to support any particular choice. You can only buy a place at the table with money or sweat and merely using something isn't contributing and doesn't get you a vote.
Arguably the problem isn't the display server its the fact that general linux usage tends to require a little understanding of what's going on under the hood than is strictly speaking desirable for joe average user especially when something doesn't work. EG needing to understand that your choice of display server is making your zoom calls not work and then having to open that whole can of worms.
The fix is honestly more labor. The trivial way to acquire more labor is with money which is hampered by the fact that so little is paid. If you want more polished stuff pay more.
No. If you tell users they should switch to a new display server, you shouldn't be surprised if no one takes you up on it if you don't provide basic feature parity.
If you tell DE/WM devs they should use your new protocol, but say it's now their responsibility to do all these things that the old display server did for them, don't be surprised if it doesn't get much traction.
I don't for the life of me understand why wayland took off. It's provided no benefit to the average user, or DE/WM dev, and a whole lot of hassle.
From what I remember, Wayland is a thinner layer than X11, basically handing clients pointers to shared buffers for them to write into, which seems better than X11's server approach. Thought maybe people were eager to switch for latency reasons, but this benchmark is showing otherwise. And would think Wayland is more efficient too, but I haven't noticed or heard of a difference.
2. There are currently many high-quality implementations, Kwin being the best IMO.
3. X11 devs didn't want to maintain it, nobody "made them" stop. You or I could maintain it, but I also don't want to, so, here we are.
4. Yeah the wayland transition was rough but I think there's basically no universe where that transition would be perfect. They're architecturally different things. The Apple Intel to M series transition wasn't perfect either and there were A LOT of bugs. These things just happen.
2. Yeah, the major projects like gnome and kde had enough developers to dedicate to porting over to wayland. Most existing DEs and WMs found the porting process to be very difficult and didn't even bother. This would have been solved had they released an implementation with feature parity. See #1.
3/4. I don't care. I consider xorg to be 'feature complete'. There are few benefits to the end user switching to wayland beyond some niche use cases like multi-display scaling, and HDR. The small benefit of those is nowhere near worth the headache they forced on users when the major DEs started going wayland only.
Overall, I am happy sticking with xfce since it's taking the slow road on moving from xorg to wayland.
But it does not matter that they now have some kind of a solution for a use case for which they denied that it even exists for a long time. I will avoid Wayland because I do not like the direction and the interests that drive it.
Yeah, because it wasn't ready. Pretty much no one recommended using it back them, if you thought it was ready you were either misguided or misled. It's time to put your skepticism aside and give it another try, there is a pretty good chance it's going to work great now.
Even Valve Steam OS is now adopting it. It's a pretty good sign wayland is a viable replacement for X11, while bringing it own things.
It is completely counterfactual that "pretty much no one" was recommending it in 2021
Fast forward to 2021 and most users experience with wayland was that GDM (on some distros) would try to start on wayland mode but couldn't for some reason and would fallback to X11. Note: I do think that the distros that were pushing for this were being reckless with their users. Introducing it as an opt-in would be much better and would still lower the barrier for testing. Also, KDE didn't even offer a wayland mode, taking until 2024 for it to start defaulting to it and any other wayland desktop had to be sought after by the user.
So really, I think people only started to "suffer" wayland's wonky-ness for the last three to five years depending how you view it. And honestly the last year or two has been pretty usable.
- Effort spent writing sway that could have been spent improving i3
- Effort spent writing GNOME-Wayland that could have been spent improving GNOME
- Effort spent writing KDE-Wayland that could have been spent improving KDE (much of this work duplicated effort with GNOME-Wayland)
- Effort spent writing wlroots to try and mitigate the effort being wasted by people writing bespoke compositors
- Wine/Proton devs needing to waste time getting every windows application to work in Wayland
- Firefox needing to target both Wayland and X
- A bunch of graphical toolkits and window managers that were working perfectly fine but will now be "left behind" since they lack the maintainers to support a porting effort
- low-level toolkits like SDL needing to implement their own window decorations now that they're not guaranteed to be provided by the OS (what?!)
What Wayland proves to me is just how easy it is for a small number of developers to unintentionally sabotage productivity in a much larger project.
I'm complaining on these developers' behalf, not bemoaning them doing what they were more or less forced to do. If glibc decided tomorrow to remove the `malloc` function from their library and every C project suddenly had to implement its own allocator, that would be a massive waste of everybody's time, no?
Robbert van der Helm has a very popular (in the Linux music editing world) program, yabridge, which enables DAW plugins written for Windows/Mac (aka most of them) to run in Linux DAWs. It leverages Wine and a cascade of transparent window layers that position mouse clicks, menu positions, and graphics updates. It's crude, it's clever, it works. Musicians who love Linux rejoice!
Enter Wayland.
Mouse clicks no longer land where they're supposed to. Reparenting a window doesn't work like it did on X11. Edits to the yabridge source code are a moving target because WINE devs (who are largely paid professionals, which occasionally keeps out a handful of useful merge requests; these maintainers DO need to balance the needs of ALL Wine users with every edit) keep editing winex11.drv (which has all the display and input functionality touched by yabridge), and robbert-vdh shares in some issues that he doesn't have much time to make changes, especially when they might break again later.
For over a year, yabridge is broken.
Advice is given to pin wine-staging 9.21. (Wine 11.0, released 7 months ago, is the current stable version.) Yabridge users share tips on how to install/build Wine 9.21 long after their package manager has deprecated it. You can still run yabridge on newer Wine, mostly; one workaround is to always drag your plugins to the upper-left corner (if the window allows it; I couldn't do this with REAPER in Fedora KDE without disabling snapping, which I want; for months, I used the non-GUI plugin panel in REAPER). A few plugins just stopped working. Sometimes users will log what happens and upload this and it even eventually gets explained---for that specific case---but often not solved right away.
One maintainer of Wine made edits both in Wine and yabridge specifically to get yabridge working again. I don't know if he did it for a CodeWeavers user or just out of the kindness of his CodeWeavers-paid heart. This pull request covered 90% of users, but a few still complained it didn't work in X DAW with Y plugin on Z distro. Because it doesn't always work, it becomes a branch; technical users will be able to manually get their DAW/plugins (often paid, sometimes a subscription, so there's an incentive to use them) to hopefully work and hopefully for the long term.
A few DAWs even change their plugin code to support, say, keyboard passthrough, which should theoretically be handled by Wine or/and yabridge but still has issues. These DAWs could be getting new features or addressing USB interface latency/throughput/routing, but instead they're dealing with fractional scaling, plugin support, themes, and a bunch of other graphical details that worked previously.
It absolutely wastes developer time because now the rules of "who handles what" (in every major distro and DE) have changed for anyone with a GUI and because developers are often users who have no choice in the changes and don't have the background to just know---or the free time to learn---how Windows and Wine and VST and Linux graphics work, and even if they did, the MR/PR they write and submit might not get merged at all in the chain of programs needed to get FabFilter to run in Bitwig on Ubuntu 26.04, because it doesn't also let Auto-Tune run in Ardour on Fedora. (This is contrived, but you can read through the 100+ open yabridge issues yourself to find the actual problems being experienced.)
By the way, the "ya" in yabridge is an abbreviation, "yet another," because it worked where other VST bridges did not. It wasn't the first compatibility layer for VST and won't be the last. Either robbert-vdh will change his codebase to work with the new methods Wine uses to handle Wayland windows, or there will be a new bridge. If you're wondering why there are 20+ actively maintained and reasonably well-known terminal emulators (How many could I rattle off without looking it up? Alacritty, Ptyxis, Foot, Wexterm, Terminator, xterm, Konsole, Guake, Kitty, ghostty, xfce4-terminal, and does Putty count?) it's because of situations like this, where the new paradigm forces old devs to keep up and implement popular feature requests or get replaced.
All of this doesn't even consider whether a DAW is Flatpak or not. (Hint: the failure modes are different.)
-----
Users can't always get old hardware to support the old software that worked. Users can't always get every version of old software they knew to work six/eight/ten years ago. Users on old software have to figure out vulnerability patches and how to handle subscription and dongle-based plugins.
(Windows 11 is a bad experience, I don't even count this as a fallback.)
If the decision makers of Linux are going to make changes that break workflows, they absolutely should get [productive, kind] pushback. We shouldn't have to downgrade our OS UX and free cash reserves to a Mac Studio just to be able to do the things we already could do in 2018.
-----
I suspect video has the same problems. DaVinci Resolve exclusively supports Rocky Linux 8.6 on kernel 4.18. Why would BMD have qualms about targetting a more recent version... unless there's some friction building this support?
It's the epitome of science, comparing it to a generic vim vs emacs flamewar which is pure subjective opinion is pretty baseless.
It’s like going from 240Hz back to 60Hz, or even 240Hz to 120. People can tell.
There is a native Wayland driver for Wine/Proton but it's enabled through an environment variable, not by default. This will probably be default in Wine 12/Proton 12 because Valve wants to squeeze as much performance out of SteamOS as possible. The gaming mode UI runs under Valve's own Wayland compositor (gamescope) already, but games are currently in nested XWayland windows.
which is still half a frame at best so I think any blame here would be just on a particular game being slow on inputs
It has been ready for users whose sole usage is an editor a terminal and a browser on their single screen intel laptop as long as they didn't also open youtube since 2015.
Imagine the boss's nephew joins the firm. He knows less than nothing and is worse than useless everything he touches turns to shit. People understandably complain. After 10 years of development and other people's time he is now moderately capable at his job. People still bitch. They aren't lying or wrong. They just aren't current.
The length of a blink is irrelevant. People notice latency especially inconsistent latency. The perception of xwayland being laggy in latency sensitive context like gaming is accurate.
No. Wayland is slow on its own. You can test it without Xwayland.
I wonder where the XWayland's added latency comes from though, it seems suspiciously high to just be easily hand-waved as overhead.
Wayland fan: You need to switch to Wayland. X is deprecated and has been for years! Wayland is the future.
User: Okay, I tried, and it's broken/worse.
Wayland fan: No, you don't understand, Wayland is just a protocol. It's your implementation of Wayland that is at fault, not Wayland itself! Wayland is still great!
User: But X was working fine...
If your protocol you pushed to replace a working implementation invites a dozen poor implementations which people routinely confuse, that's a problem with the protocol and the push to get people to use it.
And on that topic a question I have, seeing as wayland is "just a protocol" why can't the client application talk to the compositor server over a network socket instead of a unix domain socket? Update: reading the spec I found my answer, Wayland buffers are shared memory surfaces... So really wayland is not "just a protocol"
We stream OC2[1] with our mod preinstalled over WebRTC. This ensures that kids/schools don't have to try and install the mod. This is particularly important since we support running on school provided hardware. Installing a game without a mod would be hard enough. Added advantage though is kids play with a virtual (on screen) gamepad on iPads in Mobile Safari.
Game instances run in Docker containers in Kubernetes/k3s atop very outdated nVidia hardware. Given we're already going across the Internet into school networks, we've tried very hard to optimize latency across the board. Using NVidia NVEnc with DMABuf (zero copy) etc. We're unfortunately using XWayland at present so experience the documented input overhead. Although our inputs are virtual devices at this point, so the overhead may be a bit different. Trying to optimize this whole thing end to end has been a challenge. I would say that performance is currently "acceptable".
OC2 coding: https://www.youtube.com/watch?v=ITWSL5lTLig (not streamed in this case)
[1] We've bought a limited number of copies of OC2 and pods claim a license on startup. If we're at capacity, kids play something else.
This is pretty much optimal, and you can't really do much better than this.
Once a stray window appears on top, or something makes the compositor think it can't do this, it'll do the intermediate step of compositing your app window with others into a temp buffer, and render that.
Sometimes the unredirect breaks for some reason (I remember a case where for some inexplicable reason my app kept creating a window 1px smaller than the screen height), or you use XWayland, you get bad latency.
Since this is a fundamental constraint, other compositors on different OSes must work like this, and you can run into issues like this as well.
Another thing - Wayland afaik started exporing 'display planes' - which are a HW feature of GPUs, that allow it to composite multiple layers together - which means the game can render at full FPS and all the windows on top will be drawn into a different plane and get composited with no ill effects - not sure if this is actually used in production yet.
Especially in competitive gaming, I often see people targeting frame rates way beyond their display’s refresh rate. I’m not sure whether this actually provides a real benefit or whether they’re chasing a placebo effect.
Am I out of touch, or is it the children with colored LEDs on their DRAM sticks who are wrong?
> Especially in competitive gaming, I often see people targeting frame rates way beyond their display’s refresh rate. I’m not sure whether this actually provides a real benefit or whether they’re chasing a placebo effect.
A newly rendered frame can cut-in during scan out. This shows up as tearing artifacts where the frame is changed while being sent to the display, but it allows fresher pixels to hit the screen below that tearing line. So each frame on the monitor can be a mix of multiple rendered frames.
It’s not as good as having variable refresh rate display with high refresh rate, but it does reduce latency.
For less action based games it’s common to turn vsync on and pace the frames to the refresh rate to eliminate this tearing.
Sure "only 30 fps" is big news, but pretty sure "quality mode target 30 fps" is still norm.
In Xbox, many games launched at 30 fps only, then gained 60 fps mode.
Until I see majority target at least 60 fps as minimal mode, my point IMO stands.
In the PC version Resident Evil 5, hit reg with a particular boss is tied to fps, so I had to lock it to 30. Going from 165hz to 30hz was noticeable, everything above 60 just felt a bit smoother to me but 30-60 was night and day. I rarely notice it when playing on console.
Ironically the only game where I've ever felt I had to enable performance mode was Life is Strange. Not the sort of game you'd think would suffer from 30hz!
> Depends on the game. Many shooters have always targeted 60 fps (COD / BF iirc)
Define always. I don't know about COD, last COD I played on console was targeted 30 fps on PS3 and the same was true for every PS3 shooter. BF5 ran at 50fps on average. Battlefield is really an exception to the rule because they lowered graphics waaaay lower than on PC to get reach 60 fps. IIRC ps5 Pro can reach whole 120 Hz in BF6.
PC ports of Capcom games are always piss poor so no surprise there.
Biggest FPS surprise FPS for me was Destiny 2 where PvP damage to you was tied to your FPS.
If they are chasing a placebo effect, it's a really powerful one, since all the actual competitive people are often willing to sacrifice all detail and quite a lot of resolution to get those stupid high frame rates.
I can see the difference too, but the diminishing returns usually make it not worth it, since I prefer the eye candy better details and higher resolutions give me.
Also, some games can adjust the resolutions on the fly to keep a consistent frame rate. It's only become a feature on modern games, but I believe that's mostly a historical accident. PC games could often run on much worse hardware than they were actually designed for (with minimum requirements often being absolute minimums, and not 'this is what we developed for'), so people played them on low frame rates, so that kind of jank was often more culturally accepted on PC, and if you didn't want that experience, you could always upgrade. While on console, there was no upgrade path, and games were optimised for that one config, and thus never allowed to drop too far into the red (and dropping resolution is often a better option in those cases).
This is something that could be tested experimentally, but isn’t, because the subjects we would need to test this on are all sponsored by hardware vendors.
The games I have in mind though still have those details present on lower settings. Instead they just look like shit rather than disappear. To be fair though, that just might make those details have higher contrast and not fade into the background as much.
For example, it used to be popular among competitive CS players to use 4:3 resolutions on 16:9 monitors. Since the target’s vertical position is much more predictable than its horizontal position, it’s supposedly easier to aim if the image is stretched wide.
But these games only presented 4:3 options at low resolutions. This might have introduced the notion that low resolutions provide an advantage in general.
It's probably mostly a habit thing. Most of the pros started to play these games back in the 90s, when 4:3 was the standard. Add in that playing all the low resolution options are 4:3 (and the 16:9 equivalents will add resolutions rather than take it away; the 1080p is usually 16:9, so 1920x1080, but 4:3 1080p does exist, and it's 1440x1080, which is a lower resolution), it's no wonder 4:3 stuck around as long as it did.
In video games you essentially have one giant loop that runs every frame (today it's more than that, but at its core it's still that). Producing frames faster than the display’s refresh rate can still reduce input latency because the next display refresh is more likely to use a recently generated frame. It does not necessarily mean the game receives more input events, but it can process and reflect those inputs sooner.
Not placebo, but diminishing returns become significant, and the benefit depends on frame queues, VSync, VRR, whether the game is CPU- or GPU-bound, and how its input and simulation loops are designed.
But yes, given the limitations of the hardware, they often offer two modes - a high framerate but lower quality mode and a high quality but lower framerate mode.
>I often see people targeting frame rates way beyond their display’s refresh rate. I’m not sure whether this actually provides a real benefit or whether they’re chasing a placebo effect.
Pixel refresh is only one part of latency. A higher framerate will lower several other parts of the overall latency. Monitors Unboxed has charts that visualize the amount of latency for each step.
Playing a cinematic game with a controller (especially with auto-aim) at 30FPS with vsync is fine. Playing a first person shooter with a mouse, or a game where you control your camera with a mouse, at 30FPS with vsync feels very bad.
That's my theory on why the priorities are different, at least.
Depends on the engine. Anyone remember Quake 3's multiple of 3 frame rate speed hack?
Could this be to reduce input lag?
Of course, where gathering this sort of data _is_ useful is diagnosing and fixing real latency so it obviously has merit. I just think it's ok to lean on taste and experience for most things UI/UX, including latency.
Another point, by couching the comparison in a less technical form (for example, rating a configuration/setup out of 5 stars or some similar approach), it protects from being "too methodological" during testing and data-gathering. One possible issue with the author's methods is if there are degenerative cases that are common in the day-to-day experience of a given configuration, they are unlikely to be present during the precise test that they have setup.
The games I play (ITGmania) measure accuracy to the tenth of a millisecond, any fluctuation in your hardware latency can ruin your scores and nothing really is more annoying than an inconsistent setup where the latency change between or during a session is absolute hell.
Vibes and latency don't belong in the same sentence at all imo.
Not sure if I can follow but...no?! My first TFT-TV had 2 seconds input lag. Impossible to play video games on it. That has nothing to do with feelings.
Already 10ms delay has a measurable effect: https://www.youtube.com/watch?v=5qjSGEOEaXo
In the case matters most, it's not a placebo.
Imagine 2 FPS players with identical ability who play against each other. If one has a system with 4ms latency and the other has one with 5 ms latency, the former will statistically have the upper hand, even if the players can't, in isolation, notice a difference between the 2 systems.
https://www.youtube.com/watch?v=vOvQCPLkPt4
Even if everything else is perfect, display latency on modern panels is 1-3 ms. So all of the input processing and display pipeline can't be taking more than a millisecond or two and that's remarkable.
An update to Dan Luus articles with modern tech like these high refresh displays, fast gamer keyboards/mice etc would be great thought!
It would be so cool to get that to work in Linux. I know the instrument code is in hid-sony. Here are some open tabs I've got in case anyone's curious:
- https://pascal.giard.info/techreports/nguyen-daniel-autocali...
- https://www.niangames.com/articles/reverse-engineering-rockb...
- https://github.com/torvalds/linux/blob/master/drivers/hid/hi...
>Avoid XWayland. It added 3.13 ms of latency, more than all other effects combined.
When rendering 60fps on a 60Hz display every frame takes approximately 16ms to render. Then you have to add TV latency that’a probably around 20ms unless you have a very nice OLED TV. Wireless controller latency is around 8ms I think? Then your imperfect human brain adds even more latency especially when you’re tired after work. That 3ms is not perceivable. Make that 5ms even. Nobody would be able to tell a difference in a blind test.
What you are reading from the readme notes that it calls into xwayland only when gamescope (wayland compositor) is nested within another compositor (say kwin or mutter).
gamescope itself is wayland only, and when run on SteamOS is has no xwayland latency...
It doesn't yet mean that it suffers from the latency measured in the article, as the problem could very well be in something else, such as how KWin integrates with XWayland or how GPU drivers interact with it (especially that Nvidia drivers have a history of making XWayland suffer).
E.g. I have an old laptop running a browser playing some internet radio stream. Eventually the screen blanker (without locking) activates.
Some real life event makes me want to hit the space bar to pause music. But the modern screen blank has decided that it should eat/ignore key presses while blank. So hitting the key doesn't pause music. I have to wait for the screen to light up before it will be possible to trigger the pause, and this delay feels interminable!
I seem to recall that in the old days the input remained active to the focused window even if the screen was in a power saving state. This power saving was not conflated with screen-lock security etc. I much prefer that. I think this was because DPMS power saving was an underlying X server behavior, not delegated to a screensaver/lock application?
I'd also be partially satisfied with the async behavior of old terminal programs. My inputs should be buffered and processed even if the effects haven't returned to the screen yet. Then I could at least hit keys twice and be trained to know that one would unblank, the other would pause, and all would be well (eventually).
The current behavior is like having a temporarily numb hand, and being frustrated waiting for sensation to return before I can operate anything!
Edit to add: I don't think it has too much to do with display latency.
It is some convolution of the desktop environment and display server deciding that keyboard input doesn't go to the focused window while it is in this nominal screen blank state. This Fedora 43 on a boring generic Thinkpad.
My system flashed the screen white and played a note. The idea was to have the camera detect monitor brightness and detect the offset from the audio note. I'm practice the brightness of a 40 inch TV didn't seem to impact the video of the insta 360 link webcam.
(I ended up vibe coding a Python GUI to quickly allow me to push through video frames and show the audio frequency. I could quickly type 'v' (video) where I clapped and 'a' (audio) where the waveform changed. It would then tell me the offset...
---
David Ramiro built his m2p-latency and compared X11 vs Wayland in his article Building an Input Latency Meter (Because ‘Wayland Feels Off’ Isn’t a Metric) as well, coming to similar conclusions:
Native Wayland is on par with native X11 (all tied at ~7 ms), while XWayland roughly doubled the latency in his tests.
farnoy did extensive testing with the Open-Source-LDAT in his post Linux latency measurements and compositor tuning, also concluding that XWayland should be avoided.
Also, both the input latency (usb controller, and its driver), and screen latency (input latency + processing + update delay) are supposedly also affecting all measurements, but hopefully somewhat consistent or at least filtered out.
Wayland is fine. People should use AMD and KDE Plasma.
I'd avoid Nvidia to begin with.
The biggest hit is Vulkan performance (~20% less than Windows iirc) but for desktop and casual gaming use, Nvidia's proprietary drivers are perfectly fine.
I have friends who are stuck on Windows not because they play games with Windows-only anticheat, but because theyve been told by GNU heads that NVIDIA drivers simply don't perform acceptably on Linux.
edit: I should also point out the mouse acceleration curve, which if you don't fix it is different between X11 and Wayland compositors. That really messes up the "feel" of things.
[1] Github: https://github.com/DelusionalLogic/Frametime, Blogpost: https://www.jnsn.dev/posts/frametime/, and followup: https://www.jnsn.dev/posts/fastisslow/
Or maybe it just came out of nowhere and was never true.
I wonder what is considered "unnecessary programs" by the author. Is "apparmor" or sandboxing considered in this? Or just user space applications (browser, discord, …).
I wonder if input latency would be improved if you ran setup as `root`. I wouldn’t do it for security sake, but just curious
That said, this is a pure gaming PC with a Desktop Linux installed, it's not like there's a lot running on there in the first place: no 5 random docker containers, no AppArmor and nothing in kernel space other than what comes by default with CachyOS.
Latency numbers are written with three significant digits (4.21 ms). I'm curious about the accuracy of the measurement device. If it can measure tens of microseconds, I'm impressed. If it can't, the conclusions in this article should be taken more coarsely.
They also have repeated measurements which improves the precision.
> Yes, but nowhere near enough to explain why Wayland is generally perceived as much worse than X11.
Personally speaking: Wayland has massive stutters when the system is under load, most notably on the mouse pointer. X11 doesn't.
I do know it is favoured by ricers with animations & transparency but I just use it to tile stuff. Think I selected it over sway & i3 due to wayland support at the time. Not sure.
edit: no, this is the one I was remembering: https://farnoy.dev/posts/linux-latency
I also don't like to play above 60Hz.
But why?
Xlibre is an actively developed and maintained X11 protocol display server.
Xfree86 is dead, long live Xorg. Xorg is dead, long live Xlibre!
https://lore.kernel.org/ksummit/CAHk-=wiB6FJknDC5PMfpkg4gZrb...
Would you run and rely on TempleOS? Then XLibre is for you!
Wayland has been great for me for a few years now. I don't use Gnome or nvidia though.
You don't run GNOME on Wayland. You run GNOME's Wayland compositor, which is an entirely different implementation than Plasma's Wayland compositor.
I've not used gnome for years, but I have a vague memory of gnome/mutter running on a single main thread which used to lock up quite a lot (javascript etc). And because in X it was X that used to manage things like rendering the mouse pointer every frame, whereas in Wayland it flipped to mutter having to do it directly, the stalls were way more obvious in wayland than X, which is where I think a lot of this perception came from.
Again, not sure how much of this is accurate, but that's the point I was trying to make.
Wayland mouse movement lag is/can be/could/was in the order of several hundred milliseconds.
Its that that people notice, not 3 or 4ms difference in click response.
It's extra infuriating that online sources report the game running flawlessly but seem to ignore input lag.
DXVK_CONFIG="dxgi.syncInterval = 0; dxgi.maxFrameLatency = 1; dxgi.maxFrameRate = 60" gamescope -f --immediate-flips -- %command%
I also manually disabled vsync in the game's `local.cfg` XML file.
I love where "gaming on Linux" is going. But I have the feeling the hype on Youtube etc. is in part created by content creators, and doesn't faithfully represent the actual situation (surprise!).
My webserver is using crowdsec (https://www.crowdsec.net) to ban malicious IPs and I would guess that you are somehow unintentionally affected by this.
You can also test your IP by entering it into the crowdsec website to see if it is affected.
Paying $1900/month for an IP address blocklist for a website? Yikes.
The security and availability of my servers is as important to me as the ability for anyone to access the public services I provide. Which is why I responded to you immediately and asked for your cooperation to help me fix the problem.
You not being cooperative helps no one. Not yourself, not other people with the same issue and not me who's trying to fix it.
Crowdsec is free btw, I do not pay anything.