[PATCH xserver] xsync: Add resource inside of SyncCreate, export SyncCreate

adding the resource shouldn't otherwise be a problem due to the single-threaded nature of X. Signed-off-by: Alex Goins --- Xext/sync.c| 50 -- Xext/syncsdk.h | 4 miext/sync/misync.c| 27

Re: [V2] modesetting: code refactor for PRIME sync

nc with this patch before merging it, but I don't have any further objections. Reviewed-by: Alex Goins Thanks! Alex > Hi AlexG, > > What's about new patch? > > Thanks > JimQu > > > 在 2018/8/27 13:37, Jim Qu 写道: > > The X will be crashed on the system with

Re: [PATCH] modesetting: code refactor for PRIME sync

Inline On Fri, 24 Aug 2018, Jim Qu wrote: > The PRIME sync on modesetting assume that all two GPUs are used > modesetting driver on the hybrid system. The X will be crashed > on the system with other DDX driver, such as amdgpu. It only makes this assumption when the other DDX driver is the

Re: [PATCH xserver] randr: rrCheckPixmapBounding should only increase screen size

Hi Adam, Can this be merged? Thanks, Alex On Wed, 15 Aug 2018, Alex Goins wrote: > Thanks, Keith and Michel! > > Yes, I'll test and review the change, and help where necessary. Thanks for > pointing it out. > > -Alex > > On Wed, 15 Aug 2018, Michel Dänzer wrote: &g

Re: [V2] modesetting: Fix X crash in ms_dirty_update()

under PRIME(not reverse) > case? > > Thanks > > JimQu > > > On 2018年08月18日 02:55, Alex Goins wrote: > > I think this patch is along the right lines, but misses part of the fix. > Although I don't have access to a modesetting<->modesetting PRIME o

Re: [V2] modesetting: Fix X crash in ms_dirty_update()

I think this patch is along the right lines, but misses part of the fix. Although I don't have access to a modesetting<->modesetting PRIME output slaving setup to test this theory right now, I think this will break it. Have you tested that this path is exercised? It is true that

Re: [PATCH xserver] randr: rrCheckPixmapBounding should only increase screen size

Thanks, Keith and Michel! Yes, I'll test and review the change, and help where necessary. Thanks for pointing it out. -Alex On Wed, 15 Aug 2018, Michel Dänzer wrote: > On 2018-08-14 10:05 PM, Alex Goins wrote: > > The purpose of rrCheckPixmapBounding() is to make sure that the fb

[PATCH xserver] randr: rrCheckPixmapBounding should only increase screen size

that rrCheckPixmapBounding() will only resize the fb to be larger than it already is, preventing it from stepping on prior requests to increase the size of the fb. Signed-off-by: Alex Goins --- randr/rrcrtc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c index

Re: [PATCH xserver 1/2] randr: Fix rotation check in ProcRRSetScreenSize()

It sounds like this patch is the one we want. Can it be merged? Thanks, Alex On Wed, 10 Jan 2018, Michel Dänzer wrote: > On 2018-01-09 03:44 AM, Alex Goins wrote: > > ProcRRSetScreenSize() does bounds checking to ensure that none of the CRTCs > > have > > a viewport that e

Re: [PATCH xserver 2/2] randr: Use RRCrtcGetScanoutSize() in ProcRRSetScreenSize()

On Tue, 9 Jan 2018, Michel Dänzer wrote: > On 2018-01-09 03:44 AM, Alex Goins wrote: > > Previously, ProcRRSetScreenSize() manually computed the dimensions of a > > CRTC's > > viewport in order to check that it does not extend beyond the bounds of the > >

[PATCH xserver 2/2] randr: Use RRCrtcGetScanoutSize() in ProcRRSetScreenSize()

canoutSize() is used directly due to the transform having not yet been applied but the check is otherwise the same. Signed-off-by: Alex Goins <ago...@nvidia.com> --- randr/rrscreen.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/randr/rrscreen.c b/randr/rrscreen

[PATCH xserver 1/2] randr: Fix rotation check in ProcRRSetScreenSize()

is can cause valid uses of ProcRRSetScreenSize() to fail with BadMatch. This patch fixes the issue by testing that the bits RR_Rotate_90 or RR_Rotate_270 are set, rather than testing for equality. Signed-off-by: Alex Goins <ago...@nvidia.com> --- randr/rrscreen.c | 2 +- 1 file changed, 1 ins

Re: [RFC] DeepColor Visual Class Extension

> On Fri, 2017-11-03 at 21:04 -0700, Alex Goins wrote: > > > > > DPCCompositorChangeNotify > > > > > > > > requester: WINDOW window requesting notification > > > > output: OUTPUT output affected by change >

Re: [PATCH xserver 3/3] ramdac: Handle master and slave cursors independently

On Fri, 10 Nov 2017, Michel Dänzer wrote: > On 09/11/17 08:09 PM, Alex Goins wrote: > >> On 09/11/17 02:34 AM, Alex Goins wrote: > >>> On Wed, 8 Nov 2017, Michel Dänzer wrote: > > > >> I'm asking this to avoid ending up in a similar situation as with the &

Re: [PATCH xserver 3/3] ramdac: Handle master and slave cursors independently

> On 09/11/17 02:34 AM, Alex Goins wrote: > > On Wed, 8 Nov 2017, Michel Dänzer wrote: > I'm asking this to avoid ending up in a similar situation as with the > PRIME synchronization functionality, where it seems like the modesetting > driver still can't use it with

Re: [PATCH xserver 3/3] ramdac: Handle master and slave cursors independently

Thanks both for the quick feedback. Replies inline. On Wed, 8 Nov 2017, Hans de Goede wrote: > > https://lists.x.org/archives/xorg-devel/2016-September/050973.html implies > > that > > xf86CursorScreenPtr is part of the ABI. Mark xf86CursorPriv.h as such. > > I'm not sure if exporting this is a

[PATCH xserver 3/3] ramdac: Handle master and slave cursors independently

cursor code such that the slave aspects of these functions are tried first, falling back to the master if they fail. SlaveHWCursor, a flag for querying if the hardware cursor is being driven by slaves, is added to xf86CursorScreenRec, resulting in an ABI break. Signed-off-by: Alex Goins <

[PATCH xserver 1/3] ramdac: Fix formatting in xf86CheckHWCursor()

xf86CheckHWCursor() has spacing that is inconsistent with the rest of the file. Correct this in preparation for subsequent changes. Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/ramdac/xf86HWCurs.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --gi

[PATCH xserver 0/3] Allow PRIME output master "hardware" cursors

to xf86CursorScreenRec, resulting in an ABI break. Alex Goins (3): ramdac: Fix formatting in xf86CheckHWCursor() ramdac: Add xf86CursorPriv.h to ABI ramdac: Handle master and slave cursors independently hw/xfree86/ramdac/Makefile.am | 4 +- hw/xfree86/ramdac/xf86CursorPriv.h | 3 + hw/xfree86/ramdac

[PATCH xserver 2/3] ramdac: Add xf86CursorPriv.h to ABI

https://lists.x.org/archives/xorg-devel/2016-September/050973.html implies that xf86CursorScreenPtr is part of the ABI. Mark xf86CursorPriv.h as such. Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/ramdac/Makefile.am | 4 ++-- hw/xfree86/sdksyms.sh | 1 + 2 files chan

Re: [RFC] DeepColor Visual Class Extension

On Thu, 2 Nov 2017, Adam Jackson wrote: > On Thu, 2017-10-26 at 19:50 -0700, Alex Goins wrote: > > > DPCGetWindowDisplayCapabilities > > > > window: WINDOW > > => > > output: OUTPUT > > colorspace_list: LISTofCOLOR

Re: [PATCH xserver] xf86-video-modesetting: Fix ms_queue_vblank(flags = MS_QUEUE_RELATIVE)

Adding Keith, as this is a regression that completely breaks PRIME Sync configs at top of tree. Thanks, Alex On Fri, 20 Oct 2017, Alex Goins wrote: > Change 677c32bc refactored all usages of drmWaitVBlank() into a helper > function, > ms_queue_vblank(). > > ms_queue

Re: [RFC] DeepColor Visual Class Extension

