Hello, After some discussions I had with some people I would like to discuss some design choices regarding uAPI to expose async updates.
The plan is to allow userspace to update the cursor plane through the atomic API instead of the legacy cursor API. The steps I was following were: 1) Make the legacy cursor implementation use async updates path/helpers; and this should work as before 2) Expose a way for userspace to trigger an async updates for any plane (adding proper tests to igt) Assuming that async here means: update the hw immediately. But for this to happen, the idea of legacy cursor API and async update should be similar, and my question is: are they? The question that was raised was: When we perform 100 legacy cursor updates to the kernel between 2 v-blanks, how many times does the screen update cursor? (a) 1 - at vblank (b) 100 (c) depends on the hw and driver I would say (b), is that correct? If it's (b), then async updates should allow the same. (NOTE: Actually not really with the current implementation, if there is a sync pending commit, then async update blocks, which makes the name confusing). Also, if async is not possible, in the current implementation we fall back to a sync update. But this is not that interesting for userspace, for example, if drmModeSetCursor succeeds, xorg will call that every single time it gets an input event, but if it fails, there are no expectations that cursor moves are async and xorg handles cursor updates it self (using the primary plane for instance). So another question here is: should we have another flag to say that async update should fail instead of falling back to a sync update ? Another point is, if we perform an async update while there is still a pending commit, It seems to me that instead of falling back to a sync update, it would be better for the userspace if we could amend the pending commit, what do you think? And I just want to clarify (just because this wans't clear to me before and might not be clear to others) that async update (programming the hw immediately) can cause tearing if the hw reads the configuration dynamically during a scanout. Thanks Helen _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel