Re: Damage as a DIX notion

2016-09-25 Thread Keith Packard 
Michel Dänzer  writes:

> And it should be relatively easy to get that with the existing damage
> code. Since glamor is only interested in the damage region extents, it
> can set a DamageReportFunc which drops everything but the extents of the
> current operation, something like (based on a function used by the
> amdgpu/radeon drivers):

We're actually thinking of getting rid of the wrappers for damage and
doing them in DIX instead. Reducing the per-operation damage to just a
bounding box would make this a bunch simpler as well -- the pre/post op
damage bits can be handled by doing:

compute_bounds()
pre_op_damage()
operation(...)
post_op_damage()

In my mail to Eric, I suggest providing DIX-level functions that handle
an entire core operation, much like Render does:

PolyPoint(DrawablePtr drawable,
  GCPtr gc,
  int npoint,
  xPoint *points)
{
BoxRec bounds
if (gc->serialNumber != drawable->serialNumber)
ValidateGC(drawable, gc);
bounds_poly_point(drawable, gc, npoint, points, );
pre_op_damage(drawble, );
(*gc->ops->PolyPoint)(drawable, gc, npoint, points, );
post_op_damage(drawable, );
} 

> Based on my experience with the amdgpu/radeon drivers, the CPU overhead
> of this might be acceptable as is.

I think the only operation which might expose the overhead is text, both
core and render.

> (Such a new damageLevel might even be interesting for compositors as
> well)

DamageReportBoundingBox provides something like this.

-- 
-keith


signature.asc
Description: PGP signature
___
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

Re: Damage as a DIX notion

2016-09-25 Thread Keith Packard 
Eric Anholt  writes:

> In talking with ajax, I came around to "just compute the bounds up
> front, always."

That's certainly simpler. It would be useful to go and measure how much
of firefox's (and maybe other applications?) rendering is aimed at
pixmaps without damage tracking enabled.

> All glamor ops will want the damage for scissoring (we're already
> setting scissors all the time, so now we just intersect the new incoming
> box with the scissor we were going to set).  All window ops want the
> damage for compositing.  Software cursor wants it for screen.  Basically
> what get from the kinda complicated lazy damage API is avoiding damage
> computation for pixmap-only rendering.

The question is whether damage-less rendering happens enough to be worth
this effort. That includes both pixmap rendering and non-composited
desktops.

Text is probably the most interesting operation for which server
request overhead is significant (the other being dots).

> I think the approach outlined here would also work.  I'm just not
> convinced it's necessary.

A data-driven approach would be awesome here. Do we have a reasonable
performance metric? I'm no fan of gratuitous complexity, but text
performance is pretty important to me.

Maybe we can have our cake and eat it too -- is there any reason we
couldn't use a more complex mechanism for just a few operations? The
only interaction would be in the mi text code where it would have to
force the bounds computation before reverting to the spans code. 

Speaking of text, the current core text interface doesn't work for
glamor -- I need the original character data along with the glyph
pointers, so glamor currently duplicates the glyph lookup stuff. In
addition, that API kinda sucks as it elides missing glyphs without any
indication. If we replaced the core text API with one that delivered the
chars and glyphs together, we could reduce the number of GC functions
and also make computing the bounds not involve doing the glyph lookups
twice (once in damage, once in glamor). I know core text shouldn't
matter, but there's a bunch of duplicate code here.

Another thought -- I wrote wrapper functions for Render drawing which do
all of the validation etc. We should do the same for all of the core
APIs and then go root out all of the places which call through the gc
ops directly. This would be an easy place to stick damage, eliminating a
layer in the drawing stack, and also eliminating a few ValidateGC calls.

-- 
-keith


signature.asc
Description: PGP signature
___
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

Re: [PATCH xserver v3 02/11] glamor: Require that pixmap depths match for Render copies.

2016-09-25 Thread Michel Dänzer 
On 26/09/16 05:30 AM, Eric Anholt wrote:
> The copy optimization in d37329cba42fa8e72fe4be8a7be18e512268b5bd
> replicated a bug from last time we did a copy optimization: CopyArea
> is only defined for matching depths.  This is only a problem at 15 vs
> 16bpp right now (24 vs 32 would also have matching Render formats but
> they should work) but be strict in case we store other bpps
> differently in the future.

Nitpick: s/bpp/depth/g


> Fixes rendercheck -t blend -o src -f x4r4g4b4,x3r4g4b4
> 
> v2: Drop excessive src->depth == dst->depth check that snuck in.
> v3: Switch back to src->depth == dst->depth
> 
> Signed-off-by: Eric Anholt 

Regardless of the above, patches 1-3 are

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
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

Re: Damage as a DIX notion

2016-09-25 Thread Michel Dänzer 
On 26/09/16 05:45 AM, Eric Anholt wrote:
> 
> In talking with ajax, I came around to "just compute the bounds up
> front, always."

And it should be relatively easy to get that with the existing damage
code. Since glamor is only interested in the damage region extents, it
can set a DamageReportFunc which drops everything but the extents of the
current operation, something like (based on a function used by the
amdgpu/radeon drivers):

static void
glamor_damage_report(DamagePtr damage, RegionPtr region, void *closure)
{
/* Only keep track of the extents */
RegionUninit(>damage);
damage->damage.data = NULL;
damage->damage.extents = *RegionExtents(region);
}

Then the glamor rendering functions can just look at the damage region
extents.

Based on my experience with the amdgpu/radeon drivers, the CPU overhead
of this might be acceptable as is. But if it turns out to be too heavy,
we should be able to reduce it by introducing a new damageLevel which
only ever keeps track of the overall extents of the damage region, and
making the damage wrappers of rendering functions only compute the
bounding box if none of the damage records require an accurate region.

(Such a new damageLevel might even be interesting for compositors as well)


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital signature
___
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 xserver] input: fix VT switch disabling devices

2016-09-25 Thread Mihail Konev 
Make sure device removes are processed before doing a VT switch,
so that no removes are "overwritten" with attachments afterwards
(before the main thread releases the input lock, letting them be
processed), which would leave affected devices disabled.

Pass a timeout to input poll instead of telling it to wait forever,
so that no deadlock before VT switch is possible if main thread
waits for release processing only by the time input thread
is already done and does another poll.

When preparing a VT switch, temprorarily decrease polling
timeout, so there is (likely) no noticeable stall.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97880
Regressed-in: 52d6a1e832a5e62289dd4f32824ae16a78dfd7e8
Signed-off-by: Mihail Konev 
---

The patch could be wrong with regard to namings (InputThreadWait vs. input_wait)
and multiple input threads (struct InputThreadInfo).

 hw/xfree86/common/xf86Events.c |  4 
 include/input.h|  4 
 os/inputthread.c   | 39 ++-
 3 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/hw/xfree86/common/xf86Events.c b/hw/xfree86/common/xf86Events.c
index 9a8f432a0556..8290c117116e 100644
--- a/hw/xfree86/common/xf86Events.c
+++ b/hw/xfree86/common/xf86Events.c
@@ -430,6 +430,7 @@ xf86VTLeave(void)
  * Keep the order: Disable Device > LeaveVT
  *EnterVT > EnableDevice
  */
+InputThreadPollTimeoutSmall();
 for (ih = InputHandlers; ih; ih = ih->next) {
 if (ih->is_input)
 xf86DisableInputHandler(ih);
@@ -439,6 +440,9 @@ xf86VTLeave(void)
 for (pInfo = xf86InputDevs; pInfo; pInfo = pInfo->next)
 xf86DisableInputDeviceForVTSwitch(pInfo);
 
+InputThreadWaitForProcessingAllRemoves();
+InputThreadPollTimeoutNormal();
+
 input_lock();
 for (i = 0; i < xf86NumScreens; i++)
 xf86Screens[i]->LeaveVT(xf86Screens[i]);
diff --git a/include/input.h b/include/input.h
index e0f6b9b01d97..1afb3f89a33a 100644
--- a/include/input.h
+++ b/include/input.h
@@ -719,6 +719,10 @@ extern _X_EXPORT void input_lock(void);
 extern _X_EXPORT void input_unlock(void);
 extern _X_EXPORT void input_force_unlock(void);
 
+extern _X_EXPORT void InputThreadPollTimeoutSmall(void);
+extern _X_EXPORT void InputThreadPollTimeoutNormal(void);
+extern _X_EXPORT void InputThreadWaitForProcessingAllRemoves(void);
+
 extern void InputThreadPreInit(void);
 extern void InputThreadInit(void);
 extern void InputThreadFini(void);
diff --git a/os/inputthread.c b/os/inputthread.c
index 6aa0a9ce6fb5..fab3c30954e5 100644
--- a/os/inputthread.c
+++ b/os/inputthread.c
@@ -90,6 +90,12 @@ static pthread_mutex_t input_mutex;
 static Bool input_mutex_initialized;
 #endif
 
+int input_poll_timeout_ms;
+
+static Bool waiting_for_processing_all_removes = FALSE;
+static int unprocessed_removes_count = 0;
+static pthread_barrier_t all_removes_processed_barrier;
+
 void
 input_lock(void)
 {
@@ -125,6 +131,25 @@ input_force_unlock(void)
 }
 }
 
