Developer Jakub Okoński measured click-to-photon latency between Windows 11 and KDE Plasma 6 using a Teensy microcontroller, then wrote KWin patches that recover roughly 1.1 to 1.2 milliseconds in the best case. The gains land hardest in windowed games, and they arrive just after the cutoff for Plasma 6.7.
Open-source developer Jakub Okoński has spent recent weeks doing something most latency complaints never get: measuring the problem with hardware instead of feel. Using a Teensy microcontroller wired up to act as a USB HID mouse and paired with a light sensor pointed at the monitor, he captured click-to-photon latency on both Windows 11 and Linux running KDE Plasma 6. The result is a set of patches for KDE's KWin Wayland compositor that aim to close part of the measurable gap between the two platforms.
Click-to-photon is the honest metric here. It counts the full path from the physical mouse button closing a circuit to the first photons of the resulting frame hitting the sensor. That window includes USB polling, input handling, compositor scheduling, GPU rendering, scanout, and the display's own pixel response. Software profilers can tell you when a frame was submitted, but only an external sensor tells you when the screen actually changed. By instrumenting both ends, Okoński removed the guesswork and confirmed what many Linux gamers had reported anecdotally: Windows 11 was delivering lower display latency under comparable conditions.
What the patches actually change
The improvements are not uniform across every gaming scenario, and Okoński is careful about that. His own breakdown sorts the outcomes by presentation mode.
Windowed games and applications see the largest benefit. These run through the full compositing path, where KWin has the most scheduling overhead to trim, so the patches should produce what he calls a substantial reduction. V-Sync fullscreen games that qualify for direct scanout, where the compositor hands a single buffer straight to the display controller and steps out of the way, pick up roughly a millisecond. Games using variable refresh rate (VRR), or fullscreen titles where tearing is permitted, generally see no reduction as long as the frame rate stays at or below the display's refresh rate. In those cases the frame is already being shown about as early as the hardware allows.
The headline figure is about 1.1 to 1.2 milliseconds recovered in the minimums. For context, Okoński measured the platform gap in best-case VRR conditions at somewhere around 4 milliseconds. So this work narrows a meaningful slice of the difference without erasing it. A millisecond sounds trivial until you frame it against a 240 Hz monitor, where a single refresh interval is only about 4.2 milliseconds. At that point, one millisecond is roughly a quarter of a frame, and competitive players chase smaller margins than that.
Why the compositor sits in the critical path
The reason a desktop compositor affects gaming latency at all comes down to how Wayland presents frames. Unlike the older X11 model, a Wayland compositor is authoritative over what reaches the screen. Every buffer a game produces is handed to the compositor, which decides when to present it relative to the display's refresh cycle. That gatekeeping is what makes Wayland tear-free and visually clean, but it also inserts the compositor's scheduling decisions directly into the input-to-display loop.
The optimization target is the gap between when the compositor wakes up to build a frame and the actual vertical blanking interval when the display latches new content. Wake up too early and you process stale input, adding latency. Wake up too late and you miss the deadline entirely and drop a frame. Direct scanout is the escape hatch: when a fullscreen game's buffer can be sent untouched to the display hardware, KWin removes itself from the per-frame work and the latency falls toward what Windows achieves with its own fullscreen flip path. The patches refine this timing so the compositor commits closer to the deadline without overshooting it.
Timing and what comes next
The patches have not yet been submitted upstream. Okoński plans to send them to KWin in the coming weeks, which means they miss the imminent Plasma 6.7 release and will instead target a later cycle. That is a frustrating bit of calendar math for users who would feel the difference now, but compositor changes touching presentation timing warrant review rather than a rushed merge. He has also flagged several other areas he is still investigating for a lower-latency Plasma Wayland gaming experience, so this looks like the start of a longer effort rather than a one-off fix.
The broader significance is that Linux gaming latency is finally being treated as an engineering problem with reproducible measurements rather than a matter of subjective impression. Hardware-instrumented click-to-photon testing gives KWin developers a number to optimize against and a way to prove regressions or gains. As Valve's Steam Deck and the wider Proton ecosystem keep pulling more players onto Linux, this kind of low-level latency work is what separates a usable gaming desktop from a competitive one.
Readers who want the full methodology and the underlying data can follow Okoński's blog post documenting the latency investigation and the path toward closing the gap with Windows.
Comments
Please log in or register to join the discussion