[PATCH 09/11] modesetting: Implement PRIME syncing as a sink

[Alex Goins]

Thanks for taking a look Michel!

> Always scheduling an event for the next vblank means that the vblank
> interrupt can never be disabled, right? Might be better to trigger the
> next update when getting new damage if there's currently none.

Yeah, I think so. I had to work around that for DPMS by disabling flipping with
DPMS off and re-enabling it with DPMS on.

Triggering the next update when getting new damage is certainly doable. However,
there would have be some way to tell the sink to flip when the update is
finished.

Since presenting is asynchronous, I currently do this by attaching a fence to
the buffer prior to presenting, and signaling it after. The sink immediately
attempts a flip after master->PresentTrackedFlippingPixmap() returns TRUE, but
for drivers that support it, the flip is blocked (hopefully asynchronously) by
the fence. I currently have pending patches adding fencing support to i915's
flipping paths.

This method could theoretically be extended, attaching the fence even when there
isn't damage, and signaling it after presenting in response to damage. In
practice, however, I think this could cause problems.

While drmModePageFlip() is asynchronous and returns immediately, I've seen
drivers wait on page flips as part of other, synchronous, DRM calls. If we're
waiting on damage events in X to ultimately signal, this could cause a deadlock
in the kernel.

Moreover, problems would arise for drivers that do not support fencing page
flips. As it stands, it isn't that big of an issue because presenting almost
always finishes before the page flip. However, if we needed to wait for a longer
period of time, those drivers would end up flipping to a stale buffer.

Of course, I could just always present regardless of damage, but needless to say
that's not ideal. The most universal solution I think would be to add another
sink ABI function for the source to use to trigger a flip after a deferred
present.

> In the !noflip case (BTW, double negatives are kind of bad), silently
> falling back from drmModePageFlip failure to drmWaitVBlank could result
> in a frozen display with no indication what's wrong, couldn't it?

Yeah, if something happens to cause it to fall back every time that would
happen. I guess my hope in falling back is that the flip would succeed next time
around. There should probably at least be a warning.

As far as the double negative goes, no problem changing it. My logic in having
the argument phrased as a negative was that the non-flipping path is kind of a
special case. I should probably come up with a more accurate naming for
SharedPixmapFlip(), considering it doesn't always flip in this version.

Thanks,
Alex