06-06, +https://cgit.freedesktop.org/xorg/proto/presentproto/plain/presentproto.txt - DeepColor Extension Version X.X 2017-XX-XX Alex Goins

[PATCH xserver] ramdac: Check ScreenPriv != NULL in xf86ScreenSetCursor()

calls xf86SetCursor(NullCursor). If xf86ScreenSetCursor(NullCursor) returns FALSE, it calls xf86SetCursor(NullCursor) again and this repeats forever. Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/ramdac/xf86HWCurs.c | 9 - 1 file changed, 8 insertions(+), 1 deletio

[PATCH xserver] xf86-video-modesetting: Fix ms_queue_vblank(flags = MS_QUEUE_RELATIVE)

() passes in 1, which results in a large negative vblank offset. After subtracting, we're left with a relative sequence number of 100,000+, i.e. wait for 100,000+ vblanks... In the relative case we want to pass in the sequence number unmodified. Simply add a check to do this. Signed-off-by: Alex Goins

Re: [RFC] DeepColor Visual Class Extension

On Sun, 15 Oct 2017, Keith Packard wrote: > Alex Goins <ago...@nvidia.com> writes: > > > Thanks, Adam. > > > > Here's an updated version of the spec: > > This is looking very good. I don't have any architectural concerns at > this point, just some e

Re: [RFC] DeepColor Visual Class Extension

Thanks, Adam. Here's an updated version of the spec: DeepColor Extension Version X.X 2017-XX-XX Alex Goins ago...@nvidia.com

Re: [PATCH libpciaccess] linux: support 32 bit PCI domains

On Wed, 12 Jul 2017, Adam Jackson wrote: > On Wed, 2017-07-12 at 19:30 +0200, Mark Kettenis wrote: > > > Date: Tue, 11 Jul 2017 10:32:19 -0700 > > > From: Stephen Hemminger > > > > > > Yes, binary compatibility is a problem. Putting additional data at end > > > of

Re: [RFC] DeepColor Visual Class Extension

Version X.X 2017-XX-XX Alex Goins ago...@nvidia.com NVIDIA Corporation 1. Introduction The DeepColor Extension provides a new visual class, DeepColor, designed

Re: [RFC] DeepColor Visual Class Extension

Inline On Wed, 19 Jul 2017, Keith Packard wrote: > * PGP Signed by an unknown key > > Alex Goins <ago...@nvidia.com> writes: > > > 2. DeepColor Visual Class > > > > The DeepColor extension defines a new visual class, DeepColor. > > As Adam says

[RFC] DeepColor Visual Class Extension

methods for querying these properties. Supported colorspaces/encodings were chosen as a superset of those supported by the requisite EGL/Vulkan extensions, with GLX relying entirely on the X properties for the purpose of determining colorspace/encoding. Let us know what you think! Thanks, Alex Goins

Re: [RFC] Visual Class for On-Screen HDR Drawables

Pinging in case this got buried. Thanks, Alex On Wed, 1 Mar 2017, Alex Goins wrote: > Thanks Adam. Inline - > > On Fri, 10 Feb 2017, Adam Jackson wrote: > > > On Thu, 2017-02-09 at 19:06 -0800, Alex Goins wrote: > > > Any input? > > > > Inline be

Re: [RFC] Visual Class for On-Screen HDR Drawables

Thanks Adam. Inline - On Fri, 10 Feb 2017, Adam Jackson wrote: > On Thu, 2017-02-09 at 19:06 -0800, Alex Goins wrote: > > Any input? > > Inline below... > > > > Would it be a major problem for automatic redirection to destroy HDR? > > > Compositors

Re: [RFC] Visual Class for On-Screen HDR Drawables

