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

[Alex Goins]

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 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c
index da2b181..5e99526 100644
--- a/hw/xfree86/ramdac/xf86HWCurs.c
+++ b/hw/xfree86/ramdac/xf86HWCurs.c
@@ -148,7 +148,8 @@ xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor, 
xf86CursorInfoPtr infoPtr
 continue;
 
 sPriv = dixLookupPrivate(>devPrivates, xf86CursorScreenKey);
-if (!xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr))
+if (!sPriv ||
+!xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr))
 return FALSE;
 }
 return TRUE;
-- 
1.9.1

___
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] configure.ac: bump epoxy requirement to 1.2

[Matt Turner]

On Mon, Oct 24, 2016 at 2:39 AM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> As pointed out in the ABI tracker[1], epoxy has gone through a few
> non-backwards compatible ABI changes, yet preserved the DSO name.
>
> Most noticeable of which, from xserver POV, in epoxy_has_egl_extension()
> - s/EGLDisplay */EGLDisplay/.
>
> To avoid unwanted/unexpected 'fun' behaviour, just bump the requirement.
> Version 1.2 has been released more than 2 years ago, in May 2014.
>
> [1] https://abi-laboratory.pro/tracker/timeline/libepoxy/
> Cc: Eric Anholt 
> Cc: Dave Airlie 
> Signed-off-by: Emil Velikov 
> ---
> We might want this in the stable branch(es)?
>
> Eric, iirc Dave had some ideas about moving libepoxy to fd.o [+ making
> it the canonical/upstream source] and was looking for your blessing.
>
> How is that going ? The state of the github repo looks tragic.

ajax and anholt were talking about epoxy's status at XDC. Cc'ing 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 rendercheck] Report results on a per-test basis

[Martin Peres]

On 21/10/16 19:18, Eric Anholt wrote:

Martin Peres  writes:


This allows a runner such as EzBench to track each test individually
and not limit the resolution to groups.

This feature can be triggered by using the -r parameter.


I don't really see the point of this -- you need an external runner to
be choosing a specific test subset to run per rendercheck call, since
the full matrix of composite tests is too long.  Once you have an
external runner calling rendercheck per test group, all you would be
able to do using this patch would be save a few spawns of the process,
which doesn't seem worth it.


Just to be sure, are you suggesting I do something like this instead?

for format in "a8r8g8b8 x8r8g8b8 ... more formats"; do
./rendercheck -f $format
	# parse the successful groups and store them, prefixed by $format so as 
I can identify regressions per format?

done

if so, then I agree that this will work for some groups of tests but not 
the ones trying the different combinations of formats, such as :


## ConjointXor linear gradient dst=a8r8g8b8, src=(1x1R a8r8g8b8, 
1.00:1.00:1.00:1.00): pass
## ConjointXor linear gradient dst=a8r8g8b8, src=(1x1R x8r8g8b8, 
1.00:1.00:1.00:1.00): pass


or the ones that do multiple sub-tests, like:

## Src Triangles a8r8g8b8: pass
## Src TriStrip a8r8g8b8: pass
## Src TriFan a8r8g8b8: pass

Indeed, I would like to know with the smallest granularity possible what 
are the results for all the sub-tests so as I can bisect as many changes 
possible instead of bisecting to the first change that broke the group 
of tests, having a double for-loop to go through all the combination of 
composite tests is orthogonal to this problem.


This was useful for me to bisect a kernel change that broke rendering 
with glamor. It would have had had less chances of succeeding without 
this patch because multiple changes might have happened.


Anyway, don't you think this is also nice from a developer perspective 
to know what test(s) actually broke in a group, instead of having to 
download rendercheck's source, patch it to add debug printfs, recompile 
and re-run? Given how piglit works and how devs love sub-tests, I think 
I am not the only one here.


Martin
___
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] configure.ac: bump epoxy requirement to 1.2

[Emil Velikov]

From: Emil Velikov 

