Cursors uAPI vs async update - questions

[Helen Koike]

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