Any input? Thanks, Alex On Wed, 25 Jan 2017, Alex Goins wrote: > >Either we define the interaction with Render, or automatic redirection > >(and backing store) don't work. But again we're painted into a bit of a > >corner: > > > >typedef struct { > >

Re: [RFC] Visual Class for On-Screen HDR Drawables

>Either we define the interaction with Render, or automatic redirection >(and backing store) don't work. But again we're painted into a bit of a >corner: > >typedef struct { >CARD16 red B16; >CARD16 redMask B16; >CARD16 green B16; >CARD16 greenMask B16; >

Re: [RFC] Visual Class for On-Screen HDR Drawables

> >> To allow for scRGB visuals, as well as others with arbitrarily large color > >> components, we'd like to propose a new visual class that is opaque to X > >> rendering, but allows for drawables with arbitrary attributes to be used > >> for > >> on-screen rendering and compositing via GLX.

Re: [RFC] Visual Class for On-Screen HDR Drawables

> > VoidColor is a visual class defined to have a static colormap of 0 > > elements.  It > > is incapable of receiving X rendering, but is compatible with any GLX > > drawable > > of the correct depth regardless of other attributes. The idea is that you > > could > > pass any GLX fbconfig to

[RFC] Visual Class for On-Screen HDR Drawables

. What do you think? Thanks, Alex Goins NVIDIA Linux Driver Team ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH v2] ramdac: Check sPriv != NULL in xf86CheckHWCursor()

xf86CheckHWCursor() would dereference sPriv without NULL checking it. If Option "SWCursor" is specified, sPriv == NULL. In this case we should assume that HW cursors are not supported. Signed-off-by: Alex Goins <ago...@nvidia.com> Reviewed-by: Andy Ritger <arit...@nvidia.c

[PATCH] ramdac: Check sPriv != NULL in xf86CheckHWCursor()

xf86CheckHWCursor() would dereference sPriv without NULL checking it. If Option "SWCursor" is specified, sPriv == NULL. In this case we should assume that HW cursors are not supported. Signed-off-by: Alex Goins <ago...@nvidia.com> Reviewed-by: Andy Ritger <arit...@nvidia.c

Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime

functional, especially for the first Xorg release that supports PRIME Synchronization. Thanks, Alex On Thu, 8 Sep 2016, Hans de Goede wrote: > Hi, > > On 08-09-16 01:32, Alex Goins wrote: > > Hi Hans, > > > > Thanks for this, it will definitely be a big improvement. &g

Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime

On Thu, 8 Sep 2016, Michel Dänzer wrote: > On 08/09/16 08:32 AM, Alex Goins wrote: > > > > I'm encountering some very strange issues when running these with PRIME > > Synchronization enabled, even after fixing our internal cursor handling. > > When > > moving t

Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime

Hi Hans, Thanks for this, it will definitely be a big improvement. I've been testing these patches against the NVIDIA driver. Some concerns - What would be the best way to query from the master if the slave is using a HW cursor? We typically composite the cursor onto the shared pixmap, and with

[PATCH] modesetting: NULL assignment for drmmode_set_target_scanout_target_cpu

Commit 80e64dae: "modesetting: Implement PRIME syncing as a sink" originally was supposed to have this line, but it was dropped as part of the merge process. Foregoing the NULL assignment causes a ton of problems with dereferencing uninitialized memory. Signed-off-by: Alex

Re: [PATCH v7 00/11] PRIME Synchronization

> The failed patches look okay, and are tested and working. I was mistaken; "modesetting: Implement PRIME syncing as a sink" is missing a '*target = NULL' line, which causes issues from dereferencing uninitialized memory after tearing down a scanout pixmap. I'm about to send out a patch to fix

Re: [PATCH v7 00/11] PRIME Synchronization

> Merged: > > remote: E: failed to find patch for rev > b601f96a5915a2c486b389483b291797e6fdf617. > remote: I: patch #80653 updated using rev > 1bdbc7e764ed7bf7c1ae46287dec368aa7c7e80d. > remote: E: failed to find patch for rev > f4c377953df1fe0e3196eda452acf0078e61. > remote: E: failed to

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

aps internally to EnableSharedPixmapFlipping(). Don't support flipping if ms->drmmode.pageflip == FALSE. Move flipping_active check to this commit v6: Rebase onto ToT v7: Unchanged Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 96 +

[PATCH v7 08/11] modesetting: Suspend and resume flipping with DPMS

previous commit to here v3: Unchanged v4: Unchanged v5: Move flipping_active check to sink support commit v6: Rebase onto ToT v7: Unchanged Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 18 ++ 1 file changed, 14 insertions

[PATCH v7 00/11] PRIME Synchronization

: https://lists.x.org/archives/xorg-devel/2016-February/048677.html v2: https://lists.x.org/archives/xorg-devel/2016-January/048434.html v1: https://lists.x.org/archives/xorg-devel/2015-November/048039.html Thanks, Alex @ NVIDIA Linux Driver Team Alex Goins (11): xf86: Add PRIME flipping

[PATCH v7 09/11] modesetting: Blacklist USB transport devices from PRIME sync

ToT v7: Expand to blacklist all USB transport devices, not just UDL Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/hw/xfree86/drivers/modesetting/driver.c b/hw/xfree86/drivers/modes

[PATCH v7 01/11] xf86: Add PRIME flipping functions to Screen

front and back parameters to RREnableSharedPixmapFlippingProcPtr v6: Rebase onto ToT v7: Unchanged Signed-off-by: Alex Goins <ago...@nvidia.com> --- include/scrnintstr.h | 14 ++ randr/randrstr.h | 17 + 2 files changed, 31 insertions(+) diff --git a/include/

[PATCH v7 03/11] randr: Add ability to turn PRIME sync off

t the output property to 0 if it has to fall back, to avoid user confusion. Make rr(Get)PixmapSharingSyncProp() check the current value if there isn't a pending value v4: Unchanged v5: Unchanged v6: Rebase onto ToT v7: Unchanged Signed-off-by: Alex Goins <ago...@nvidia.com> ---

[PATCH v7 06/11] modesetting: Always load ms->drmmode.pageflip

commit v6: Rebase onto ToT v7: Unchanged Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/driver.c b/hw/xfree86/drivers/modesetting/driver.

[PATCH v7 11/11] modesetting: Implement PRIME syncing as a source

: Move disabling of reverse PRIME on sink to sink commit v6: Rebase onto ToT v7: Unchanged Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 137 +++ hw/xfree86/drivers/modesetting/drmmode_display.h | 8 +- 2 files c

[PATCH v7 05/11] modesetting: Always tear down scanout pixmap

). v1: N/A v2: N/A v3: N/A v4: N/A v5: Initial commit v6: Rebase onto ToT v7: Unchanged Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 30 +--- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/hw/xfree86/d

