alization after 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/s
ME Sync 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 t
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 slave
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 wrot
gt; is equivalent to slave screen in modesetting driver 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 a
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 SharedPixmapNotify
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 t
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
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
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
> >
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
---
randr/rrscreen.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/randr/rrscreen.c b/randr/rrscreen.c
index f484383.
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
---
randr/rrscreen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
> On Fri, 2017-11-03 at 21:04 -0700, Alex Goins wrote:
>
> > > > DPCCompositorChangeNotify
> > > >
> > > > requester: WINDOW window requesting notification
> > > > output: OUTPUT output affected by change
>
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
> 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 w
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
ructures the HW 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
es, is added 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
xf86CheckHWCursor() has spacing that is inconsistent with the rest of the file.
Correct this in preparation for subsequent changes.
Signed-off-by: Alex Goins
---
hw/xfree86/ramdac/xf86HWCurs.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/xfree86/ramdac
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
---
hw/xfree86/ramdac/Makefile.am | 4 ++--
hw/xfree86/sdksyms.sh | 1 +
2 files changed, 3 insertions(+), 2
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
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_vblan
ering Extension", 2009-07-15,
-http://cgit.freedesktop.org/xorg/proto/renderproto/tree/renderproto.txt
+[PRESENT]
+Packard, Keith, "The Present Extension", 2013-06-06,
+https://cgit.freedesktop.org/xorg/proto/presentproto/plain/presentproto.txt
-
DeepColor
calls xf86SetCursor(NullCursor). If
xf86ScreenSetCursor(NullCursor) returns FALSE, it calls
xf86SetCursor(NullCursor) again and this repeats forever.
Signed-off-by: Alex Goins
---
hw/xfree86/ramdac/xf86HWCurs.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/hw/xfree86/ra
() 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
On Sun, 15 Oct 2017, Keith Packard wrote:
> Alex Goins 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 editorial comments.
Thanks, Adam.
Here's an updated version of the spec:
DeepColor Extension
Version X.X
2017-XX-XX
Alex Goins
ago...@nvidi
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 structure is possible, but as w
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, de
Inline
On Wed, 19 Jul 2017, Keith Packard wrote:
> * PGP Signed by an unknown key
>
> Alex Goins writes:
>
> > 2. DeepColor Visual Class
> >
> > The DeepColor extension defines a new visual class, DeepColor.
>
> As Adam says, reporting a new visua
I-specific 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,
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
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 cou
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 {
>
>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;
>
> >> 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. I'll
> > 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 glX
g ideas and criticism from the community. 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
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
Reviewed-by: Andy Ritger
---
hw/xfree86/ramdac/xf86HWCurs.c | 4 ++
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
Reviewed-by: Andy Ritger
---
hw/xfree86/ramdac/xf86HWCurs.c | 3 ++-
1 fi
default behavior remained
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
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
> > mov
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
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 Goins
---
> 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 it
> 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
mit
v5: Unchanged
v6: Rebase onto ToT
v7: NULL check and free drmVersionPtr
Signed-off-by: Alex Goins
---
hw/xfree86/drivers/modesetting/driver.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/drivers/modesetting/driver.c
b/hw/xfree86/drivers/modese
v3: 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 fli
() to set scanout pixmaps
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
---
hw/xfree86/drivers/modesetting/driver.c
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
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff
anged
Signed-off-by: Alex Goins
---
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(-)
diff
ebase onto ToT
v7: Expand to blacklist all USB transport devices, not just UDL
Signed-off-by: Alex Goins
---
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/modesetting/driv
: Add front and back parameters to RREnableSharedPixmapFlippingProcPtr
v6: Rebase onto ToT
v7: Unchanged
Signed-off-by: Alex Goins
---
include/scrnintstr.h | 14 ++
randr/randrstr.h | 17 +
2 files changed, 31 insertions(+)
diff --git a/include/scrnintstr.
different sources with different outputs
Make rrSetupPixmapSharing() set 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
tial commit
v6: Rebase onto ToT
v7: Unchanged
Signed-off-by: Alex Goins
---
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..97a7404 1
: Move disabling of reverse PRIME on sink to sink commit
v6: Rebase onto ToT
v7: Unchanged
Signed-off-by: Alex Goins
---
hw/xfree86/drivers/modesetting/driver.c | 137 +++
hw/xfree86/drivers/modesetting/drmmode_display.h | 8 +-
2 files changed, 144 insertions(+), 1
).
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
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 30 +---
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/hw/xfree86/drivers/modesetting
bugs and 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
---
hw/xfree86/drivers/modesetting/driver.c | 9 +
hw/xfree86/drivers/modesetting/drmmod
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
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 vblank ev
> > >> 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 dec
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 a
different sources with different outputs
Make rrSetupPixmapSharing() set 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: Unchang
: Move disabling of reverse PRIME on sink to sink commit
v6: Rebase onto ToT
Signed-off-by: Alex Goins
---
hw/xfree86/drivers/modesetting/driver.c | 137 +++
hw/xfree86/drivers/modesetting/drmmode_display.h | 8 +-
2 files changed, 144 insertions(+), 1 deletion
efactor to accomodate earlier changes
v6: Rebase onto ToT
Signed-off-by: Alex Goins
---
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..f7abd1e 10064
() to set scanout pixmaps
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
---
hw/xfree86/drivers/modesetting/driver.c | 96 +++-
hw/
mit
v5: Unchanged
v6: Rebase onto ToT
Signed-off-by: Alex Goins
---
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 100
).
v1: N/A
v2: N/A
v3: N/A
v4: N/A
v5: Initial commit
v6: Rebase onto ToT
Signed-off-by: Alex Goins
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 30 +---
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
b
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 functions to
d-off-by: Alex Goins
---
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(-)
diff --git a/hw/xf
: Add front and back parameters to RREnableSharedPixmapFlippingProcPtr
v6: Rebase onto ToT
Signed-off-by: Alex Goins
---
include/scrnintstr.h | 14 ++
randr/randrstr.h | 17 +
2 files changed, 31 insertions(+)
diff --git a/include/scrnintstr.h b/include/scrnint
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
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/hw
tial commit
v6: Rebase onto ToT
Signed-off-by: Alex Goins
---
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..97a7404 100644
--
bugs and 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
---
hw/xfree86/drivers/modesetting/driver.c | 9 +
hw/xfree86/drivers/modesetting/drmmode_display.c | 22 ++
Got it.
Thanks!
Alex
On Fri, 27 May 2016, Dave Airlie wrote:
> On 20 May 2016 at 08:36, Alex Goins wrote:
> > Hi Dave,
> >
> > Any update on this? Anything I can do to help?
>
> Hey,
>
> can you take a look at
>
> prime: clean up slave bo properly. (
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
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 wrote:
> > Sorry for all of the self-replies.
> >
> > I spent more time looking into what might be causing this (despite
crtc_id directly like
drmModePageFlip(), 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
gt; >> 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 releasing of the b
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'
ked OK with DRI2 so that probably 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 nouvea
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 __G
> 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.
>
> Sce
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 wrote:
> > Adds typedefs for (*RRStartFlippingPixmapTrackingProcPtr),
> > (*RREnableSharedPixmapFlippingProcPtr),
> > and (*RRDisableSharedPixma
: Add front and back parameters to RREnableSharedPixmapFlippingProcPtr
Signed-off-by: Alex Goins
---
include/scrnintstr.h | 14 ++
randr/randrstr.h | 17 +
2 files changed, 31 insertions(+)
diff --git a/include/scrnintstr.h b/include/scrnintstr.h
index 2e617c4..c74
).
v1: N/A
v2: N/A
v3: N/A
v4: N/A
v5: Initial commit
Signed-off-by: Alex Goins
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 30 +---
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
b/hw/xfree86/drivers
commit
Signed-off-by: Alex Goins
---
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/xfree86/drive
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
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 1 +
1
5: Unchanged
Signed-off-by: Alex Goins
---
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
: Move disabling of reverse PRIME on sink to sink commit
Signed-off-by: Alex Goins
---
hw/xfree86/drivers/modesetting/driver.c | 137 +++
hw/xfree86/drivers/modesetting/drmmode_display.h | 8 +-
2 files changed, 144 insertions(+), 1 deletion(-)
diff --git a/hw
-off-by: Alex Goins
---
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 100644
--- a/hw/xfree86
previous commit to here
v3: Unchanged
v4: Unchanged
v5: Move flipping_active check to sink support commit
Signed-off-by: Alex Goins
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/hw/xfree86/drivers
bugs and 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
---
hw/xfree86/drivers/modesetting/driver.c | 9 +
hw/xfree86/drivers/modesetting/drmmode_display.c | 22 ++
hw/xfree86/dri
() to set scanout pixmaps
internally to EnableSharedPixmapFlipping().
Don't support flipping if ms->drmmode.pageflip == FALSE.
Move flipping_active check to this commit
Signed-off-by: Alex Goins
---
hw/xfree86/drivers/modesetting/driver.c | 96 +++-
hw/
efactor to accomodate earlier changes
Signed-off-by: Alex Goins
---
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
--- a/hw/xfree
different sources with different outputs
Make rrSetupPixmapSharing() set 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: U
IDIA Linux 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: Alwa
PRIME 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
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
> 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 exe
1 - 100 of 157 matches
Mail list logo
