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…
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…