[PATCH v7 04/11] modesetting: Internal storage of scanout pixmaps

reduce constraints on calling conventions. v1: N/A v2: N/A v3: N/A v4: N/A v5: Initial commit v6: Rebase onto ToT v7: Unchanged Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 9 + hw/xfree86/drivers/modesetting/drmmode_di

Re: [PATCH v6 10/11] modesetting: Disable Reverse PRIME for i915

Inline > > I'm not a huge fan of the term "reverse PRIME," since to me, reverse PRIME > > is > > just PRIME. PRIME can be used for display sink support with any two > > devices/drivers that expose the capabilities. I don't see why it should be > > considered "reverse PRIME" just because the sink

Re: [PATCH v6 09/11] modesetting: Blacklist UDL from PRIME sync

Hi Hans! Replying inline. > On 11-06-16 02:21, Alex Goins wrote: > > UDL (USB 2.0 DisplayLink DRM driver) has strange semantics when it comes to > > vblank events and damage tracking when page flipping. > > > > When doing a page flip, it will instantly raise a vblan

Re: [PATCH v6 10/11] modesetting: Disable Reverse PRIME for i915

> > >> IMHO the proposed patch does not sound like a reasonable long-term > > >> solution. Ideally the driver will expose a flag, based on which Xorg > > >> will enable/disable reverse prime. That said, as a short-term fix this > > >> is fine, barring the issues mentioned below. > > > > > > The

Re: [PATCH v6 10/11] modesetting: Disable Reverse PRIME for i915

Thanks for the feedback, Emil! > IMHO the proposed patch does not sound like a reasonable long-term > solution. Ideally the driver will expose a flag, based on which Xorg > will enable/disable reverse prime. That said, as a short-term fix this > is fine, barring the issues mentioned below. I'll

[PATCH v6 03/11] randr: Add ability to turn PRIME sync off

