On 2020-07-29 9:23 a.m., Kulkarni, Vandita wrote: > > On async flips, there needs to be some clarity/guideline on the behaviour and > event expectation from the > driver by user space. > Here are few assumptions that we have, > 1. Our understanding is that the user space doesn’t expect the timestamp for > async flips (but still expects vblank timestamp) , or > doesn’t do anything with that, same is the assumption wrt the flip sequence, > please correct us if we are wrong. > 2. In the sequence the user space still expects the counter that marks > vblanks. > 3. The user space can use different event types like DRM_EVENT_VBLANK or > DRM_EVENT_FLIP_COMPLETE > for getting the corresponding event. And their designs are still aligned to > this even in case of async. > > If there are any more expectations from the user space wrt to the event that > is being sent from the > driver in case of async flip, please let us know. > > If the user space doesn’t care much about the flip sequence then, we can just > not do anything like returning > the flip counter like this version is doing and just stick to returning of > the frame counter value(which marks vblanks).
There's no such thing as a "flip sequence" in the KMS API. There's only the per-CRTC vblank counter. Each flip completion event needs to contain the value of that counter when the hardware completed the flip, regardless of whether it was an async flip or not. As for the timestamp in the event, I'm not sure what the expectations are for async flips, but I suspect it may not really matter. E.g. the timestamp calculated to correspond to the end of the previous vertical blank period might be fine. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
