On Tuesday, August 30th, 2022 at 10:31, Michel Dänzer <michel.daenzer@xxxxxxxxxxx> wrote: > > For the atomic uAPI, we need to pick on of these two approaches: > > > > 1. Let the kernel fall back to a sync flip if async isn't possible. This > > simplifies user-space, but then user-space has no reliable way to figure out > > what really happened (sync or async?). That could be fixed with a new > > read-only CRTC prop indicating whether the last flip was async or not. > > However, maybe someone will come up in the future with user-space which > > needs to only apply an update if async flip is possible, in which case this > > approach falls short. > > The future is now. :) > > As I described in the documentation patch discussion, this approach would > make it tricky for a Wayland compositor to decide if it should use an async > commit (which needs to be done ASAP to serve the intended purpose) or not (in > which case the compositor may want to delay the commit as long as possible > for minimal latency). Ah right. If an async page-flip is not possible, then a Wayland compositor could want to wait the "last moment" before the next vblank to see if a more up-to-date buffer is available. With that + Xorg usage, I think we have a rather solid case for failing async flips rather than silently falling back to vsync.