t the output property to 0 if it has to fall back, to avoid user confusion. Make rr(Get)PixmapSharingSyncProp() check the current value if there isn't a pending value v4: Unchanged v5: Unchanged v6: Rebase onto ToT Signed-off-by: Alex Goins <ago...@nvidia.com> --- randr/ran

[PATCH v6 11/11] modesetting: Implement PRIME syncing as a source

: Move disabling of reverse PRIME on sink to sink commit v6: Rebase onto ToT Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 137 +++ hw/xfree86/drivers/modesetting/drmmode_display.h | 8 +- 2 files changed, 144 inse

[PATCH v6 09/11] modesetting: Blacklist UDL from PRIME sync

to accomodate earlier changes v6: Rebase onto ToT Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/hw/xfree86/drivers/modesetting/driver.c b/hw/xfree86/drivers/modesetting/driver.c index ab3b028..f

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

aps internally to EnableSharedPixmapFlipping(). Don't support flipping if ms->drmmode.pageflip == FALSE. Move flipping_active check to this commit v6: Rebase onto ToT Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 96 +++- hw/

[PATCH v6 10/11] modesetting: Disable Reverse PRIME for i915

: Rebase onto ToT Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/driver.c b/hw/xfree86/drivers/modesetting/driver.c index f7abd1e..403cb96

[PATCH v6 05/11] modesetting: Always tear down scanout pixmap

). v1: N/A v2: N/A v3: N/A v4: N/A v5: Initial commit v6: Rebase onto ToT Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 30 +--- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/hw/xfree86/drivers/modes

[PATCH v6 00/11] PRIME Synchronization

xorg-devel/2016-February/048677.html v2: https://lists.x.org/archives/xorg-devel/2016-January/048434.html v1: https://lists.x.org/archives/xorg-devel/2015-November/048039.html Thanks, Alex @ NVIDIA Linux Driver Team Alex Goins (11): xf86: Add PRIME flipping functions to Screen randr

[PATCH v6 02/11] randr/xf86: Add PRIME Synchronization / Double Buffer

-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/modes/xf86Crtc.h| 4 ++ hw/xfree86/modes/xf86RandR12.c | 4 +- randr/randrstr.h | 1 + randr/rrcrtc.c | 131 - 4 files changed, 111 insertions(+), 29 deletions(-)

[PATCH v6 01/11] xf86: Add PRIME flipping functions to Screen

front and back parameters to RREnableSharedPixmapFlippingProcPtr v6: Rebase onto ToT Signed-off-by: Alex Goins <ago...@nvidia.com> --- include/scrnintstr.h | 14 ++ randr/randrstr.h | 17 + 2 files changed, 31 insertions(+) diff --git a/include/scrnintstr

[PATCH v6 08/11] modesetting: Suspend and resume flipping with DPMS

previous commit to here v3: Unchanged v4: Unchanged v5: Move flipping_active check to sink support commit v6: Rebase onto ToT Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 18 ++ 1 file changed, 14 insertions(+), 4 del

[PATCH v6 06/11] modesetting: Always load ms->drmmode.pageflip

commit v6: Rebase onto ToT Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/driver.c b/hw/xfree86/drivers/modesetting/driver.c index 0059e56.

[PATCH v6 04/11] modesetting: Internal storage of scanout pixmaps

reduce constraints on calling conventions. v1: N/A v2: N/A v3: N/A v4: N/A v5: Initial commit v6: Rebase onto ToT Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 9 + hw/xfree86/drivers/modesetting/drmmode_di

Re: [PATCH v5 00/13] PRIME Synchronization

Got it. Thanks! Alex On Fri, 27 May 2016, Dave Airlie wrote: > On 20 May 2016 at 08:36, Alex Goins <ago...@nvidia.com> wrote: > > Hi Dave, > > > > Any update on this? Anything I can do to help? > > Hey, > > can you take a look at > > prime:

Re: [PATCH xserver] prime: clean up slave bo properly. (v3)

Reviewed-by: Alex Goins Thanks, Alex On Fri, 6 May 2016, Dave Airlie wrote: > This is an ABI break, in that we now pass NULL to a function > that hasn't accepted it before. > > Alex Goins had a different patch for this but it wasn't symmetrical, > it freed something in a very

