[PATCH v3 0/9] PRIME Synchronization

Alex Goins agoins at nvidia.com
Wed Feb 3 05:22:41 CET 2016


Hello all,

These patches change the xserver to support setting up PRIME with double
buffering, and implement double buffered PRIME sink support in the
modesetting driver. In addition to these changes, I've upstreamed a couple
of patches to the i915 DRM driver that mesh with these, and have
implemented double buffered PRIME source support in the NVIDIA proprietary
driver (pending release.)

Previous cover letters:
    v2: http://lists.x.org/archives/xorg-devel/2016-January/048434.html
    v1: http://lists.x.org/archives/xorg-devel/2015-November/048039.html

In this patch set there are a few changes:
    1) Moved some of the ABI functions into rrScrPrivRec instead of
       ScreenRec.
       
       In the case of (rr)StartFlippingPixmapTracking(), it was
       because I needed to add the RRCrtc as a parameter so that the source
       driver can be aware of the outputs being used.

       In the case of (rr)(Enable/Disable)SharedPixmapFlipping(), I was
       previously passing in the xf86CrtcPtr as a void*, which is kind of
       gross. It makes more sense to pass in the RRCrtcPtr and get the
       xf86CrtcPtr from there, necessitating an rrScrPrivRec ABI function.

       It may be best to move all of the ABI functions to rrScrPrivRec
       regardless of whether or not they need to use RandR-specific data
       types, since none of them make sense without RandR enabled. However,
       since the old pixmap sharing functions are in ScreenRec, I left
       functions there where possible. If you would prefer them in
       rrScrPrivRec, just let me know.

    2) Made damage get flushed to the kernel driver for both scanout
       pixmaps, rather than just the latest one to get damage registered.

    3) Added comments to the output property code indicating that it will
       need to be reworked if an when we support different source providers
       for different outputs.

    4) Made RandR check the current value of the output property if there
       is no pending value. Previously, it failed to correctly pick up on
       the default value, although it didn't cause a visible bug since with
       no value it defaults to TRUE.

    5) Made RandR set the output property to 0 if it has to fall back to
       unsynchronized PRIME, so that if the user checks the value it will
       reflect the current state of the system.

    6) Made RandR fall back on unsynchronized pixmap sharing if the PRIME
       flipping functions fail.

    7) Blacklisted UDL for PRIME synchronization in the modesetting driver,
       making it fail rrEnableSharedPixmapFlapping() so that RandR falls
       back on unsynchronized PRIME. UDL has several issues that prevent it
       from working properly with PRIME synchronization.

       See commit message for "modesetting: Blacklist UDL from PRIME sync"
       for details.

Thanks, Alex @ NVIDIA Linux Driver Team

Alex Goins (9):
  xf86: Add PRIME flipping functions to Screen
  randr/xf86: Add PRIME Synchronization / Double Buffer
  randr: Add ability to turn PRIME sync off
  randr: Cleanup rrSetupPixmapSharing()
  modesetting: Properly clean up w/ PRIME syncing
  modesetting: Implement PRIME syncing as a sink
  modesetting: Fix mmap leak in scanout_pixmap_cpu
  modesetting: Suspend and resume flipping with DPMS
  modesetting: Blacklist UDL from PRIME sync

 hw/xfree86/drivers/modesetting/driver.c          |  96 ++++++--
 hw/xfree86/drivers/modesetting/drmmode_display.c | 282 +++++++++++++++++++++--
 hw/xfree86/drivers/modesetting/drmmode_display.h |  17 +-
 hw/xfree86/modes/xf86Crtc.h                      |   4 +
 hw/xfree86/modes/xf86RandR12.c                   |   4 +-
 include/scrnintstr.h                             |  14 ++
 randr/randrstr.h                                 |  17 ++
 randr/rrcrtc.c                                   | 158 +++++++++++--
 randr/rrprovider.c                               |  57 +++++
 9 files changed, 599 insertions(+), 50 deletions(-)

-- 
1.9.1



More information about the xorg-devel mailing list