+void
+InputThreadPollTimeoutSmall(void)
+{
+input_poll_timeout_ms = 4;
+}
+
+void
+InputThreadPollTimeoutNormal(void)
+{
+input_poll_timeout_ms = 200;
+}
+
+void
+InputThreadWaitForProcessingAllRemoves(void)
+{
+waiting_for_processing_all_removes = TRUE;
+pthread_barrier_wait(_removes_processed_barrier);
+}
+
 /**
  * Notify a thread about the availability of new asynchronously enqueued input
  * events.
@@ -267,6 +292,7 @@ InputThreadUnregisterDev(int fd)
 
 dev->state = device_state_removed;
 inputThreadInfo->changed = TRUE;
+unprocessed_removes_count++;
 
 input_unlock();
 
@@ -348,13 +374,19 @@ InputThreadDoWork(void *arg)
 ospoll_remove(inputThreadInfo->fds, dev->fd);
 xorg_list_del(>node);
 free(dev);
+unprocessed_removes_count--;
 break;
 }
 }
 input_unlock();
 }
 
-if (ospoll_wait(inputThreadInfo->fds, -1) < 0) {
+if (waiting_for_processing_all_removes && !unprocessed_removes_count) {
+waiting_for_processing_all_removes = FALSE;
+pthread_barrier_wait(_removes_processed_barrier);
+}
+
+if (ospoll_wait(inputThreadInfo->fds, input_poll_timeout_ms) < 0) {
 if (errno == EINVAL)
 FatalError("input-thread: %s (%s)", __func__, strerror(errno));
 else if (errno != EINTR)
@@ -400,6 +432,8 @@ InputThreadPreInit(void)
 if (!inputThreadInfo)
 FatalError("input-thread: could not allocate memory");
 
+pthread_barrier_init(_removes_processed_barrier, NULL, 2);
+
 inputThreadInfo->thread = 0;
 xorg_list_init(>devs);
 inputThreadInfo->fds = ospoll_create();
@@ -434,6 +468,7 @@ InputThreadPreInit(void)
 pthread_setname_np ("MainThread");
 #endif
 
+InputThreadPollTimeoutNormal();
 }
 
 /**
@@ -517,6 +552,8 @@ int

Re: Damage as a DIX notion

2016-09-25 Thread Eric Anholt 
Keith Packard  writes:

> Adam, Eric and I were chatting at XDC about how to make damage
> computations more efficient and more useful.
>
> The impetus of this was that glamor on tilers would like to have the
> bounds of every operation to reduce the number of tiles processed for
> small operations. Damage already computes the bounds of every operation,
> but that bounds is not available to glamor. Re-computing the bounds
> would be wasteful, so instead we want to capture the computation done
> (potentially) by damage instead of redoing it.
>
> I've taken a couple of stabs at a design, and I figured I'd share my
> current ideas to get some feedback.
>
> First off, I think I need a set of bounds computing functions, one per
> rendering operation. I've started writing these to compute a simple
> bounding box for an entire operation. This may be larger than what
> Damage currently computes, but I don't think a closer bounds is
> interesting for most operations.
>
> Next, I think we just want to pass any computed bounds along with the
> rendering operation. This means tacking on another argument to all of
> them. A NULL value means that no bounds have been computed yet.
>
> Finally, each element in the stack which needs the operation bounds will
> have a local BoxRec to hold a bounds, and then call the
> operation-specific bounds function, which will either use the existing
> bounds (if non-NULL), or fill in the local BoxRec and return that.
>
> Here's a sample of these new functions:
>
> BoxPtr
> bounds_poly_point(DrawablePtr drawable,
>   GCPtr gc,
>   int npoint,
>   const xPoint *points,
>   BoxPtr bounds,
>   BoxPtr local_bounds)
> {
> int i;
>
> /* Are the operation bounds already computed? */
> if (bounds != NULL)
> return bounds;
>
> /* Compute bounds of this operation */
> bounds = local_bounds;
> if (npoint == 0) {
> *bounds = bounds_empty();
> return bounds;
> }
>
> open_rect_to_box(bounds, points[0].x, points[0].y, 1, 1);
> for (i = 1; i < npoint; i++)
> open_rect_union(bounds, bounds, points[i].x, points[i].y, 1, 
> 1);
> bounds_trim_gc(drawable, gc, bounds);
> return bounds;
> }
>
> Here's how the Damage layer uses this:
>
> static void
> damagePolyPoint(DrawablePtr pDrawable,
> GCPtr pGC, int npt, const xPoint * ppt,
> BoxPtr bounds)
> {
> BoxRec local_bounds;
> DAMAGE_GC_OP_PROLOGUE(pGC, pDrawable);
>
> if (checkGCDamage(pDamage, pGC)) {
> bounds = bounds_poly_point(pDrawable, pGC, npt, ppt, bounds, 
> _bounds);
> if (!bounds_is_empty(bounds))
> damageDamageRelBox(pDrawable, bounds, pGC->subWindowMode);
> }
> (*pGC->ops->PolyPoint) (pDrawable, pGC, npt, ppt, bounds);
> damageRegionProcessPending(pDamage);
> DAMAGE_GC_OP_EPILOGUE(pGC, pDrawable);
> }