Re: [PATCH v5 00/13] PRIME Synchronization

Hi Dave, Any update on this? Anything I can do to help? Thanks, Alex On Tue, 3 May 2016, Dave Airlie wrote: > On 3 May 2016 at 12:19, Alex Goins <ago...@nvidia.com> wrote: > > Sorry for all of the self-replies. > > > > I spent more time looking into what mig

Re: [PATCH v5 00/13] PRIME Synchronization

(), and since there is no standard interface to do something like drm_intel_get_pipe_from_crtc_id(), we just make a best guess in drmmode_crtc_vblank_pipe(). Could be error-prone. Thanks, Alex On Sat, 30 Apr 2016, Alex Goins wrote: > D'oh, I was still running mutter with vblank_mode=0 from when I

Re: [PATCH xserver] prime: clean up slave bo properly. (v2)

to a function > >> that hasn't accepted it before. > >> > >> Alex Goins had a different patch for this but it wasn't symmetrical, > >> it freed something in a very different place than it allocated it, > >> this attempts to retain symmetry in the rele

Re: [PATCH v5 00/13] PRIME Synchronization

D'oh, I was still running mutter with vblank_mode=0 from when I had no native heads present. Now it's using the Present extension to wait for vblank, but not to flip. Still not seeing the issues described. Thanks, Alex On Sat, 30 Apr 2016, Alex Goins wrote: > So far I've been una

Re: [PATCH v5 00/13] PRIME Synchronization

bly doesn't mean much until I can resolve the above. Thanks, Alex On Fri, 29 Apr 2016, Alex Goins wrote: > > Okay I've finally gotten around to playing with these today. > > Thanks!! > > > I'm using a i915 + nouveau system with nouveau running as the master. Both &

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

I meant __GL_SYNC_DISPLAY_DEVICE=. Thanks Alex On Fri, 29 Apr 2016, Alex Goins wrote: > 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_SYN

Re: [PATCH v5 00/13] PRIME Synchronization

> Okay I've finally gotten around to playing with these today. Thanks!! > I'm using a i915 + nouveau system with nouveau running as the master. Both > using modesetting DDX. > > The basics seem to work okay, but I am seeing some issues I'm not 100% sure > are the fault of these patches. > >

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

heads in our driver. Thanks, Alex On Fri, 29 Apr 2016, Dave Airlie wrote: > On 13 April 2016 at 14:17, Alex Goins <ago...@nvidia.com> wrote: > > Adds typedefs for (*RRStartFlippingPixmapTrackingProcPtr), > > (*RREnableSharedPixmapFlippingProcPtr), > > and (*RRDisable

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

front and back parameters to RREnableSharedPixmapFlippingProcPtr Signed-off-by: Alex Goins <ago...@nvidia.com> --- include/scrnintstr.h | 14 ++ randr/randrstr.h | 17 + 2 files changed, 31 insertions(+) diff --git a/include/scrnintstr.h b/include/scrnin

[PATCH v5 05/13] modesetting: Always tear down scanout pixmap

). v1: N/A v2: N/A v3: N/A v4: N/A v5: Initial commit Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 30 +--- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_displa

[PATCH v5 06/13] modesetting: Always load ms->drmmode.pageflip

t Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/driver.c b/hw/xfree86/drivers/modesetting/driver.c index eb5084f..5edfd9b 100644 --- a/hw/

[PATCH v5 08/13] modesetting: Fix mmap leak in scanout_pixmap_cpu

() of the backing bo as part of the cleanup process. v1: Initial commit v2: Unchanged v3: Refactor to do dumb_bo_destroy as part of teardown_scanout_pixmap v4: Unchanged v5: Refactor for previous target change Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modes

[PATCH v5 11/13] modesetting: Disable Reverse PRIME for i915

-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/driver.c b/hw/xfree86/drivers/modesetting/driver.c index 987c577..e87de1a 100644 --- a/hw/xfree86/d

[PATCH v5 13/13] modesetting: Implement PRIME syncing as a source

: Move disabling of reverse PRIME on sink to sink commit Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 137 +++ hw/xfree86/drivers/modesetting/drmmode_display.h | 8 +- 2 files changed, 144 insertions(+), 1 de

