[PATCH 04/11] xf86: Add PRIME flipping functions to ScreenRec

[Alex Goins]

> > Yeah, there's no open source implementation of these right now, but essentially
> > they just allow the source driver to do whatever specific setup necessary to
> > present to either of the two supplied shared buffers from the same headsurface,
> > as well as having presentation driven by PresentTrackedFlippingPixmap() as
> > opposed to some sort of internal mechanism.
> 
> Not sure adding an API without showing how it's supposed to be
> implemented is going to fly.

I suppose I could make an open source implementation, but that will take more
time.

> > It would probably be possible to implement (Start/Stop)PixmapTracking such that
> > multiple calls on the same mscreenpix with different shared pixmaps achieves
> > that behavior, but it would be less explicit and would probably result in some
> > unnecessary setup/teardown when switching to externally driven presentation on
> > the second call.
> > 
> > As of right now, I would expect multiple calls to StartPixmapTracking() with the
> > same mscreenpix but different shared pixmaps to result in two independently
> > driven shared pixmaps presenting from the same mscreenpix. I've been trying to
> > avoid tampering with the semantics of the old paths as much as possible.
> 
> AFAICT presentation is entirely driven by the drivers, so it's not
> obvious to me why it couldn't work with the existing
> StartStopPixmapTracking API.
> 
> One thing that might be nice, to avoid the master driver unnecessarily
> updating a shared pixmap from the screen pixmap, would be a hook for the
> slave driver to ask the master driver to update a shared pixmap. As you
> mentioned in another post before, the slave driver could hook into the
> master screen pixmap damage directly for triggering presentation. Then
> the control flow could be:
> 
> Drawing to screen pixmap
>  -> damage triggers slave driver to start presentation
>   -> slave driver asks master driver to update shared pixmap
>    -> slave driver submits flip from shared pixmap

This is what I mean. Right now presentation (and by that I mean updating the
shared pixmap) is entirely driven by the drivers. The patches here do exactly
what you say, adding master->PresentTrackedFlippingPixmap() (name can change of
course) which is a call that allows the slave to request that the master update
a shared pixmap. Afterwards, the slave flips to that pixmap. The only difference
is that it isn't triggered by damage, but instead tries on each vblank.

Switching between presentation driven entirely by the master to presentation
driven by the sink in the double-buffered case is where the hangup comes up, for
the most part. On the first call we would expect the master to start presenting
on its own accord, and after the second call we would expect presentation to be
driven by the sink, which is different than today's behavior with two calls to
StartPixmapTracking(). I can make it work, just something to consider.

While it's technically possible for the sink driver to listen for damage on
mscreenpix, I noticed while prototyping it that the definition of
DamageRegister() with DAMAGE_VALIDATE_ENABLE indicates that damage shouldn't be
registered with mismatched screens. Not sure how hard of a requirement that is,
but it scared me away from that approach. Please correct me if I'm wrong.

What I'm looking into now is adding an additional hook for the master driver to
request the slave driver to flip to a shared pixmap. This way, the master driver
has complete discretion over when it is ready for the slave to flip. If there
isn't damage, the master driver can wait until there is damage to present and
request the flip. If there is damage, it can do it right away. Then, the slave
doesn't need to make assumptions about the behavior of
master->PresentTrackedFlippingPixmap(), whether or not it is synchronous or
supports fencing DMA-BUFs.

Drawing to screen pixmap
    1) Slave driver starts presentation
    2) Slave driver asks master driver to update shared pixmap
    3) Master driver asks slave driver to flip to updated shared pixmap
    	- Note: Doesn't have to happen immediately
    4) Slave driver gets page-flip event, goto 1

By having presentation ultimately bottlenecked by page-flip events, we ensure
that presentation conforms to the sink's refresh rate.

Thanks,
Alex