As pointed out in the ABI tracker[1], epoxy has gone through a few
non-backwards compatible ABI changes, yet preserved the DSO name.

Most noticeable of which, from xserver POV, in epoxy_has_egl_extension()
- s/EGLDisplay */EGLDisplay/.

To avoid unwanted/unexpected 'fun' behaviour, just bump the requirement.
Version 1.2 has been released more than 2 years ago, in May 2014.

[1] https://abi-laboratory.pro/tracker/timeline/libepoxy/
Cc: Eric Anholt 
Cc: Dave Airlie 
Signed-off-by: Emil Velikov 
---
We might want this in the stable branch(es)?

Eric, iirc Dave had some ideas about moving libepoxy to fd.o [+ making
it the canonical/upstream source] and was looking for your blessing.

How is that going ? The state of the github repo looks tragic.
---
 configure.ac | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 2e35abf..2aa8c85 100644
--- a/configure.ac
+++ b/configure.ac
@@ -828,6 +828,7 @@ LIBDMX="dmx >= 1.0.99.1"
 LIBDRI="dri >= 7.8.0"
 LIBDRM="libdrm >= 2.3.1"
 LIBEGL="egl"
+LIBEPOXY="epoxy >= 1.2"
 LIBGBM="gbm >= 10.2.0"
 LIBGL="gl >= 7.1.0"
 LIBXEXT="xext >= 1.0.99.4"
@@ -2150,7 +2151,7 @@ AM_CONDITIONAL([GLAMOR], [test "x$GLAMOR" = xyes])
 
 if test "x$GLAMOR" = xyes; then
AC_DEFINE(GLAMOR, 1, [Build glamor])
-   PKG_CHECK_MODULES([GLAMOR], [epoxy])
+   PKG_CHECK_MODULES([GLAMOR], [$LIBEPOXY])
 
PKG_CHECK_MODULES(GBM, "$LIBGBM", [GBM=yes], [GBM=no])
if test "x$GBM" = xyes; then
@@ -2503,7 +2504,7 @@ AM_CONDITIONAL(XFAKESERVER, [test "x$KDRIVE" = xyes && 
test "x$XFAKE" = xyes])
 
 dnl Xwayland DDX
 
-XWAYLANDMODULES="wayland-client >= 1.3.0 $LIBDRM epoxy"
+XWAYLANDMODULES="wayland-client >= 1.3.0 $LIBDRM $LIBEPOXY"
 if test "x$XF86VIDMODE" = xyes; then
XWAYLANDMODULES="$XWAYLANDMODULES $VIDMODEPROTO"
 fi
-- 
2.10.0

___
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] modesetting: unifdef MODESETTING_OUTPUT_SLAVE_SUPPORT

[Hans de Goede]

Hi,

On 22-10-16 14:10, Nikhil Mahale wrote:

Commit c7e8d4a6ee9542f56cd241cf7a960fb8223a6b22 had already
unifdef MODESETTING_OUTPUT_SLAVE_SUPPORT but commit
9257b1252da9092ddc676fec9aabe2b33dfad272 didn't
notice that.

Signed-off-by: Nikhil Mahale 


Looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 61a0e27..6e755e9 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -1701,10 +1701,8 @@ drmmode_create_name(ScrnInfoPtr pScrn, 
drmModeConnectorPtr koutput, char *name,
  fallback:
 if (koutput->connector_type >= MS_ARRAY_SIZE(output_names))
 snprintf(name, 32, "Unknown%d-%d", koutput->connector_type, 
koutput->connector_type_id);
-#ifdef MODESETTING_OUTPUT_SLAVE_SUPPORT
 else if (pScrn->is_gpu)
 snprintf(name, 32, "%s-%d-%d", output_names[koutput->connector_type], 
pScrn->scrnIndex - GPU_SCREEN_OFFSET + 1, koutput->connector_type_id);
-#endif
 else
 snprintf(name, 32, "%s-%d", output_names[koutput->connector_type], 
koutput->connector_type_id);
 }


___
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