UPDATE: This (and, therefore, the promised bug reports) has been put on hold until I get around to getting actual evidence with the herein-mentioned RPi Pico + photoresistor setup, which is itself "delayed until further notice" because I simply have better and more important stuff to do1 right now.
UPDATE 2: Some madlad actually did it, only for GNOME though but that's still amazing
UPDATE 3: Apparently, it's like this on purpose, at least partially, and... ~~yeah, more the reason to actually get stats (for stuff other than GNOME) and then proceed appropriately.~~
Sorry to all the folks who are bound to X11 because of this issue or similar, but I just... can't. Maybe in 3 months or so. Maybe earlier, maybe later, but it will happen.
Part II is definitely coming, bug reports should probably follow shortly thereafter.
This is not true anymore, and after having considered my options here, I give up. I am not doing this, and I sincerely apologize to anybody who was actually expecting me to do this.
This is an extremely rough attempt at documenting (and failed attempt at actually getting evidence of) an issue that I've experienced with ~99% of all Wayland compositors that exist out there, that being cursor rendering latency. Basically, the delay between moving a physical input device and the cursor's location being updated is substantially longer than it is on Xorg, at least in the vast majority of cases.
If you're reading this and are like "well, I run this or that compositor/DE and have never experienced this", well, consider yourself lucky. I, and a relatively small, but still definitely real minority of individuals can feel it, making Wayland anywhere between somewhat miserable to use to simply outright unusable (I myself am located somewhere towards the latter end of that spectrum). And, before anybody goes "there is no single 'Wayland' out there, what are you talking about", yes, I am indeed aware of that, however this is universal enough of an issue that I'm willing to refer to it as a problem with Wayland (or Linux graphics in general at this point) as a whole, instead of calling out any particular compositors or desktops.
To be fair, this isn't as bad as it used to be (it definitely used to be worse), however the fact that this is even an issue to begin with makes me question how viable Wayland even is and... really, it's not a good look for any of it.
As I've said already, this is a pretty much ubiquitous issue across all (desktop) Wayland compositors, and it usually manifests itself as the mouse/touchpad feeling "heavier" than it does under an Xorg session, and can (usually) be demonstrated by moving said device back and forth/left-to-right-and-back and watching the mouse cursor's behavior on screen. It generally cannot be noticed unless one has already experienced what mouse movement feels like on Xorg on their hardware, so people on platforms like Asahi Linux where Wayland is your only option, or those who have either never run Xorg on their machines or haven't used it in a long time may not even have noticed this whatsoever, and plenty of who went from X11 to Wayland might not have noticed it either due to simply not caring about it (or possibly by dismissing it as a mouse accel issue, or a thing with their mice, or they're on a 120/144+Hz display where it's a lot less noticable (all of my displays are 60Hz so...) or...)
I am indeed aware of the many shortcomings of many input devices (touchpads, mostly, but also some "gaming"-ish mice and touchscreens) on Linux/*nix, and in fact own at least one (probably more than one) machine with "not great™" Linux support for its touchpad, however, again, it's still better on X11, so that isn't really relevant here.
Yeah, so... I tried to get evidence for this being an actual issue, mostly for the purpose of making this ever so slightly more credible, and for reducing plausible deniability. If I wanted to report this as an issue to every single relevant Wayland compositor in the observable universe, having actual evidence would be very helpful. Not critical, just useful, and would at least somewhat protect this from "you're just imagining it"-type excuses.
The method I chose for obtaining said evidence involved setting up a Raspberry Pi Pico as a USB HID mouse and having it react to a button press while also flashing an LED hooked up to it, with the intent being to measure the delay between the light turning on and the mouse cursor moving on the display.2 The actual problem here was recording this delay, with the best I could do being the slow-mo mode of my3 phone's camera, which, as far as I'm aware, slows down the recording speed by 3 times, and since the resulting footage is in 30 FPS, and assuming that it isn't faking it in any way (which it might be!), it's actually recording at 90 FPS, which would turn out to be a problem later on.
I then proceeded to set up the computers involved in all of this, with the final setup consisting of three machines (by driver name):
amdgpu: ThinkPad A285, AMD Ryzen Pro 2500U, 8GB RAM
i915: ThinkPad T480, Intel Core i5-8350U (4 cores, 8 threads), Intel UHD Graphics 620, 24GB RAM4
nvidia: Intel Core i7-4770S (4 cores, 8 threads; though the iGPU in it is dead, don't worry about it), Nvidia GTX 970 (3.5GB VRAM), 16GB RAM
I was considering using some other machines in this (three, to be exact; a Raspberry Pi 5 (vc4 driver), an older "gaming" laptop with a GTX 1060 (internal output wired up to iGPU, external to dedicated), and a Sandy Bridge Intel laptop to have another data point for i915), however those were scrapped by the time I realized that the original incarnation of this experiment would have created nearly 200 individual video samples to go through, at which point I decided to cut out those machines (and also some test cases for Xorg I realized that I was actually planning to test Xorg more than Wayland).
The software setup for this is described here, though please note that I have uploaded this mostly "as-is" and some parts of the process which I did do but never actually wrote down (building Xorg from source and having the packages stored away so that they can be hotswapped in when needed), mostly because they were added in on the fly and also happened right before I found out that none of this would actually work out in the end.
I planned to test KWin Wayland, GNOME Wayland, Sway, Wayfire (is also wlroots-based but they're doing something different, though it still sucks at this) and Hyprland, and with and without HW cursors and atomic KMS. And, of course, I had to test Xorg itself as well, to have a reference point to compare Wayland stuff against.
And then, I tried to actually test it. Initially, it went exactly as I had assumed: I started with the A285 because, well I don't actually know why, really, but I did, and got Wayfire, Hyprland and KWin all tested (on that machine, not on the others) on the first day. But then... I decided to take a quick recording of Xorg just to see how it would fare, and it was horrifying. I kept counting the same amount of frames between LED fire and first cursor movement (5, maybe 6 sometimes) in footage for both Xorg and Wayland, at which point I basically decided "yeah, I'll just ship this without the hard numbers that I initially wanted".
I then proceeded to make a post about it5, and I did get some good responses, like using a photoresistor on the Pico and doing all the stuff within the constraints of the microcontroller itself, however, by that point, I had already given up on proceeding with testing this. While it might seem like I had done barely anything, by that point... I was just tired, and had been dealing with this for months on end with no obvious solution other than to report it everywhere and hope that at least one project fixes it on their end, if that's even possible. The "hard numbers" part was always merely an "optional extra" for this, and since I wasn't really willing to put in any more mental investment into this, that's where I left off in regards to proper testing.
I do indeed plan on coming back to this sometime in the future, maybe to check if this has (or hasn't) improved any, but I'm not exactly sure when that's going to happen.
To be honest... I don't know. I'm not really a developer of any kind (for now...), and I don't code in any of the languages that the more commonplace compositors are written in, so I barely know what's going on in any of this, I just know that it sucks to use and that something is wrong, somewhere, and that barely anybody cares about it despite it making daily-driving a Wayland session a complete non-starter for me. There's also a bit of desperation on my side in wanting to do anything about this in the first place, because I've had way too many issues with Xorg, the other option, and every time I've run into one of them (usually video playback related stuff, like this), I tried to get Wayland to work out for me, but then I realized how awful using any sane (i.e. not a trackpoint, which isn't insane, just... laggy enough unto itself that you just don't notice it there) pointing device felt and immediately ran back to Xorg. Every single goddamn time. Kinda like how I've run into many issues with Linux as a whole, contemplated about returning to Windows because of them, then actually tried Windows as an actual daily driver OS for the first time in a while and noped out immediately, also every single time it happened.
In all seriousness, a lot of this might be caused by the aforementioned atomic KMS, however [update this part if this turns out to be wrong] there's still a substantial amount of latency (compared to X11 on the same hardware, not overall, because at that point there's actual "real world" issues that you're running into) even with it disabled, which makes me think that this is an issue of either all the Wayland compositor devs just so happening to be following the same weird, fucky advice in regards to how this should be done, or that it's some kernel/DRM/whatever nonsense that makes it happen on Wayland but not on X11 for some completely bespoke reason, even though Xorg goes over most of the same APIs as Wayland does these days anyway. However, given that, as I've said already, I'm not really a developer and have no idea what the hell any of this stuff actually is, I can't really be the judge here.
I plan on reporting this stuff to all (or most) relevant compositor projects involved (so KWin, Mutter, wlroots and Hyprland/aquamarine), however this is mostly as a way to get "people who should know better" to point me to another place to report this stuff (e.g. the individual DRM drivers on freedesktop gitlab) if so required. In case that this turns out to be something that does have to be resolved by each compositor on their own, well that's the end of my involvement, really. Again, all I can really do is, well, say that it's an issue (so, basically, that it isn't just FUD spread by the anti-Wayland lobby) that exists and make a very small fraction of the internet know about it, all the actual dev stuff will need to be done by "not me". It's sad, but that's just the way it is.
In case anybody feels like getting better evidence of this happening on their own hardware after having seen my pathetic attempt at doing so, and actually have the will to do this, feel free to do so and link to it here, however I am not at all expecting any of you to actually do this, as it's quite a lot of effort (the more machines are involved, the more shots you need to take, and the more Arch installs you have to do, and then some), so don't take this as me pressuring you to go out and do so. It would be very much appreciated, though.
Because I can, for *some* reason, actually feel the latency (I managed to daily drive KDE Wayland for a while on a different device and didn't notice it at all but then got my T480 and tried all the compositors that exist, almost one by one, and they all felt horrible compared to Xorg), and consider it to be a deal breaker for Wayland as a whole. Also, nobody else seems to care about it (I mean, some people clearly do, but pretty much none of the devs who matter here don't), and it doesn't look like anybody would start caring about it all of a sudden and start doing something about it, so here I am.
I really did think in the beginning that maybe somebody has resolved this already, that it's just an Intel issue (which it definitely isn't, as I now know), but... no. Nothing.
Xorg is still better in this single, critical regard (and also network transparency but there's solutions for that, I think, and also X11 isn't ever actually going to go away entirely; it'll just be used as Xwayland or something else possibly), and worse in everything else.
I gave up because, to be honest, I had wasted an insane amount of time, resources, and, yes, money (well, not that much of it, but a few purchases related to this were indeed made, most notably, the A285 I mentioned) on this (my testing attempt only covers about ~15% of overall things I did in relation to this), and, really, it didn't make that much sense to continue. As I've already said, getting actual stats was merely optional (but definitely beneficial) for the goal I had (have), since they wouldn't necessarily indicate anything of value other than that... it's a real problem, which was clear enough already.
I might actually end up setting up something like what's described here, which should have been my plan from the beginning, and which (as proven by the fact that they got actual numbers out of it) is known to work, however I'd like to measure the reactions to this before proceeding any further.
So, yeah. ~60% chance actual data is coming, though it might take a while, as I have other stuff that I had to put on hold because of this. Shouldn't take long to set up the Pico and the sensor, though.
That's the thing. I don't. Or, at least, I wish I didn't have to look like I am against Wayland. It's more so that I don't really like Xorg anymore (at least not as a daily driver desktop) and would like to use Wayland because it is "at least 99% better™", however... the cursor lag. It just drives me insane.
Actually, I wouldn't have any problem with Xorg if it did one thing right: video playback. Wayland (read: all the compositors, besides GNOME because GNOME is weird) does it just fine, but on Xorg, it's weird, there's frame drops all over the place, it's especially not great on NVIDIA and, really... I'm not surprised this is how it fares here. X11 was never really meant for this kind of use case (but we forced it to do it anyway), and really I don't care anymore, except...
...there's NO REASON the machines I have (at least the ones I actually want to use as an actual desktop/laptop) should fail this badly at this task. Take, for example, that post I linked where I couldn't get a 1060M to play video smoothly under XFCE (so Xorg). There's no reason for a 1060 to fuck up this badly at this task. And, for what it's worth, the iGPU in the machine (hooked up to the internal panel but I'm going to be using the external output only and that one's connected to the dGPU) does this a lot better. It's even tolerable in Firefox, which doesn't sound like much, but trust me, that means something (to me, anyway).
So, really, I'm severely dissatisfied with both display servers and would like at least one of them (preferably Wayland though because it's what everybody is planning on switching to anyway, or has switched to already) to become at least somewhat better. X11 is fine for now because I really care about mouse movement not being painful (would rather have good mouse movement but bad video playback than good video playback but awful mouse movement; though in reality I want both to be good), and pretty much everything I use6 also supports Wayland just fine, so in case the situation with cursor rendering there gets better, I should be able to switch just fine... should...
That's the thing, I don't know. I barely know what the issue itself is, and I have pretty much no hope of resolving it myself, so reporting it it is. If I get told to go somewhere else, I will. If it turns out that I did the right thing, well it's pretty much "just wait and see" for me from that point onwards.
nothing to see here yet, hopefully that'll change soon
Let me make this clear: this should not be an issue in the present day. Until at least 75% of reasonably mainstream enough Wayland compositors get this right, I do not care about any of the "progress" that Wayland is "making", because it is clearly incapable of getting absolutely critical things like this going. I do not care that some people simply do not care (nor want to care) about this; this is a bad look for Wayland as a whole, and I am tired of it.
Instead of trying to create an actually properly functioning alternative to X11, which, to be clear, is ancient and should not be used for daily driver desktop setups, the folks doing all of this have jumped from "okay, we have an interactive rectangle with text and images inside of it being drawn onto a screen" to "Pipewire! DRM leasing so VR headsets can work! Vector cursor themes! Everything and the kitchen sink, and them some!".
I would have thought that human interation issues like this (to be fair, yes, it's kinda hard to notice if you're "normal", but still) would have a higher priority than fucking VR and an audio/video server that is genuinely superior to the previous solutions but falls flat in many cases in spite of this (that pipewire thing might actually be my next target after I get this done) for them, but apparently not.
And, yet, a substantial part of the entire Linux community seems to think that every Wayland issue which isn't Nvidia or GNOME related has been solved eons ago already. This is NOT true, as demonstrated by this post (and all those desperate posts I've put up online over the last few months), not to mention any of the other Wayland "rough spots" that still exist.
Yes, "good enough" is the enemy of "perfect", but this should not be considered "good enough" under any circumstances. Unless... you happen to have hardware which hides this enough from you that you can simply pretend that this isn't an issue, which unfortunately seems to be the case for many of the Linux devs around the globe. Yes, many of them don't have such machines, but... do I care? Has this issue been solved already? No. Is there any indication that this is ever going to be solved? Also no, except for wishing that "it just will be fixed itself".
I do indeed realize that many people simply do not care, nor wish to care about cursor latency (I've said as much multiple times here alone), nor have many even thought about such a thing being a problem, and that I am indeed at least somewhat unique in being able to notice this (both among Linux users, but especially amongst your "normie" desktop users), let alone in making such a mess about it.
However... is it really too much of an ask to have a responsive, hardware-accelerated (yes, I know, Nvidia drivers and all that), and smooth-feeling mouse cursor, on not particularly ancient hardware, in the year of our lord 2025 mind you, especially when an even more ancient alternative (Xorg) has had this going properly since forever ago for quite some time (X11 had its dark ages too, I just wasn't there to see them)? Come on already, give me a break now.
And... that's it. Wayland cursor lag is real, not imaginary, and the Linux community at large should at least be marginally aware of it being real before declaring "Wayland is ready today, just switch to it already" and ripping Xorg out of everybody's hands all at once because "it's ancient and insecure and shouldn't be used anymore". Technically, that part shouldn't be in quotes, because it's entirely true (though, it's not as bad as some people claim it is; you're not going to get hacked by a state-sponsored hacking group and have ransomware installed on your machine and therefore lose all your data by merely having Xorg running on your computer7), however... Wayland isn't perfect, ok? Just be aware of that, because some folks clearly don't seem to be.
So sorry for this rant, I just can't deal with this myself anymore.
Footnotes
-
Like, for example, finally getting my home server going and having backups going again after being... weird for the past half a year. ↩
-
The (relatively crude) code for this is here, if you're wondering. Requires CircuitPython instead of MicroPython because the former has a USB HID implementation. ↩
-
Actually, it's borrowed, not mine. My own phone is even worse at this. ↩
-
I don't actually need 24 GB of RAM in my T480 (even 16 is overkill for me, technically); I ended up with that for... reasons (got a thing handed down to me and the RAM was kinda sorta part of that, it's weird), so... ↩
-
Here's one of the Wayland clips, and this is one of the Xorg ones (taken with Xorg
masterbranch). Not giving you any more than that. ↩ -
Except for
unclutterandxclickerbut there are alternatives, for that first one they're compositor specific ones at that but they do exist. ↩ -
Yes, that's way exaggerated, and nobody (as far as I'm aware) is claiming that, however I put that there for comedic effect only, and tbh I would not be surprised if somebody actually started claiming this for real. ↩
Most people do care about cursor latency, even if not knowingly, and developers very much do as well. When I implemented this, which reduced cursor latency by the most part of a frame on most systems, many people commented on how their system felt faster afterwards. Gnome has since implemented something similar (which doesn't prevent stutter like KWin does, but does reduce latency to a similar degree).
That you're not getting actionable results is thus not surprising - if a difference of a few ms is noticeable, a measurement resolution of 11ms isn't enough. To measure this kind of latency, you'd need to do a lot of measurements and average them out, which is quite a lot of effort. Effort that would not be well spent, mind you, because this is not the kind of difference between usable and "feels like shit".
Almost certainly the difference you feel comes from the side you completely ignored - input. Are you using the synaptics driver on Xorg, or libinput? If libinput, are you using the same settings? Do you have display scaling, which changes cursor speed on Wayland?