First of all, why would you want the game to interact with your display server what so ever (aside from alt+tab)? This is why full screen exists. >[In VRR] Whe

First of all, why would you want the game to interact with your display server what so ever (aside from alt+tab)? This is why full screen exists. >[In VRR] Whenever an application is slower than the displays maximum refresh rate the display will wait for the next frame before it updates the pixels and thus you don’t see any stutter Nothing so simple. VRR means your framerate fluctuates, which means you have stutter, by definition. Perhaps if you can bound it within a sufficiently small range that it wont be perceptible. If game framerates _did_ have predictably small variance, everyone would just generate the new frame right before VBI and have perfect (practically) latency free, no tear, no stutter, no motion blur (via BFI/CRT) rendering. >Not all displays have this functionality (yet) because it’s difficult to make it work well: In many displays with different refresh rates the brightness changes a lot, so if the refresh rate jumps around you’ll see the display constantly flicker in brightness. The brightness only changes if you are using Black Frame Insertion (on old monitors you can't use VRR at the same time as BFI; on newer ones this is supposedely fixed, i have no idea how or if it's valid). One big issue though is that VRR makes liquid crystal transitions even harder than it already is to happen fast and artifact-free. These measurements are bad for various reasons. There's also the obvious question: how does Wayland actually change the framebuffer? Direct scanout is a term I've never heard that could mean many things... I guess you get control over scanout, so you could render during VBI and have zero latency in this part of the loop, in which case why even measure it.