(I assume there's a missing BoxPtr bounds = NULL at the top of this function)

> We can obviously change the internals of Damage so that we just pass the
> damage box to damageRegionProcessPending; that will greatly simplify the
> internals of that code.
>
> Now, down in glamor, we can do the same thing to compute the bounds as
> needed. Here's how a glamor fallback works:
>
> static void
> glamor_poly_fill_rect_bail(DrawablePtr drawable,
>GCPtr gc, int nrect, const xRectangle 
> *prect,
>BoxPtr bounds)
> {
> BoxRec local_bounds;
>
> glamor_fallback("to %p (%c)\n", drawable,
> glamor_get_drawable_location(drawable));
> bounds = bounds_poly_fill_rect(drawable, gc, nrect, prect, 
> bounds, _bounds);
> if (glamor_prepare_access_box(drawable, GLAMOR_ACCESS_RW, bounds) 
> &&
> glamor_prepare_access_gc(gc))
> {
> fbPolyFillRect(drawable, gc, nrect, prect, bounds);
> }
> glamor_finish_access_gc(gc);
> glamor_finish_access(drawable);
> }
>
> If Damage has already computed the bounds of the operation, then glamor
> can re-use that value. Otherwise, it will compute the bounds itself to
> reduce the amount of data shuffled.
>
> I've written just a smattering of the code as I'm assuming we'll improve
> this design and probably end up replacing all of the code. I had
> initially thought that we'd want to take advantage of the patches I've
> sent around which make the rendering data immutable, but that isn't
> necessary for this

[PATCH xserver v3 02/11] glamor: Require that pixmap depths match for Render copies.

2016-09-25 Thread Eric Anholt 
The copy optimization in d37329cba42fa8e72fe4be8a7be18e512268b5bd
replicated a bug from last time we did a copy optimization: CopyArea
is only defined for matching depths.  This is only a problem at 15 vs
16bpp right now (24 vs 32 would also have matching Render formats but
they should work) but be strict in case we store other bpps
differently in the future.

Fixes rendercheck -t blend -o src -f x4r4g4b4,x3r4g4b4

v2: Drop excessive src->depth == dst->depth check that snuck in.
v3: Switch back to src->depth == dst->depth

Signed-off-by: Eric Anholt 
---
 glamor/glamor_render.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index a06868e3fdaa..d4d69a695d4d 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -1423,6 +1423,8 @@ glamor_composite_clipped_region(CARD8 op,
 /* Is the composite operation equivalent to a copy? */
 if (!mask && !source->alphaMap && !dest->alphaMap
 && source->pDrawable && !source->transform
+/* CopyArea is only defined with matching depths. */
+&& dest->pDrawable->depth == source->pDrawable->depth
 && ((op == PictOpSrc
  && (source->format == dest->format
  || (PICT_FORMAT_COLOR(dest->format)
-- 
2.9.3

___
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 xserver v3 05/11] test: Handle srcdir != builddir in Xvfb testing.

2016-09-25 Thread Eric Anholt 
Signed-off-by: Eric Anholt 
---
 test/Makefile.am| 3 ++-
 test/scripts/xvfb-piglit.sh | 8 +++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/test/Makefile.am b/test/Makefile.am
index 5a35e2bb198f..4ccadf5b0005 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -26,7 +26,8 @@ TESTS = \
$(NULL)
 
 TESTS_ENVIRONMENT = \
-   XSERVER_DIR=$(abs_top_builddir) \
+   XSERVER_DIR=$(abs_top_srcdir) \
+   XSERVER_BUILDDIR=$(abs_top_builddir) \
$(XORG_MALLOC_DEBUG_ENV) \
$(NULL)
 
diff --git a/test/scripts/xvfb-piglit.sh b/test/scripts/xvfb-piglit.sh
index 2a4e9405268d..b775239e34f5 100755
--- a/test/scripts/xvfb-piglit.sh
+++ b/test/scripts/xvfb-piglit.sh
@@ -20,12 +20,18 @@ if test "x$XSERVER_DIR" = "x"; then
 exit 1
 fi
 
+if test "x$XSERVER_BUILDDIR" = "x"; then
+echo "XSERVER_BUILDDIR must be set to the build directory of the xserver 
repository."
+# Exit as a real failure because it should always be set.
+exit 1
+fi
+
 export PIGLIT_RESULTS_DIR=$PIGLIT_DIR/results/xvfb
 
 startx \
 $XSERVER_DIR/test/scripts/xinit-piglit-session.sh \
 -- \
-$XSERVER_DIR/hw/vfb/Xvfb \
+$XSERVER_BUILDDIR/hw/vfb/Xvfb \
 -noreset \
 -screen scrn 1280x1024x24
 
-- 
2.9.3

___
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 xserver v3 03/11] glamor: Properly handle mask formats without alpha.

2016-09-25 Thread Eric Anholt 
Even if the pixmap's storage has alpha, it may have been uploaded with
garbage in the alpha channel, so we need to force the shader to set
alpha to 1.  This was broken way back in
355334fcd99e4dce62e2be1e27290c9a74ea944f.

Fixes rendercheck -t composite -f x8r8g8b8.

Signed-off-by: Eric Anholt 
---
 glamor/glamor_render.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index d4d69a695d4d..f5651eb87e54 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -868,7 +868,10 @@ glamor_composite_choose_shader(CARD8 op,
 goto fail;
 }
 else {
-key.mask = SHADER_MASK_TEXTURE_ALPHA;
+if (PICT_FORMAT_A(mask->format))
+key.mask = SHADER_MASK_TEXTURE_ALPHA;
+else
+key.mask = SHADER_MASK_TEXTURE;
 }
 
 if (!mask->componentAlpha) {
-- 
2.9.3

___
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 xserver v3 01/11] glamor: Fix some awful formatting of some fallback debug code.

2016-09-25 Thread Eric Anholt 
This was clearly x-indent.sh damage.

Signed-off-by: Eric Anholt 
---
 glamor/glamor_render.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index f87bbf34fa74..a06868e3fdaa 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -1712,12 +1712,12 @@ glamor_composite(CARD8 op,
  source, source->pDrawable,
  source->pDrawable ? source->pDrawable->width : 0,
  source->pDrawable ? source->pDrawable->height : 0, mask,
- (!mask) ? NULL : mask->pDrawable, (!mask
-|| !mask->pDrawable) ? 0 :
- mask->pDrawable->width, (!mask
-  || !mask->pDrawable) ? 0 : mask->
- pDrawable->height, glamor_get_picture_location(source),
- glamor_get_picture_location(mask), dest, dest->pDrawable,
+ (!mask) ? NULL : mask->pDrawable,
+ (!mask || !mask->pDrawable) ? 0 : mask->pDrawable->width,
+ (!mask || !mask->pDrawable) ? 0 : mask->pDrawable->height,
+ glamor_get_picture_location(source),
+ glamor_get_picture_location(mask),
+ dest, dest->pDrawable,
  dest->pDrawable->width, dest->pDrawable->height,
  glamor_get_picture_location(dest));
 
-- 
2.9.3

___
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 xserver v3 07/11] test: Make the piglit-running script callable with an arbitrary server.

2016-09-25 Thread Eric Anholt 
v2: Check that SERVER_COMMAND is set.

Signed-off-by: Eric Anholt 
---
 test/.gitignore|  1 +
 test/Makefile.am   |  1 +
 test/scripts/{xvfb-piglit.sh => run-piglit.sh} | 16 --
 test/scripts/xvfb-piglit.sh| 73 ++
 4 files changed, 18 insertions(+), 73 deletions(-)
 copy test/scripts/{xvfb-piglit.sh => run-piglit.sh} (83%)

diff --git a/test/.gitignore b/test/.gitignore
index c44fc827ac13..47f766c5f620 100644
--- a/test/.gitignore
+++ b/test/.gitignore
@@ -11,6 +11,7 @@ xfree86
 xkb
 xtest
 signal-logging
+piglit-results
 simple-xinit
 *.log
 *.trs
diff --git a/test/Makefile.am b/test/Makefile.am
index 24bfc35bc88a..cf19beca96ff 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -163,6 +163,7 @@ endif
 EXTRA_DIST = \
$(SCRIPT_TESTS) \
scripts/xinit-piglit-session.sh \
+   scripts/run-piglit.sh \
ddxstubs.c \
$(NULL)
 
diff --git a/test/scripts/xvfb-piglit.sh b/test/scripts/run-piglit.sh
similarity index 83%
copy from test/scripts/xvfb-piglit.sh
copy to test/scripts/run-piglit.sh
index b775239e34f5..11e9c1eb9883 100755
--- a/test/scripts/xvfb-piglit.sh
+++ b/test/scripts/run-piglit.sh
@@ -14,6 +14,12 @@ if test "x$PIGLIT_DIR" = "x"; then
 exit 77
 fi
 
+if test "x$PIGLIT_RESULTS_DIR" = "x"; then
+echo "PIGLIT_RESULTS_DIR must be set to where to output piglit results."
+# Exit as a real failure because it should always be set.
+exit 1
+fi
+
 if test "x$XSERVER_DIR" = "x"; then
 echo "XSERVER_DIR must be set to the directory of the xserver repository."
 # Exit as a real failure because it should always be set.
@@ -26,14 +32,16 @@ if test "x$XSERVER_BUILDDIR" = "x"; then
 exit 1
 fi
 
-export PIGLIT_RESULTS_DIR=$PIGLIT_DIR/results/xvfb
+if test "x$SERVER_COMMAND" = "x"; then
+echo "SERVER_COMMAND must be set to the server to be spawned."
+# Exit as a real failure because it should always be set.
+exit 1
+fi
 
 startx \
 $XSERVER_DIR/test/scripts/xinit-piglit-session.sh \
 -- \
-$XSERVER_BUILDDIR/hw/vfb/Xvfb \
--noreset \
--screen scrn 1280x1024x24
+$SERVER_COMMAND
 
 # Write out piglit-summaries.
 SHORT_SUMMARY=$PIGLIT_RESULTS_DIR/summary
diff --git a/test/scripts/xvfb-piglit.sh b/test/scripts/xvfb-piglit.sh
index b775239e34f5..799f2850057a 100755
--- a/test/scripts/xvfb-piglit.sh
+++ b/test/scripts/xvfb-piglit.sh
@@ -1,72 +1,7 @@
-#!/bin/sh
-
-set -e
-
-if test "x$XTEST_DIR" = "x"; then
-echo "XTEST_DIR must be set to the directory of the xtest repository."
-# Exit as a "skip" so make check works even without piglit.
-exit 77
-fi
-
-if test "x$PIGLIT_DIR" = "x"; then
-echo "PIGLIT_DIR must be set to the directory of the piglit repository."
-# Exit as a "skip" so make check works even without piglit.
-exit 77
-fi
-
-if test "x$XSERVER_DIR" = "x"; then
-echo "XSERVER_DIR must be set to the directory of the xserver repository."
-# Exit as a real failure because it should always be set.
-exit 1
-fi
-
-if test "x$XSERVER_BUILDDIR" = "x"; then
-echo "XSERVER_BUILDDIR must be set to the build directory of the xserver 
repository."
-# Exit as a real failure because it should always be set.
-exit 1
-fi
-
-export PIGLIT_RESULTS_DIR=$PIGLIT_DIR/results/xvfb
-
-startx \
-$XSERVER_DIR/test/scripts/xinit-piglit-session.sh \
--- \
-$XSERVER_BUILDDIR/hw/vfb/Xvfb \
+export SERVER_COMMAND="$XSERVER_DIR/hw/vfb/Xvfb \
 -noreset \
--screen scrn 1280x1024x24
-
-# Write out piglit-summaries.
-SHORT_SUMMARY=$PIGLIT_RESULTS_DIR/summary
-LONG_SUMMARY=$PIGLIT_RESULTS_DIR/long-summary
-$PIGLIT_DIR/piglit-summary.py -s $PIGLIT_RESULTS_DIR > $SHORT_SUMMARY
-$PIGLIT_DIR/piglit-summary.py $PIGLIT_RESULTS_DIR > $LONG_SUMMARY
-
-# Write the short summary to make check's log file.
-cat $SHORT_SUMMARY
-
-# Parse the piglit summary to decide on our exit status.
-status=0
-# "pass: 0" would mean no tests actually ran.
-if grep "pass:.*0" $SHORT_SUMMARY > /dev/null; then
-status=1
-fi
-# Fails or crashes should be failures from make check's perspective.
-if ! grep "fail:.*0" $SHORT_SUMMARY > /dev/null; then
-status=1
-fi
-if ! grep "crash:.*0" $SHORT_SUMMARY > /dev/null; then
-status=1
-fi
-
-if test $status != 0; then
-$PIGLIT_DIR/piglit-summary-html.py \
-   --overwrite \
-   $PIGLIT_RESULTS_DIR/html \
-   $PIGLIT_RESULTS_DIR
+-screen scrn 1280x1024x24"
+export PIGLIT_RESULTS_DIR=$XSERVER_BUILDDIR/test/piglit-results/xvfb
 
-echo "Some piglit tests failed."
-echo "The list of failing tests can be found in $LONG_SUMMARY."
-echo "An html page of the failing tests can be found at 
$PIGLIT_RESULTS_DIR/html/problems.html"
-fi
+exec $XSERVER_DIR/test/scripts/run-piglit.sh
 
-exit $status
-- 
2.9.3

___
xorg-devel@lists.x.org: X.Org development
Archives:

[PATCH xserver v3 06/11] test: Add a little xinit-like program for starting servers for testing.

2016-09-25 Thread Eric Anholt 
The normal xinit is racy because it doesn't use -displayfd.  This
implements the bare minimum for testing purposes, using -displayfd to
sequence starting the client, and avoids adding yet another dependency
to the server.

v2: Fix asprintf error checks.
v3: Add error checking for fork(), clarify calloc() arg.

Signed-off-by: Eric Anholt 
---
 test/.gitignore |   1 +
 test/Makefile.am|  13 ++-
 test/simple-xinit.c | 229 
 3 files changed, 239 insertions(+), 4 deletions(-)
 create mode 100644 test/simple-xinit.c

diff --git a/test/.gitignore b/test/.gitignore
index a62fc3d70651..c44fc827ac13 100644
--- a/test/.gitignore
+++ b/test/.gitignore
@@ -11,5 +11,6 @@ xfree86
 xkb
 xtest
 signal-logging
+simple-xinit
 *.log
 *.trs
diff --git a/test/Makefile.am b/test/Makefile.am
index 4ccadf5b0005..24bfc35bc88a 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -1,17 +1,22 @@
 if ENABLE_UNIT_TESTS
 SUBDIRS= .
-noinst_PROGRAMS = list string
+TEST_PROGS = list string
 if XORG
 # Tests that require at least some DDX functions in order to fully link
 # For now, requires xf86 ddx, could be adjusted to use another
 SUBDIRS += xi1 xi2
-noinst_PROGRAMS += xkb input xtest misc fixes xfree86 signal-logging touch
+TEST_PROGS += xkb input xtest misc fixes xfree86 signal-logging touch
 if RES
-noinst_PROGRAMS += hashtabletest
+TEST_PROGS += hashtabletest
 endif
 endif
 check_LTLIBRARIES = libxservertest.la
 
+noinst_PROGRAMS = \
+   simple-xinit \
+   $(TEST_PROGS) \
+   $(NULL)
+
 if XVFB
 XVFB_TESTS = scripts/xvfb-piglit.sh
 endif
@@ -21,7 +26,7 @@ SCRIPT_TESTS = \
$(NULL)
 
 TESTS = \
-   $(noinst_PROGRAMS) \
+   $(TEST_PROGS) \
$(SCRIPT_TESTS) \
$(NULL)
 
diff --git a/test/simple-xinit.c b/test/simple-xinit.c
new file mode 100644
index ..89189a609c19
--- /dev/null
+++ b/test/simple-xinit.c
@@ -0,0 +1,229 @@
+/*
+ * Copyright © 2016 Broadcom
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifdef HAVE_DIX_CONFIG_H
+#include 
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void
+kill_server(int server_pid)
+{
+int ret = kill(server_pid, SIGTERM);
+int wstatus;
+
+if (ret) {
+fprintf(stderr, "Failed to send kill to the server: %s\n",
+strerror(errno));
+exit(1);
+}
+
+ret = waitpid(server_pid, , 0);
+if (ret < 0) {
+fprintf(stderr, "Failed to wait for X to die: %s\n", strerror(errno));
+exit(1);
+}
+}
+
+static void
+usage(int argc, char **argv)
+{
+fprintf(stderr, "%s  -- \n", argv[0]);
+exit(1);
+}
+
+/* Starts the X server, returning its pid. */
+static int
+start_server(char *const *server_args)
+{
+int server_pid = fork();
+
+if (server_pid == -1) {
+fprintf(stderr, "Fork failed: %s\n", strerror(errno));
+exit(1);
+} else if (server_pid != 0) {
+/* Continue along the main process that will exec the client. */
+return server_pid;
+}
+
+/* Execute the server.  This only returns if an error occurred. */
+execvp(server_args[0], server_args);
+fprintf(stderr, "Error starting the server: %s\n", strerror(errno));
+exit(1);
+}
+
+/* Reads the display number out of the started server's display socket. */
+static int
+get_display(int displayfd)
+{
+char display_string[10];
+ssize_t ret;
+
+ret = read(displayfd, display_string, sizeof(display_string - 1));
+if (ret <= 0) {
+fprintf(stderr, "Failed reading displayfd: %s\n", strerror(errno));
+exit(1);
+}
+
+/* We've read in the display number as a string terminated by
+ * '\n', but not '\0'.  Cap it and parse the number.
+ */
+display_string[ret] = '\0';
+return atoi(display_string);
+}
+
+static int
+start_client(char

[PATCH xserver v3 04/11] ephyr: Add a mode for skipping redisplay in glamor.

2016-09-25 Thread Eric Anholt 
This speeds up headless testing of Xephyr -glamor with softpipe from
"a test per minute or so" to "a test every few seconds".

Signed-off-by: Eric Anholt 
---
 hw/kdrive/ephyr/ephyr_glamor_glx.c | 8 
 hw/kdrive/ephyr/ephyrinit.c| 7 ++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/hw/kdrive/ephyr/ephyr_glamor_glx.c 
b/hw/kdrive/ephyr/ephyr_glamor_glx.c
index 2f219141eccc..007123c31e48 100644
--- a/hw/kdrive/ephyr/ephyr_glamor_glx.c
+++ b/hw/kdrive/ephyr/ephyr_glamor_glx.c
@@ -57,6 +57,7 @@ static Display *dpy;
 static XVisualInfo *visual_info;
 static GLXFBConfig fb_config;
 Bool ephyr_glamor_gles2;
+Bool ephyr_glamor_skip_present;
 /** @} */
 
 /**
@@ -220,6 +221,13 @@ ephyr_glamor_damage_redisplay(struct ephyr_glamor *glamor,
 {
 GLint old_vao;
 
+/* Skip presenting the output in this mode.  Presentation is
+ * expensive, and if we're just running the X Test suite headless,
+ * nobody's watching.
+ */
+if (ephyr_glamor_skip_present)
+return;
+
 glXMakeCurrent(dpy, glamor->glx_win, glamor->ctx);
 
 if (glamor->vao) {
diff --git a/hw/kdrive/ephyr/ephyrinit.c b/hw/kdrive/ephyr/ephyrinit.c
index 149ea981ee4d..7632c2643210 100644
--- a/hw/kdrive/ephyr/ephyrinit.c
+++ b/hw/kdrive/ephyr/ephyrinit.c
@@ -36,7 +36,7 @@ extern Bool EphyrWantResize;
 extern Bool EphyrWantNoHostGrab;
 extern Bool kdHasPointer;
 extern Bool kdHasKbd;
-extern Bool ephyr_glamor, ephyr_glamor_gles2;
+extern Bool ephyr_glamor, ephyr_glamor_gles2, ephyr_glamor_skip_present;
 
 extern Bool ephyrNoXV;
 
@@ -148,6 +148,7 @@ ddxUseMsg(void)
 #ifdef GLAMOR
 ErrorF("-glamor  Enable 2D acceleration using glamor\n");
 ErrorF("-glamor_gles2Enable 2D acceleration using glamor (with 
GLES2 only)\n");
+ErrorF("-glamor-skip-present Skip presenting the output when using glamor 
(for internal testing optimization)\n");
 #endif
 ErrorF
 ("-fakexa  Simulate acceleration using software 
rendering\n");
@@ -288,6 +289,10 @@ ddxProcessArgument(int argc, char **argv, int i)
 ephyrFuncs.finiAccel = ephyr_glamor_fini;
 return 1;
 }
+else if (!strcmp (argv[i], "-glamor-skip-present")) {
+ephyr_glamor_skip_present = TRUE;
+return 1;
+}
 #endif
 else if (!strcmp(argv[i], "-fakexa")) {
 ephyrFuncs.initAccel = ephyrDrawInit;
-- 
2.9.3

___
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 xserver v3 10/11] test: Switch our testing X server to being spawned with simple-xinit.

2016-09-25 Thread Eric Anholt 
Once I introduced a second X server being tested, I found that startx
hit races in choosing a display.

Signed-off-by: Eric Anholt 
---
 test/scripts/run-piglit.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/scripts/run-piglit.sh b/test/scripts/run-piglit.sh
index 3623a05c17fd..b999c259811a 100755
--- a/test/scripts/run-piglit.sh
+++ b/test/scripts/run-piglit.sh
@@ -38,7 +38,7 @@ if test "x$SERVER_COMMAND" = "x"; then
 exit 1
 fi
 
-startx \
+$XSERVER_BUILDDIR/test/simple-xinit \
 $XSERVER_DIR/test/scripts/xinit-piglit-session.sh \
 -- \
 $SERVER_COMMAND
-- 
2.9.3

___
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 xserver v3 08/11] test: Fix parsing of piglit results.

2016-09-25 Thread Eric Anholt 
The "dmesg-fail" line was matching our "fail" regex, so if you didn't
have those we would ignore fails.

Signed-off-by: Eric Anholt 
---
 test/scripts/run-piglit.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/test/scripts/run-piglit.sh b/test/scripts/run-piglit.sh
index 11e9c1eb9883..c412d7ee70af 100755
--- a/test/scripts/run-piglit.sh
+++ b/test/scripts/run-piglit.sh
@@ -55,14 +55,14 @@ cat $SHORT_SUMMARY
 # Parse the piglit summary to decide on our exit status.
 status=0
 # "pass: 0" would mean no tests actually ran.
-if grep "pass:.*0" $SHORT_SUMMARY > /dev/null; then
+if grep "^ *pass: *0$" $SHORT_SUMMARY > /dev/null; then
 status=1
 fi
 # Fails or crashes should be failures from make check's perspective.
-if ! grep "fail:.*0" $SHORT_SUMMARY > /dev/null; then
+if ! grep "^ *fail: *0$" $SHORT_SUMMARY > /dev/null; then
 status=1
 fi
-if ! grep "crash:.*0" $SHORT_SUMMARY > /dev/null; then
+if ! grep "^ *crash: *0$" $SHORT_SUMMARY > /dev/null; then
 status=1
 fi
 
-- 
2.9.3

___
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 xserver v3 09/11] test: Update piglit HTML even when tests all pass.

2016-09-25 Thread Eric Anholt 
I was confused by the behavior I'd written before.  keithp and
mattst88 responded with shock that I would have made it so surprising,
as well.

v2: Point to index.html instead of problems.html, which won't exist if
we had no problems.

Signed-off-by: Eric Anholt 
---
 test/scripts/run-piglit.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/test/scripts/run-piglit.sh b/test/scripts/run-piglit.sh
index c412d7ee70af..3623a05c17fd 100755
--- a/test/scripts/run-piglit.sh
+++ b/test/scripts/run-piglit.sh
@@ -66,15 +66,15 @@ if ! grep "^ *crash: *0$" $SHORT_SUMMARY > /dev/null; then
 status=1
 fi
 
-if test $status != 0; then
-$PIGLIT_DIR/piglit-summary-html.py \
+$PIGLIT_DIR/piglit-summary-html.py \
--overwrite \
$PIGLIT_RESULTS_DIR/html \
$PIGLIT_RESULTS_DIR
 
+if test $status != 0; then
 echo "Some piglit tests failed."
 echo "The list of failing tests can be found in $LONG_SUMMARY."
-echo "An html page of the failing tests can be found at 
$PIGLIT_RESULTS_DIR/html/problems.html"
 fi
+echo "An html page of the test status can be found at 
$PIGLIT_RESULTS_DIR/html/index.html"
 
 exit $status
-- 
2.9.3

___
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 xserver v3 11/11] test: Run xts against Xephyr -glamor when present.

2016-09-25 Thread Eric Anholt 
v2: Drop x8r8g8b8 skip, now that it's fixed.

Signed-off-by: Eric Anholt 
---
 test/Makefile.am |  6 ++
 test/scripts/xephyr-glamor-piglit.sh | 16 
 2 files changed, 22 insertions(+)
 create mode 100755 test/scripts/xephyr-glamor-piglit.sh

diff --git a/test/Makefile.am b/test/Makefile.am
index cf19beca96ff..c89915c41348 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -19,10 +19,16 @@ noinst_PROGRAMS = \
 
 if XVFB
 XVFB_TESTS = scripts/xvfb-piglit.sh
+if XEPHYR
+if GLAMOR
+XEPHYR_GLAMOR_TESTS = scripts/xephyr-glamor-piglit.sh
+endif
+endif
 endif
 
 SCRIPT_TESTS = \
$(XVFB_TESTS) \
+   $(XEPHYR_GLAMOR_TESTS) \
$(NULL)
 
 TESTS = \
diff --git a/test/scripts/xephyr-glamor-piglit.sh 
b/test/scripts/xephyr-glamor-piglit.sh
new file mode 100755
index ..51d42c313643
--- /dev/null
+++ b/test/scripts/xephyr-glamor-piglit.sh
@@ -0,0 +1,16 @@
+# Start a Xephyr server using glamor.  Since the test environment is
+# headless, we start an Xvfb first to host the Xephyr.
+export PIGLIT_RESULTS_DIR=$XSERVER_BUILDDIR/test/piglit-results/xephyr-glamor
+
+export SERVER_COMMAND="$XSERVER_BUILDDIR/hw/kdrive/ephyr/Xephyr \
+-glamor \
+-glamor-skip-present \
+-noreset \
+-schedMax 2000 \
+-screen 1280x1024"
+
+$XSERVER_BUILDDIR/test/simple-xinit \
+$XSERVER_DIR/test/scripts/run-piglit.sh \
+-- \
+$XSERVER_BUILDDIR/hw/vfb/Xvfb \
+-screen scrn 1280x1024x24
-- 
2.9.3

___
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

Damage as a DIX notion

2016-09-25 Thread "Keith Packard" 

Adam, Eric and I were chatting at XDC about how to make damage
computations more efficient and more useful.

The impetus of this was that glamor on tilers would like to have the
bounds of every operation to reduce the number of tiles processed for
small operations. Damage already computes the bounds of every operation,
but that bounds is not available to glamor. Re-computing the bounds
would be wasteful, so instead we want to capture the computation done
(potentially) by damage instead of redoing it.

I've taken a couple of stabs at a design, and I figured I'd share my
current ideas to get some feedback.

First off, I think I need a set of bounds computing functions, one per
rendering operation. I've started writing these to compute a simple
bounding box for an entire operation. This may be larger than what
Damage currently computes, but I don't think a closer bounds is
interesting for most operations.

Next, I think we just want to pass any computed bounds along with the
rendering operation. This means tacking on another argument to all of
them. A NULL value means that no bounds have been computed yet.

Finally, each element in the stack which needs the operation bounds will
have a local BoxRec to hold a bounds, and then call the
operation-specific bounds function, which will either use the existing
bounds (if non-NULL), or fill in the local BoxRec and return that.

Here's a sample of these new functions:

BoxPtr
bounds_poly_point(DrawablePtr drawable,
  GCPtr gc,
  int npoint,
  const xPoint *points,
  BoxPtr bounds,
  BoxPtr local_bounds)
{
int i;

/* Are the operation bounds already computed? */
if (bounds != NULL)
return bounds;

/* Compute bounds of this operation */
bounds = local_bounds;
if (npoint == 0) {
*bounds = bounds_empty();
return bounds;
}

open_rect_to_box(bounds, points[0].x, points[0].y, 1, 1);
for (i = 1; i < npoint; i++)
open_rect_union(bounds, bounds, points[i].x, points[i].y, 1, 1);
bounds_trim_gc(drawable, gc, bounds);
return bounds;
}

Here's how the Damage layer uses this:

static void
damagePolyPoint(DrawablePtr pDrawable,
GCPtr pGC, int npt, const xPoint * ppt,
BoxPtr bounds)
{
BoxRec local_bounds;
DAMAGE_GC_OP_PROLOGUE(pGC, pDrawable);

if (checkGCDamage(pDamage, pGC)) {
bounds = bounds_poly_point(pDrawable, pGC, npt, ppt, bounds, 
_bounds);
if (!bounds_is_empty(bounds))
damageDamageRelBox(pDrawable, bounds, pGC->subWindowMode);
}
(*pGC->ops->PolyPoint) (pDrawable, pGC, npt, ppt, bounds);
damageRegionProcessPending(pDamage);
DAMAGE_GC_OP_EPILOGUE(pGC, pDrawable);
}

We can obviously change the internals of Damage so that we just pass the
damage box to damageRegionProcessPending; that will greatly simplify the
internals of that code.

Now, down in glamor, we can do the same thing to compute the bounds as
needed. Here's how a glamor fallback works:

static void
glamor_poly_fill_rect_bail(DrawablePtr drawable,
   GCPtr gc, int nrect, const xRectangle *prect,
   BoxPtr bounds)
{
BoxRec local_bounds;

glamor_fallback("to %p (%c)\n", drawable,
glamor_get_drawable_location(drawable));
bounds = bounds_poly_fill_rect(drawable, gc, nrect, prect, bounds, 
_bounds);
if (glamor_prepare_access_box(drawable, GLAMOR_ACCESS_RW, bounds) &&
glamor_prepare_access_gc(gc))
{
fbPolyFillRect(drawable, gc, nrect, prect, bounds);
}
glamor_finish_access_gc(gc);
glamor_finish_access(drawable);
}

If Damage has already computed the bounds of the operation, then glamor
can re-use that value. Otherwise, it will compute the bounds itself to
reduce the amount of data shuffled.

I've written just a smattering of the code as I'm assuming we'll improve
this design and probably end up replacing all of the code. I had
initially thought that we'd want to take advantage of the patches I've
sent around which make the rendering data immutable, but that isn't
necessary for this design.

The current design has one serious problem, and I don't have a solution
in mind yet. When you draw something that is implemented in terms of
other drawing operations (like mi lines/points/arcs etc), and if Damage
isn't being tracked on the drawable, then the bounds are never computed
for the higher-level operation, and instead you end

[PATCH xserver] xace: Don't censor window borders

2016-09-25 Thread Keith Packard 
GetImage is allowed to return window border contents, so don't remove
that from the returned image.

Signed-off-by: Keith Packard 
---
 Xext/xace.c| 13 ++---
 dix/dispatch.c | 10 ++
 2 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/Xext/xace.c b/Xext/xace.c
index a3a83a2..f8f8d13 100644
--- a/Xext/xace.c
+++ b/Xext/xace.c
@@ -236,16 +236,15 @@ XaceCensorImage(ClientPtr client,
 BoxRec imageBox;
 int nRects;
 
-imageBox.x1 = x;
-imageBox.y1 = y;
-imageBox.x2 = x + w;
-imageBox.y2 = y + h;
+imageBox.x1 = pDraw->x + x;
+imageBox.y1 = pDraw->y + y;
+imageBox.x2 = pDraw->x + x + w;
+imageBox.y2 = pDraw->y + y + h;
 RegionInit(, , 1);
 RegionNull();
 
 /* censorRegion = imageRegion - visibleRegion */
 RegionSubtract(, , pVisibleRegion);
-RegionTranslate(, -x, -y);
 nRects = RegionNumRects();
 if (nRects > 0) {   /* we have something to censor */
 GCPtr pScratchGC = NULL;
@@ -265,8 +264,8 @@ XaceCensorImage(ClientPtr client,
 goto failSafe;
 }
 for (pBox = RegionRects(), i = 0; i < nRects; i++, 
pBox++) {
-pRects[i].x = pBox->x1;
-pRects[i].y = pBox->y1;
+pRects[i].x = pBox->x1 - imageBox.x1;
+pRects[i].y = pBox->y1 - imageBox.y1;
 pRects[i].width = pBox->x2 - pBox->x1;
 pRects[i].height = pBox->y2 - pBox->y1;
 }
diff --git a/dix/dispatch.c b/dix/dispatch.c
index adcc9cf..e111377 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -2187,12 +2187,8 @@ DoGetImage(ClientPtr client, int format, Drawable 
drawable,
 return BadAlloc;
 WriteReplyToClient(client, sizeof(xGetImageReply), );
 
-if (pDraw->type == DRAWABLE_WINDOW) {
-pVisibleRegion = NotClippedByChildren((WindowPtr) pDraw);
-if (pVisibleRegion) {
-RegionTranslate(pVisibleRegion, -pDraw->x, -pDraw->y);
-}
-}
+if (pDraw->type == DRAWABLE_WINDOW)
+pVisibleRegion = &((WindowPtr) pDraw)->borderClip;
 
 if (linesPerBuf == 0) {
 /* nothing to do */
@@ -2251,8 +2247,6 @@ DoGetImage(ClientPtr client, int format, Drawable 
drawable,
 }
 }
 }
-if (pVisibleRegion)
-RegionDestroy(pVisibleRegion);
 free(pBuf);
 return Success;
 }
-- 
2.9.3

___
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 xserver] test: Add a helper script for testing glamor on a hardware driver.

2016-09-25 Thread Eric Anholt 
I don't think we can integrate this with make check, and I'd rather
work on a modesetting-driver-as-headless-testing-environment series
for long term testing of glamor on hardware drivers.  Until then, this
should help driver developers get testing done of glamor on their
chip.

On my Skylake, this takes 12 minutes to run the test suite.

Signed-off-by: Eric Anholt 
---

This is a followup patch to my previous testing series.

 test/Makefile.am  |  1 +
 test/scripts/xephyr-glamor-on-host.sh | 12 
 2 files changed, 13 insertions(+)
 create mode 100755 test/scripts/xephyr-glamor-on-host.sh

diff --git a/test/Makefile.am b/test/Makefile.am
index c89915c41348..ae6595050b37 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -170,6 +170,7 @@ EXTRA_DIST = \
$(SCRIPT_TESTS) \
scripts/xinit-piglit-session.sh \
scripts/run-piglit.sh \
+   scripts/xephyr-glamor-on-host.sh \
ddxstubs.c \
$(NULL)
 
diff --git a/test/scripts/xephyr-glamor-on-host.sh 
b/test/scripts/xephyr-glamor-on-host.sh
new file mode 100755
index ..f3669bebfd79
--- /dev/null
+++ b/test/scripts/xephyr-glamor-on-host.sh
@@ -0,0 +1,12 @@
+# Start a Xephyr server using glamor.  This assumes that you have an
+# existing X Server to host the Xephyr -glamor instance.
+export 
PIGLIT_RESULTS_DIR=$XSERVER_BUILDDIR/test/piglit-results/host-xephyr-glamor
+
+export SERVER_COMMAND="$XSERVER_BUILDDIR/hw/kdrive/ephyr/Xephyr \
+-glamor \
+-glamor-skip-present \
+-noreset \
+-schedMax 2000 \
+-screen 1280x1024"
+
+exec $XSERVER_DIR/test/scripts/run-piglit.sh
-- 
2.9.3

___
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

Re: [PATCH xserver 02/10 v2] glamor: Require that 16bpp pixmap depths match for Render copies.

2016-09-25 Thread Eric Anholt 
Michel Dänzer  writes:

> On 23/09/16 09:51 PM, Eric Anholt wrote:
>> Michel Dänzer  writes:
>>> On 23/09/16 04:57 PM, Eric Anholt wrote:
 The copy optimization in d37329cba42fa8e72fe4be8a7be18e512268b5bd
 replicated a bug from last time we did a copy optimization, and didn't
 get rendercheck run on it.
>>>
>>> Actually, I'm pretty sure I did run rendercheck, but didn't notice the
>>> regression due to the radeonsi bug affecting the same test. Please
>>> consider removing that language from the commit log.
>> 
>> OK.  I'll drop the comment about running rendercheck.
>
> Thanks.
>
>
>> We do need some concerted effort on actually fixing our rendering bugs
>> and reenabling the skipped tests.  I've spent a while trying to come up
>> with why the remaining rendercheck test fails and come up with nothing
>> yet.
>
> How can others help with this?

I fixed the remaining glamor-specific case in the scripts on the plane.
Now we're down to:

# Skip some tests that are failing at the time of importing the script.
#"REPORT: min_bounds, rbearing was 0, expecting 2"
PIGLIT_ARGS="$PIGLIT_ARGS -x xlistfontswithinfo@3"
PIGLIT_ARGS="$PIGLIT_ARGS -x xlistfontswithinfo@4"
PIGLIT_ARGS="$PIGLIT_ARGS -x xloadqueryfont@1"
PIGLIT_ARGS="$PIGLIT_ARGS -x xqueryfont@1"
PIGLIT_ARGS="$PIGLIT_ARGS -x xqueryfont@2"
#"REPORT: Incorrect pixel on inside of area at point (0, 0): 0x0 != 0x1"
PIGLIT_ARGS="$PIGLIT_ARGS -x xgetimage@7"
PIGLIT_ARGS="$PIGLIT_ARGS -x xgetsubimage@7"

in the current XTS set across fb and glamor/llvmpipe.  XGetImage/7 seems
to be BadMatching.  I have no idea about the font thing, but it doesn't
seem too rendering-related either.

So, at this point, I think it's up to us to go bang on our hardware 3D
drivers to make sure that they're rendering glamor correctly.  Sending
out a script to make that easier, even if we're not going to put it in
make check.

For i965, I'm seeing failures in:

rendercheck/blend/over:

Beginning blend test on a4r4g4b4
Over blend test error of 15. at (0, 0) --
   R G B A
got:   0.000 0.000 0.000 0.000
expected:  0.000 0.000 0.000 1.000
src color: 0.00 0.00 0.00 1.00 (a8)
dst color: 0.00 0.00 0.00 1.00
src: 1x1R a8, dst: a4r4g4b4
Beginning blend test on a4b4g4r4
Over blend test error of 15. at (0, 0) --
   R G B A
got:   0.000 0.000 0.000 0.000
expected:  0.000 0.000 0.000 1.000
src color: 0.00 0.00 0.00 1.00 (a8)
dst color: 0.00 0.00 0.00 1.00
src: 1x1R a8, dst: a4b4g4r4

and rendercheck/blend/src:

Beginning blend test on b8g8r8a8
Src blend test error of 255. at (0, 0) --
   R G B A
got:   0.000 0.000 0.000 0.000
expected:  0.000 0.000 0.000 1.000
src color: 0.00 0.00 0.00 1.00 (a8)
dst color: 0.00 0.00 0.00 1.00
src: 1x1R a8, dst: b8g8r8a8

Beginning blend test on a4r4g4b4
Src blend test error of 15. at (0, 0) --
   R G B A
got:   0.000 0.000 0.000 0.000
expected:  0.000 0.000 0.000 1.000
src color: 0.00 0.00 0.00 1.00 (a8)
dst color: 0.00 0.00 0.00 1.00
src: 1x1R a8, dst: a4r4g4b4
Beginning blend test on a4b4g4r4
Src blend test error of 15. at (0, 0) --
   R G B A
got:   0.000 0.000 0.000 0.000
expected:  0.000 0.000 0.000 1.000
src color: 0.00 0.00 0.00 1.00 (a8)
dst color: 0.00 0.00 0.00 1.00
src: 1x1R a8, dst: a4b4g4r4

and rendercheck/cacomposite/all/a8:

Ignoring server-supported format: x2b10g10r10
Beginning composite CA mask test on a8
Saturate CA composite test error of 128. at (0, 0) --
   R G B A
got:   0.000 0.000 0.000 0.498
expected:  0.000 0.000 0.000 1.000
src color: 0.00 0.00 0.00 1.00
msk color: 0.00 0.00 0.00 0.50
dst color: 0.00 0.00 0.00 1.00
src: 1x1R a8, mask: 1x1R a8, dst: a8
Beginning composite CA mask test on a8r8g8b8
DisjointIn CA composite test error of 255. at (0, 0) --
   R G B A
got:   0.000 0.000 0.000 0.000
expected:  0.000 0.000 0.000 1.000
src color: 0.00 0.00 0.00 1.00
msk color: 0.00 0.00 0.00 1.00
dst color: 0.00 0.00 0.00 1.00

and rendercheck/triangles:

Beginning Dst Triangles test on a8
triangles test error of 255. at (0, 0) --
   R G B A
got:   0.000 0.000 0.000 0.000
expected:  0.000 0.000 0.000 1.000
...


signature.asc
Description: PGP signature
___
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

Re: [PATCH 1/2] glamor: Add GLAMOR_ACCESS_WO

2016-09-25 Thread Eric Anholt 
Michel Dänzer  writes:

> Adding Marek and Nicolai, maybe they have some feedback from a GL
> (driver) perspective.
>
>
> On 23/08/16 10:41 AM, Dave Airlie wrote:
>> From: Michel Dänzer 
>> 
>> [airlied: rebased onto master -
>> I left WO alone as it's more like the GL interface
>> review suggested changing it to bits.]
>
> After realizing that patch 2 can only affect the !ZPixmap case, I tested
> this series with
>
>  x11perf -putimagexy{10,100,500} -shmputxy{10,100,500}
>
> and to my surprise, all of the numbers went down by around an order of
> magnitude (using radeonsi on Kaveri). I investigated a little bit what's
> going on:

I should have replied before.  Based on the performance numbers, I've
considered these patches rejected.


signature.asc
Description: PGP signature
___
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

Re: 2 patches for glamor on OpenBSD (without DRI3/XSHM_FENCE)

2016-09-25 Thread Eric Anholt 
Matthieu Herrb  writes:

> On Fri, Sep 23, 2016 at 04:45:37PM +0300, Hans de Goede wrote:
>> Hi,
>> 
>> On 09/23/2016 04:33 PM, Matthieu Herrb wrote:
>> > Hi
>> > 
>> > Adam, Keith, any chance to get those 2 patches merged for 1.19 ?
>> > It would reduce the number of local patches I'm maintaining outside of
>> > os/os-support.
>> > 
>> > https://patchwork.freedesktop.org/patch/64866/
>> > https://patchwork.freedesktop.org/patch/65081/
>> 
>> Both links seem to point to post + re-post of
>> the same patch, so I see only 1 patch?
>
> You're right. Sorry I mixed up my cut/paste the 2nd one is
>
> https://patchwork.freedesktop.org/patch/65444/
>
> But it could be without the renaming. so just:
>
> Make glamor_name_from_pixmap work without DRI3
>
> This function is used by the modesetting driver to implement DRI2 and
> shouldn't fail on systems that don't support DRI3.  Remove the check
> for DRI3 and rename glamor_egl_dri3_fd_name_from_tex to
> glamor_egl_fd_name_from_tex.

Updated commit message wording and fixed the warning:

commit 8bb4b11298c285d2cd1eb28e65729933ec386829
Author: Matthieu Herrb 
Date:   Fri Sep 23 16:56:06 2016 +0300

glamor: Make glamor_name_from_pixmap work without DRI3

This function is used by the modesetting driver to implement DRI2 and
shouldn't fail on systems that don't support DRI3.

v2: Drop stale commit message wording, fix compiler warning (by anholt)

Signed-off-by: Eric Anholt 
Reviewed-by: Eric Anholt 

and merged:
To git+ssh://git.freedesktop.org/git/xorg/xserver
   128d40b2dd0a..ba199cb90157  HEAD -> master


signature.asc
Description: PGP signature
___
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

Re: [PATCH 05/18] glamor: fix spelling mistakes

2016-09-25 Thread Eric Anholt 
Adam Jackson  writes:

> On Sat, 2016-04-02 at 19:53 +0100, Eric Engestrom wrote:
>
>> -   the orginal slope and the slope which is vertical to it will not 
>> be correct. */
>> +   the orignal slope and the slope which is vertical to it will not 
>> be correct. */
>
> "Original".
>
> - ajax

Fixed that and merged:
   ade315386cee..128d40b2dd0a  HEAD -> master


signature.asc
Description: PGP signature
___
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 xserver] glamor: Properly handle mask formats without alpha.

2016-09-25 Thread Eric Anholt 
Even if the pixmap's storage has alpha, it may have been uploaded with
garbage in the alpha channel, so we need to force the shader to set
alpha to 1.  This was broken way back in
355334fcd99e4dce62e2be1e27290c9a74ea944f.

Fixes rendercheck -t composite -f x8r8g8b8.

Signed-off-by: Eric Anholt 
---
 glamor/glamor_render.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index b5903acb20c2..f2ef08316410 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -868,7 +868,10 @@ glamor_composite_choose_shader(CARD8 op,
 goto fail;
 }
 else {
-key.mask = SHADER_MASK_TEXTURE_ALPHA;
+if (PICT_FORMAT_A(mask->format))
+key.mask = SHADER_MASK_TEXTURE_ALPHA;
+else
+key.mask = SHADER_MASK_TEXTURE;
 }
 
 if (!mask->componentAlpha) {
-- 
2.9.3

___
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

Re: [PATCH] remove dead code in dummy driver

2016-09-25 Thread Bob Terek 


On 09/23/2016 07:20 AM, Aaron Plattner wrote:


On 09/22/2016 04:30 PM, Bob Terek wrote:



Shouldn't the first 5 of Aaron's patches be applied, since they are all
cleanup items?

https://lists.x.org/archives/xorg-devel/2015-January/045395.html


I never pushed them because they were never reviewed. Would it help if I
resent them?


Why don't you hold off for a bit. . .



Patch 6 supposedly caused a server crash, but the first 5 should be ok?


Patch 6 was kind of controversial so I don't know if we want it anyway.


Welp, on that topic, your patch 6 was an alternative approach to support 
arbitrary pixel dimensions for the framebuffer. The more conventional 
approach had been posted by Boichat, 
https://lists.x.org/archives/xorg-devel/2014-November/044580.html . I'd 
like to suggest that Boichat's approach be used, but extended even further:


In 2014 I had also modified the dummy driver while working with Teradici 
Corporation to support not only arbitrary pixel dimensions, but also 
multiple monitors. The latter feature might not make sense to some 
folks, but if you have a server-side Xserver mapped to a hardware thin 
client sitting across a network, which has multiple physical monitors 
attached, you want the Xserver to be configured in the exact same manner 
as the tin client. Even though there is just a virtual framebuffer in 
main memory, X applications need to know the number/size/location of 
monitors so that toolbars are placed properly, windows are fullscreen'ed 
properly, etc. And when the user moves from one hardware thin client to 
another, which may have a different monitor configuration, the Xserver 
session needs to change to that configuration.


At Teradici we made dummy be RandR 1.2 compliant in a manner similar to 
Boichat, but added xorg.conf parameters to specify how many CRTC/Outputs 
should be created at startup. Thus the configuration could be 
manipulated via the standard RandR API (either programatically or 
through the xrandr command). This might happen when the hardware thin 
client connects to an existing X session, and server-side session 
management software will issue what is needed to reconfigure the 
Xserver. The end result is that the hardware thin client could be 
supported by multiple CRTC/Output's, with typical VESA modes, but a 
software thin client could use arbitrary pixel dimensions on a single 
CRTC/Output to map exactly the size of the window it was running in.


Teradici and I would like to submit these patches to dummy to support 
the functionality that many want. The dummy driver is so simple that I 
don't see this as overly complex. Yes, it is a bit more code to add, but 
it is very straightforward, nothing at all surprising. And it is 
backwards compatible, the multiple CRTC/Output support does not have to 
be utilized, the default is 1. Our modified driver behaves just like the 
current one, except that arbitrary modes may be added and switched to 
via the RandR protocol.


I can post these patches, and include Aaron's cleanups, if folks will 
support this approach. It has been tested via Teradici for over a year 
and seems to be stable. I am in the process of updating the code to the 
current version and so far so good.


Thoughts?

Thanks,

Bob Terek
___
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

Re: [PATCH xserver 2/2] Eliminate coordinate mode in PolyPoint, PolyLines and FillPolygon ops

2016-09-25 Thread Adam Jackson 
On Sat, 2016-09-24 at 05:09 +0300, Keith Packard wrote:
> > Adam Jackson  writes:
> 
> > You want to make this non-static, so in the xinerama case you can do
> > this translation once at the top level.
> 
> 
> ...
> 
> > You're not correcting stuff->coordMode in place, which means under
> > xinerama you'll mutate geometry once per screen, which ain't right.
> 
> 
> These seem in conflict to me -- if we have xinerama do the transform
> once and smash stuff->coordMode, it seems like we're done, right?

Not really in conflict, just both true. If PanoramiXPolyPoint does the
transform and smashes coordMode, then ProcPolyPoint wouldn't need to
_also_ do it when xinerama is active. But it does need to do the fixup
for the (normal) case where xinerama isn't active. (Please don't key
off !noPanoramiXExtension, I'd like to be able to meaningfully test
xinerama with just one ScreenRec.)

Strictly you could fix up just once in ProcPolyPoint if you also fixed
up coordMode, but doing the fixup in xin would get us closer to being
able to do thread-per-GPU for xinerama, which might be nice.

- ajax
___
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

Re: [PATCH xserver 02/10 v2] glamor: Require that 16bpp pixmap depths match for Render copies.

2016-09-25 Thread Michel Dänzer 
On 23/09/16 09:51 PM, Eric Anholt wrote:
> Michel Dänzer  writes:
>> On 23/09/16 04:57 PM, Eric Anholt wrote:
>>> The copy optimization in d37329cba42fa8e72fe4be8a7be18e512268b5bd
>>> replicated a bug from last time we did a copy optimization, and didn't
>>> get rendercheck run on it.
>>
>> Actually, I'm pretty sure I did run rendercheck, but didn't notice the
>> regression due to the radeonsi bug affecting the same test. Please
>> consider removing that language from the commit log.
> 
> OK.  I'll drop the comment about running rendercheck.

Thanks.


> We do need some concerted effort on actually fixing our rendering bugs
> and reenabling the skipped tests.  I've spent a while trying to come up
> with why the remaining rendercheck test fails and come up with nothing
> yet.

How can others help with this?


>>> This is effectively a re-cherry-pick of 
>>> 510c8605641803f1f5b5d2de6d3bb422b148e0e7.
>>>
>>> Fixes rendercheck -t blend -o src -f x4r4g4b4,x3r4g4b4
>>>
>>> v2: Drop excessive src->depth == dst->depth check that snuck in.
>>>
>>> Signed-off-by: Eric Anholt 
>>> ---
>>>
>>> Michel, I didn't apply your review becuase you said "second clause",
>>> but I removed the first of the two.
>>
>> Is there any case where the drawable depths don't match, but a copy does
>> what's expected?
> 
> I asked keithp, and he agreed that CopyArea may not be used to copy
> between depths.  Render is totally defined across depths, though.

Right, which is why I thought the first clause was necessary and the
second one redundant.

(I suspect some cases such as copying between depth 24 and 32 may work
out correctly, but it's probably better to use a whitelist approach for
those rather than a blacklist for all cases which don't work correctly)


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital signature
___
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

Re: [xserver, 2/2] xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error

2016-09-25 Thread Michel Dänzer 
On 23/09/16 07:48 PM, Hans de Goede wrote:
> On 09/23/2016 11:13 AM, Michel Dänzer wrote:
>> On 23/09/16 03:46 PM, Hans de Goede wrote:
>>>
>>> Since this is a fallback which ideally should never get used (all
>>> drivers should call xf86HandleColormaps) I believe it is not worth
>>> the time to implement your (admittedly better) fallback suggestion.
>>
>> Fine with me, but please at least change the comment to be more accurate
>> and clearer.
> 
> OK, the comment now reads:
> /*
>  * Compatibility pScrn->ChangeGamma provider for ddx drivers which do
> not call
>  * xf86HandleColormaps(). Note such drivers really should be fixed to call
>  * xf86HandleColormaps() as this clobbers any per-crtc setup.
>  */

As I mentioned before, "clobbers any per-CRTC setup" isn't accurate.
Only the gamma ramp of the CRTC assigned to the RandR compatibility
output is clobbered.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
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