[PATCH v5 04/13] modesetting: Internal storage of scanout pixmaps

reduce constraints on calling conventions. v1: N/A v2: N/A v3: N/A v4: N/A v5: Initial commit Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 9 + hw/xfree86/drivers/modesetting/drmmode_display.c | 22 ++

[PATCH v5 12/13] modesetting: Consistent whitespace in driver.c

-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 36 - 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/driver.c b/hw/xfree86/drivers/modesetting/driver.c index e87de1a..7e15c18

[PATCH v5 09/13] modesetting: Suspend and resume flipping with DPMS

previous commit to here v3: Unchanged v4: Unchanged v5: Move flipping_active check to sink support commit Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --gi

[PATCH v5 07/13] modesetting: Implement PRIME syncing as a sink

aps internally to EnableSharedPixmapFlipping(). Don't support flipping if ms->drmmode.pageflip == FALSE. Move flipping_active check to this commit Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 96 +++- hw/xfree86/drivers/modesett

[PATCH v5 10/13] modesetting: Blacklist UDL from PRIME sync

to accomodate earlier changes Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/hw/xfree86/drivers/modesetting/driver.c b/hw/xfree86/drivers/modesetting/driver.c index db50aa4..987c577 100644 --

[PATCH v5 03/13] randr: Add ability to turn PRIME sync off

t the output property to 0 if it has to fall back, to avoid user confusion. Make rr(Get)PixmapSharingSyncProp() check the current value if there isn't a pending value v4: Unchanged v5: Unchanged Signed-off-by: Alex Goins <ago...@nvidia.com> --- randr/randrstr.h

[PATCH v5 00/13] PRIME Synchronization

Driver Team Alex Goins (13): xf86: Add PRIME flipping functions to Screen randr/xf86: Add PRIME Synchronization / Double Buffer randr: Add ability to turn PRIME sync off modesetting: Internal storage of scanout pixmaps modesetting: Always tear down scanout pixmap modesetting: Always load ms

[PATCH v5 02/13] randr/xf86: Add PRIME Synchronization / Double Buffer

uses it. Refactor to use rrEnableSharedPixmapFlipping() as a substitute for rrCrtcSetScanoutPixmap() in the flipping case. Remove extraneous pSlaveScrPriv from DetachScanoutPixmap() Remove extraneous protopix and pScrPriv from rrSetupPixmapSharing() Signed-off-by: Alex Goins <

Re: [PATCH v4 02/13] modesetting: scanout_pixmap_gpu one call only

interested in feedback on the rest of the patch set; hoping to get this in ASAP so we can target it with our driver. Thanks, Alex On Tue, 8 Mar 2016, Alex Goins wrote: > > AFAICT RRReplaceScanoutPixmap may call set_scanout_pixmap while > > randr_crtc->scanout_pixmap is already non-NUL

Re: [PATCH v4 02/13] modesetting: scanout_pixmap_gpu one call only

> AFAICT RRReplaceScanoutPixmap may call set_scanout_pixmap while > randr_crtc->scanout_pixmap is already non-NULL (and pointing to a > different pixmap). That seems to be true now that you mention it. I haven't paid that much attention to RRReplaceScanoutPixmap(), since it doesn't seem to get

[PATCH v4 10/13] modesetting: Blacklist UDL from PRIME sync

with more well-behaved DRM drivers. Work needs to be done on UDL in order to properly support synchronized PRIME. For now, just blacklist it, causing RandR to fall back to unsynchronized PRIME. v1: N/A v2: N/A v3: Initial commit v4: Move check to driver.c for consistency/visibility Signed-off-by: Alex

[PATCH v4 13/13] modesetting: Implement PRIME syncing as a source

Signed-off-by: Alex Goins <ago...@nvidia.com> --- hw/xfree86/drivers/modesetting/driver.c | 141 +++ hw/xfree86/drivers/modesetting/drmmode_display.h | 8 +- 2 files changed, 148 insertions(+), 1 deletion(-) diff --git a/hw/xfree86/drivers/modesetting/driver.c

  1   2   >