[Xf86-video-armsoc] Understanding n-buffering support and the swap chain

[Daniel Drake]

Hi,

I'm trying to understand this commit:

http://cgit.freedesktop.org/xorg/driver/xf86-video-armsoc/commit/?id=1d13da045ced12a123db184fff677b0de41d80e6

I think I understand the basic concept: accept multiple SwapBuffers
requests, both for the next vblank and the ones that come after. But
the implementation does not match my expectation.

For example, I would expect to see queueing logic in
ARMSOCDRI2ScheduleSwap along the lines of:
  check if I'm already doing a swap, if so, just queue this request and return
and similarly in the SwapComplete handler, logic along the lines of:
  check if there are more pending flips in the swap chain, if so, go
ahead and execute the next one now

Instead, the implementation seems to go straight through and call
drmmode_page_flip() right away, in all cases, even if another
(uncompleted) swap was requested a moment ago.

Is this written in the expectation that the underlying DRM driver will
implement some kind of queue mechanism where it receives multiple
requests? Flipping the first one on the upcoming vblank, the next one
on the following vblank, etc?

DRM isn't designed like that - you can only "queue" a single page flip
for the next immediate vblank. If you try to queue another page flip
before the vblank event arrives, the driver is supposed to return
-EBUSY - but it seems that common drivers instead silently discard the
first flip request and service the 2nd request upon the next vblank
interrupt. Either way, it's not a multi-entry queue that armsoc might
be expecting.

Thanks for any clarification
Daniel