[PATCH v5 01/13] xf86: Add PRIME flipping functions to Screen

Alex Goins agoins at nvidia.com
Fri Apr 29 18:27:14 UTC 2016


The reference implementation in modesetting doesn't use it, but our driver uses
it so that we can be aware of the outputs available on the CRTC.

This allows users to set __GL_SYNC_TO_VBLANK=<slave output name> so that OpenGL
applications can sync to the slave's vblank in the same fashion that they do for
native heads in our driver.

Thanks,
Alex

On Fri, 29 Apr 2016, Dave Airlie wrote:

> On 13 April 2016 at 14:17, Alex Goins <agoins at nvidia.com> wrote:
> > Adds typedefs for (*RRStartFlippingPixmapTrackingProcPtr),
> > (*RREnableSharedPixmapFlippingProcPtr),
> > and (*RRDisableSharedPixmapFlippingProcPtr) in randrstr.h.
> >
> > Adds typedefs for (*PresentSharedPixmapProcPtr),
> > (*SharedPixmapNotifyDamageProcPtr),
> > (*RequestSharedPixmapNotifyDamageProcPtr), and
> > (*StopFlippingPixmapTrackingProcPtr) in scrnintstr.h.
> >
> > Adds RR(Enable/Disable)SharedPixmapFlipping, and
> > RRStartFlippingPixmapTracking to rrScrnPrivRec.
> >
> > Adds StopFlippingPixmapTracking, PresentSharedPixmap,
> > SharedPixmapNotifyDamage, and RequestSharedPixmapNotifyDamage to ScreenRec.
> >
> > rrScrnPrivRec used for functions that use RandR-private data types, and
> > ScreenRec used for the rest.
> >
> > RREnableSharedPixmapFlipping will allow the sink driver to setup for
> > flipping between two shared pixmaps.
> >
> > RRDisableSharedPixmapFlipping will allow the sink driver to do teardown
> > associated with flipping between two shared pixmaps.
> >
> > (RRStart/Stop)FlippingPixmapTracking are merely the double-buffered
> > equivalents of (Start/Stop)PixmapTracking, allowing the source driver to do
> > whatever setup and teardown necessary for presenting on the two shared
> > pixmaps.
> 
> Why does Start take a crtc? I can't see it being used here, do you need it
> for some reason in some other case, I think it should be migrated to Screen
> it it doesn't need the crtc. It would also be more symmetrical.
> 
> Dave.
> 


More information about the xorg-devel mailing list