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

[Keith Packard]

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?

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

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

[Eric Anholt]

The copy optimization in d37329cba42fa8e72fe4be8a7be18e512268b5bd
replicated a bug from last time we did a copy optimization, and didn't
get rendercheck run on it.  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.

 glamor/glamor_render.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index c590580412c9..b5903acb20c2 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -1423,6 +1423,11 @@ glamor_composite_clipped_region(CARD8 op,
 /* Is the composite operation equivalent to a copy? */
 if (!mask && !source->alphaMap && !dest->alphaMap
 && source->pDrawable && !source->transform
+/* We can't do direct copies between different depths at 16bpp
+ * because r,g,b are allocated to different bits.
+ */
+&& !(dest->pDrawable->bitsPerPixel == 16 &&
+ 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] Enable XTRANS_SEND_FDS on FreeBSD and DragonFly too

[François Tigeot]

This code is based on a local patch which had actually been sitting in
FreeBSD ports since 2015.

Signed-off-by: François Tigeot 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index c09b854..b9e27d0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1231,7 +1231,7 @@ AC_ARG_ENABLE(xtrans-send-fds,
AS_HELP_STRING([--disable-xtrans-send-fds], [Use
 case "x$XTRANS_SEND_FDS" in
 xauto)
case "$host_os" in
-   linux*|solaris*)
+   linux*|solaris*|freebsd*|dragonfly*)
XTRANS_SEND_FDS=yes
;;
*)
-- 
2.9.2

___
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] os: Eliminate NewOutputPending

[Hans de Goede]

Hi,

On 09/22/2016 11:34 AM, Keith Packard wrote:

By removing clients from output_pending_clients list when flushing is
attempted, that list now becomes the list of clients that need
flushing, which is equivalent to what NewOutputPending was used for.

Clients are added to output_pending_clients when data are added to
their output buffer and when write blocked clients become writable.

Signed-off-by: Keith Packard 


I'm working on a branch with a bunch of reviewed fixes for 1.19
for Ajax to pull, is this 1.19 material ?

Regards,

Hans



---
 os/WaitFor.c|  2 +-
 os/connection.c |  3 +--
 os/io.c | 16 
 os/osdep.h  |  2 --
 4 files changed, 6 insertions(+), 17 deletions(-)

diff --git a/os/WaitFor.c b/os/WaitFor.c
index 024df35..cde2c8c 100644
--- a/os/WaitFor.c
+++ b/os/WaitFor.c
@@ -213,7 +213,7 @@ WaitForSomething(Bool are_ready)
 timeout = check_timers();

 BlockHandler();
-if (NewOutputPending)
+if (any_output_pending())
 FlushAllOutput();
 /* keep this check close to select() call to minimize race */
 if (dispatchException)
diff --git a/os/connection.c b/os/connection.c
index a901ebf..52b5067 100644
--- a/os/connection.c
+++ b/os/connection.c
@@ -121,7 +121,6 @@ SOFTWARE.
 struct ospoll   *server_poll;

 int MaxClients = 0;
-Bool NewOutputPending;  /* not yet attempted to write some new output 
*/
 Bool NoListenAll;   /* Don't establish any listening sockets */

 static Bool RunFromSmartParent; /* send SIGUSR1 to parent process */
@@ -712,7 +711,7 @@ ClientReady(int fd, int xevents, void *data)
 mark_client_ready(client);
 if (xevents & X_NOTIFY_WRITE) {
 ospoll_mute(server_poll, fd, X_NOTIFY_WRITE);
-NewOutputPending = TRUE;
+output_pending_mark(client);
 }
 }

diff --git a/os/io.c b/os/io.c
index 5ba1e86..7b95118 100644
--- a/os/io.c
+++ b/os/io.c
@@ -596,9 +596,8 @@ FlushAllOutput(void)
 {
 OsCommPtr oc;
 register ClientPtr client, tmp;
-Bool newoutput = NewOutputPending;

-if (!newoutput)
+if (!any_output_pending())
 return;

 /*
@@ -607,7 +606,6 @@ FlushAllOutput(void)
  * simply wait for the select to tell us when he's ready to receive.
  */
 CriticalOutputPending = FALSE;
-NewOutputPending = FALSE;

 xorg_list_for_each_entry_safe(client, tmp, _pending_clients, 
output_pending) {
 if (client->clientGone)
@@ -615,8 +613,7 @@ FlushAllOutput(void)
 if (!client_is_ready(client)) {
 oc = (OsCommPtr) client->osPrivate;
 (void) FlushClient(client, oc, (char *) NULL, 0);
-} else
-NewOutputPending = TRUE;
+}
 }
 }

@@ -759,16 +756,12 @@ WriteToClient(ClientPtr who, int count, const void *__buf)
 }
 #endif
 if (oco->count == 0 || oco->count + count + padBytes > oco->size) {
-output_pending_clear(who);
-if (!any_output_pending()) {
+if (!any_output_pending())
 CriticalOutputPending = FALSE;
-NewOutputPending = FALSE;
-}

 return FlushClient(who, oc, buf, count);
 }

-NewOutputPending = TRUE;
 output_pending_mark(who);
 memmove((char *) oco->buf + oco->count, buf, count);
 oco->count += count;
@@ -802,6 +795,7 @@ FlushClient(ClientPtr who, OsCommPtr oc, const void 
*__extraBuf, int extraCount)
 long notWritten;
 long todo;

+output_pending_clear(who);
 if (!oco)
return 0;
 written = 0;
@@ -868,7 +862,6 @@ FlushClient(ClientPtr who, OsCommPtr oc, const void 
*__extraBuf, int extraCount)
 /* If we've arrived here, then the client is stuffed to the gills
and not ready to accept more.  Make a note of it and buffer
the rest. */
-output_pending_mark(who);

 if (written < oco->count) {
 if (written > 0) {
@@ -932,7 +925,6 @@ FlushClient(ClientPtr who, OsCommPtr oc, const void 
*__extraBuf, int extraCount)

 /* everything was flushed out */
 oco->count = 0;
-output_pending_clear(who);

 if (oco->size > BUFWATERMARK) {
 free(oco->buf);
diff --git a/os/osdep.h b/os/osdep.h
index 90a247f..9c8bd48 100644
--- a/os/osdep.h
+++ b/os/osdep.h
@@ -165,8 +165,6 @@ extern void SetConnectionTranslation(int conn, int client);
 extern void ClearConnectionTranslation(void);
 #endif

-extern Bool NewOutputPending;
-
 extern WorkQueuePtr workQueue;

 /* in WaitFor.c */


___
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 xbitmaps] Install pkgconfig file into arch-dependent location

[Alan Coopersmith]

On 09/23/16 12:05 AM, Emil Velikov wrote:

On 23 September 2016 at 07:31, Julien Cristau  wrote:

On Thu, Sep 22, 2016 at 19:12:13 +0200, Heiko Becker wrote:


Signed-off-by: Heiko Becker 
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 060112d..9a89bbe 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,4 +1,4 @@
-pkgconfigdir = $(datadir)/pkgconfig
+pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA = xbitmaps.pc

 MAINTAINERCLEANFILES = ChangeLog INSTALL


That seems like it's going backwards, and your commit message doesn't
explain why.


That was my initial thought as well (going backwards). Then again,
as-is the .pc file is located in a arch _in_ dependant location, which
causes file conflicts as you have multilib - x86-86 & x86 installed
for example. In such cases the files have different contents (path)
which leads to link time issues.


How can you have link time issues when there's noting in xbitmaps to
link with?   It's purely xbm files, sometimes abused as C headers.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
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.

[Michel Dänzer]

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.


> 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?


-- 
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: [PATCH xbitmaps] Install pkgconfig file into arch-dependent location

[Emil Velikov]

On 23 September 2016 at 07:31, Julien Cristau  wrote:
> On Thu, Sep 22, 2016 at 19:12:13 +0200, Heiko Becker wrote:
>
>> Signed-off-by: Heiko Becker 
>> ---
>>  Makefile.am | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 060112d..9a89bbe 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -1,4 +1,4 @@
>> -pkgconfigdir = $(datadir)/pkgconfig
>> +pkgconfigdir = $(libdir)/pkgconfig
>>  pkgconfig_DATA = xbitmaps.pc
>>
>>  MAINTAINERCLEANFILES = ChangeLog INSTALL
>
> That seems like it's going backwards, and your commit message doesn't
> explain why.
>
That was my initial thought as well (going backwards). Then again,
as-is the .pc file is located in a arch _in_ dependant location, which
causes file conflicts as you have multilib - x86-86 & x86 installed
for example. In such cases the files have different contents (path)
which leads to link time issues.

Thanks
Emil
___
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 xf86-video-dummy v2] Remove pointless empty functions

[Antoine Martin]

On 22/09/16 23:14, Aaron Plattner wrote:
> These functions might be useful in a real driver, but with no
> hardware, they're pointless.  Get rid of them.
> 
> v2: Rebase, get rid of pointless calls to DUMMYAdjustFrame, return TRUE from
> DUMMYSwitchMode.
> 
> Signed-off-by: Aaron Plattner 
Both:
Reviewed-by: Antoine Martin 
Tested-by: Antoine Martin 

Cheers
Antoine

> ---
>  src/dummy_driver.c | 44 +---
>  1 file changed, 1 insertion(+), 43 deletions(-)
> 
> diff --git a/src/dummy_driver.c b/src/dummy_driver.c
> index cf150539e10b..265660280549 100644
> --- a/src/dummy_driver.c
> +++ b/src/dummy_driver.c
> @@ -65,9 +65,6 @@ static ModeStatus DUMMYValidMode(SCRN_ARG_TYPE arg, 
> DisplayModePtr mode,
>  static Bool  DUMMYSaveScreen(ScreenPtr pScreen, int mode);
>  
>  /* Internally used functions */
> -static Bool dummyModeInit(ScrnInfoPtr pScrn, DisplayModePtr mode);
> -static void  dummySave(ScrnInfoPtr pScrn);
> -static void  dummyRestore(ScrnInfoPtr pScrn, Bool restoreText);
>  static Bool  dummyDriverFunc(ScrnInfoPtr pScrn, xorgDriverFuncOp op,
>   pointer ptr);
>  
> @@ -461,14 +458,6 @@ DUMMYPreInit(ScrnInfoPtr pScrn, int flags)
>  static Bool
>  DUMMYEnterVT(VT_FUNC_ARGS_DECL)
>  {
> -SCRN_INFO_PTR(arg);
> -
> -/* Should we re-save the text mode on each VT enter? */
> -if(!dummyModeInit(pScrn, pScrn->currentMode))
> -  return FALSE;
> -
> -DUMMYAdjustFrame(ADJUST_FRAME_ARGS(pScrn, pScrn->frameX0, 
> pScrn->frameY0));
> -
>  return TRUE;
>  }
>  
> @@ -476,8 +465,6 @@ DUMMYEnterVT(VT_FUNC_ARGS_DECL)
>  static void
>  DUMMYLeaveVT(VT_FUNC_ARGS_DECL)
>  {
> -SCRN_INFO_PTR(arg);
> -dummyRestore(pScrn, TRUE);
>  }
>  
>  static void
> @@ -535,15 +522,6 @@ DUMMYScreenInit(SCREEN_INIT_ARGS_DECL)
>  
>  if (!(dPtr->FBBase = malloc(pScrn->videoRam * 1024)))
>   return FALSE;
> -
> -/*
> - * next we save the current state and setup the first mode
> - */
> -dummySave(pScrn);
> -
> -if (!dummyModeInit(pScrn,pScrn->currentMode))
> - return FALSE;
> -DUMMYAdjustFrame(ADJUST_FRAME_ARGS(pScrn, pScrn->frameX0, 
> pScrn->frameY0));
>  
>  /*
>   * Reset visual list.
> @@ -665,8 +643,7 @@ DUMMYScreenInit(SCREEN_INIT_ARGS_DECL)
>  Bool
>  DUMMYSwitchMode(SWITCH_MODE_ARGS_DECL)
>  {
> -SCRN_INFO_PTR(arg);
> -return dummyModeInit(pScrn, mode);
> +return TRUE;
>  }
>  
>  /* Mandatory */
> @@ -683,7 +660,6 @@ DUMMYCloseScreen(CLOSE_SCREEN_ARGS_DECL)
>  DUMMYPtr dPtr = DUMMYPTR(pScrn);
>  
>  if(pScrn->vtSema){
> - dummyRestore(pScrn, TRUE);
>   free(dPtr->FBBase);
>  }
>  
> @@ -725,24 +701,6 @@ DUMMYValidMode(SCRN_ARG_TYPE arg, DisplayModePtr mode, 
> Bool verbose, int flags)
>  return(MODE_OK);
>  }
>  
> -static void
> -dummySave(ScrnInfoPtr pScrn)
> -{
> -}
> -
> -static void 
> -dummyRestore(ScrnInfoPtr pScrn, Bool restoreText)
> -{
> -}
> -
> -static Bool
> -dummyModeInit(ScrnInfoPtr pScrn, DisplayModePtr mode)
> -{
> -dummyRestore(pScrn, FALSE);
> -
> -return(TRUE);
> -}
> -
>  Atom VFB_PROP  = 0;
>  #define  VFB_PROP_NAME  "VFB_IDENT"
>  
> 

___
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 xbitmaps] Install pkgconfig file into arch-dependent location

[Julien Cristau]

On Thu, Sep 22, 2016 at 19:12:13 +0200, Heiko Becker wrote:

> Signed-off-by: Heiko Becker 
> ---
>  Makefile.am | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index 060112d..9a89bbe 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -1,4 +1,4 @@
> -pkgconfigdir = $(datadir)/pkgconfig
> +pkgconfigdir = $(libdir)/pkgconfig
>  pkgconfig_DATA = xbitmaps.pc
>  
>  MAINTAINERCLEANFILES = ChangeLog INSTALL

That seems like it's going backwards, and your commit message doesn't
explain why.

Cheers,
Julien
___
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/1] Simplify, statement is always true.

[Hans de Goede]

Hi,

On 09/22/2016 03:08 AM, Maya Rashish wrote:

pVideo->bus is uint8_t, always less than 256.

Signed-off-by: Maya Rashish 


LGTM:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
 hw/xfree86/common/xf86pciBus.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/hw/xfree86/common/xf86pciBus.c b/hw/xfree86/common/xf86pciBus.c
index 8158c2b..bed4434 100644
--- a/hw/xfree86/common/xf86pciBus.c
+++ b/hw/xfree86/common/xf86pciBus.c
@@ -1457,11 +1457,7 @@ xf86PciConfigureNewDev(void *busData, struct pci_device 
*pVideo,

 pVideo = (struct pci_device *) busData;

-if (pVideo->bus < 256)
-snprintf(busnum, sizeof(busnum), "%d", pVideo->bus);
-else
-snprintf(busnum, sizeof(busnum), "%d@%d",
- pVideo->bus & 0x00ff, pVideo->bus >> 8);
+snprintf(busnum, sizeof(busnum), "%d", pVideo->bus);

 XNFasprintf(, "PCI:%s:%d:%d",
 busnum, pVideo->dev, pVideo->func);


___
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 06/10 v2] test: Make the piglit-running script callable with an arbitrary server.

[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 08/10 v2] test: Update piglit HTML even when tests all pass.

[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

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

[Michel Dänzer]

On 23/09/16 03:46 PM, Hans de Goede wrote:
> On 09/20/2016 04:58 AM, Michel Dänzer wrote:
> 
>> If there are other drivers which can't call xf86HandleColormaps for some
>> reason, a better solution would be to combine the per-screen gamma set
>> via pScrn->ChangeGamma with the per-CRTC gamma set via
>> xf86RandR12CrtcSetGamma.
> 
> Hmm, I understand what you're getting at. The problem is not if drivers
> can or cannot call xf86HandleColormaps though. The problem is that there
> likely will be drivers which do not (even though they would be perfectly
> fine doing so).
> 
> Although I agree that your proposal is an improvement, I would prefer to
> just move forward with this patch-set to provide a fall-back to ensure
> that we do not have any regressions caused by pScrn->ChangeGamma being
> NULL.

Leaving it as NULL would probably flush out such drivers more quickly
though. :)


> 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.


-- 
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: [xserver, 2/2] xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error

[Hans de Goede]

Hi,

On 09/20/2016 04:58 AM, Michel Dänzer wrote:

On 17/09/16 07:00 PM, Hans De Goede wrote:

Commit b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")
dropped the providing of a pScrn->ChangeGamma callback from the xf86RandR12
code. Leaving pScrn->ChangeGamma NULL in most cases.

This triggers the BadImplementation error in xf86ChangeGamma() :

if (pScrn->ChangeGamma)
return (*pScrn->ChangeGamma) (pScrn, gamma);

return BadImplementation;

Which causes X-apps using XF86VidModeSetGamma to crash with a
X protocol error.

This commit fixes this by re-introducing the xf86RandR12ChangeGamma
helper removed by the commit and adjusting it to work with the new
combined palette / gamma code.

Fixes: b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")


I suspect you really want to fix the modesetting driver to call
xf86HandleColormaps, so it can actually benefit from that change and
e.g. gamma sliders in games start working.


Ah, good one. I'll take a look at this.



If there are other drivers which can't call xf86HandleColormaps for some
reason, a better solution would be to combine the per-screen gamma set
via pScrn->ChangeGamma with the per-CRTC gamma set via
xf86RandR12CrtcSetGamma.


Hmm, I understand what you're getting at. The problem is not if drivers
can or cannot call xf86HandleColormaps though. The problem is that there
likely will be drivers which do not (even though they would be perfectly
fine doing so).

Although I agree that your proposal is an improvement, I would prefer to
just move forward with this patch-set to provide a fall-back to ensure
that we do not have any regressions caused by pScrn->ChangeGamma being
NULL.

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.

Regards,

Hans
___
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 05/10 v2] test: Add a little xinit-like program for starting servers for testing.

[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.

Signed-off-by: Eric Anholt 
---
 test/.gitignore |   1 +
 test/Makefile.am|  13 ++-
 test/simple-xinit.c | 223 
 3 files changed, 233 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 ..565620ad71a6
--- /dev/null
+++ b/test/simple-xinit.c
@@ -0,0 +1,223 @@
+/*
+ * 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 serverpid)
+{
+int ret = kill(serverpid, SIGTERM);
+int wstatus;
+
+if (ret) {
+fprintf(stderr, "Failed to send kill to the server: %s\n",
+strerror(errno));
+exit(1);
+}
+
+ret = waitpid(serverpid, , 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 serverpid = fork();
+
+if (serverpid != 0) {
+/* Continue along the main process that will exec the client. */
+return serverpid;
+}
+
+/* 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 *const *client_args, int display)
+{
+char *display_string;
+int ret;
+int client_pid;
+
+ret = asprintf(_string, ":%d", display);
+if (ret < 0) {
+

[PATCH xserver] modesetting: Do not call drmModeSetCursor2() twice on every cursor change

[Hans de Goede]

Each xf86ScreenSetCursor() call calls:

xf86DriverLoadCursorARGB()
infoPtr->ShowCursor()

In succession, ending up in 2 drmModeSetCursor2() calls, with the second
effectively being a no-op. Keep track of having set the cursor already
in drmmode_load_cursor_argb_check() and unless hide() was called in
the mean time make drmmode_show_cursor() a no-op.

Signed-off-by: Hans de Goede 
---
Note this patch applies on top of Michael Thayer's
"modesetting: allow switching from software to hardware cursors (v4)"
series
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 7 ++-
 hw/xfree86/drivers/modesetting/drmmode_display.h | 1 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 46e981b..23c1db1 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -783,6 +783,8 @@ drmmode_set_cursor(xf86CrtcPtr crtc)
 if (ret)
 /* fallback to swcursor */
 return FALSE;
+
+drmmode_crtc->cursor_up = TRUE;
 return TRUE;
 }
 
@@ -817,6 +819,7 @@ drmmode_hide_cursor(xf86CrtcPtr crtc)
 drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
 drmmode_ptr drmmode = drmmode_crtc->drmmode;
 
+drmmode_crtc->cursor_up = FALSE;
 drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, 0,
  ms->cursor_width, ms->cursor_height);
 }
@@ -825,7 +828,9 @@ static void
 drmmode_show_cursor(xf86CrtcPtr crtc)
 {
 drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
-drmmode_set_cursor(crtc);
+
+if (!drmmode_crtc->cursor_up)
+drmmode_set_cursor(crtc);
 }
 
 static void
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.h 
b/hw/xfree86/drivers/modesetting/drmmode_display.h
index f979b99..f774250 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.h
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.h
@@ -91,6 +91,7 @@ typedef struct {
 uint32_t vblank_pipe;
 int dpms_mode;
 struct dumb_bo *cursor_bo;
+Bool cursor_up;
 uint16_t lut_r[256], lut_g[256], lut_b[256];
 
 drmmode_bo rotate_bo;
-- 
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 xbitmaps] Install pkgconfig file into arch-dependent location

[Emil Velikov]

On 23 September 2016 at 08:07, Alan Coopersmith
 wrote:
> On 09/23/16 12:05 AM, Emil Velikov wrote:
>>
>> On 23 September 2016 at 07:31, Julien Cristau  wrote:
>>>
>>> On Thu, Sep 22, 2016 at 19:12:13 +0200, Heiko Becker wrote:
>>>
 Signed-off-by: Heiko Becker 
 ---
  Makefile.am | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/Makefile.am b/Makefile.am
 index 060112d..9a89bbe 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -1,4 +1,4 @@
 -pkgconfigdir = $(datadir)/pkgconfig
 +pkgconfigdir = $(libdir)/pkgconfig
  pkgconfig_DATA = xbitmaps.pc

  MAINTAINERCLEANFILES = ChangeLog INSTALL
>>>
>>>
>>> That seems like it's going backwards, and your commit message doesn't
>>> explain why.
>>>
>> That was my initial thought as well (going backwards). Then again,
>> as-is the .pc file is located in a arch _in_ dependant location, which
>> causes file conflicts as you have multilib - x86-86 & x86 installed
>> for example. In such cases the files have different contents (path)
>> which leads to link time issues.
>
>
> How can you have link time issues when there's noting in xbitmaps to
> link with?   It's purely xbm files, sometimes abused as C headers.
>
Ack, you're absolutely correct. I didn't realise that the xbitmaps
repo doesn't ship any libraries.

Thanks
Emil
___
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 xbitmaps] Install pkgconfig file into arch-dependent location

[Heiko Becker]

On 09/23/16 12:34, Emil Velikov wrote:
> On 23 September 2016 at 08:07, Alan Coopersmith
>  wrote:
>> On 09/23/16 12:05 AM, Emil Velikov wrote:
>>>
>>> On 23 September 2016 at 07:31, Julien Cristau  wrote:

 On Thu, Sep 22, 2016 at 19:12:13 +0200, Heiko Becker wrote:

 That seems like it's going backwards, and your commit message doesn't
 explain why.

>>> That was my initial thought as well (going backwards). Then again,
>>> as-is the .pc file is located in a arch _in_ dependant location, which
>>> causes file conflicts as you have multilib - x86-86 & x86 installed
>>> for example. In such cases the files have different contents (path)
>>> which leads to link time issues.
>>
>>
>> How can you have link time issues when there's noting in xbitmaps to
>> link with?   It's purely xbm files, sometimes abused as C headers.
>>
> Ack, you're absolutely correct. I didn't realise that the xbitmaps
> repo doesn't ship any libraries.

It doesn't, but it provides includes and the includedir gets propagated
via pkg-config, leading to a build error on a multi-arch layout when
cross compiling xsetroot.

Cheers,
Heiko


___
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: only fall back to drmModeSetCursor() on -EINVAL

[Hans de Goede]

Hi All,

On 09/16/2016 06:51 PM, Michael Thayer wrote:

This change effectively reverts commit 074cf58.  We were falling back from
drmModeSetCursor2() to drmModeSetCursor() whenever the first failed.  This
fall-back only makes sense on pre-mid-2013 kernels which implemented the
cursor_set hook but not cursor_set2, and in this case the call to
drmModeSetCursor2() will always return -EINVAL.  Specifically, a return
value of -ENXIO usually means that neither are supported.

Signed-off-by: Michael Thayer 


LGTM: Reviewed-by: Hans de Goede 

Regards,

Hans



---
1) Tested that hardware cursors still work with the patch applied.
2) Tested in gdb that the expected path is taken when drmModeSetCursor2()
   returns -EINVAL.

 hw/xfree86/drivers/modesetting/drmmode_display.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 6b933e4..41810d9 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -768,11 +768,15 @@ drmmode_set_cursor(xf86CrtcPtr crtc)
 if (!ret)
 return TRUE;

-drmmode_crtc->set_cursor2_failed = TRUE;
+/* -EINVAL can mean that an old kernel supports drmModeSetCursor but
+ * not drmModeSetCursor2, though it can mean other things too. */
+if (ret == -EINVAL)
+drmmode_crtc->set_cursor2_failed = TRUE;
 }

-ret = drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, 
handle,
-   ms->cursor_width, ms->cursor_height);
+if (ret == -EINVAL)
+ret = drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
+   handle, ms->cursor_width, ms->cursor_height);

 if (ret) {
 xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);


___
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: always set a hardware cursor when requested to load one.

[Hans de Goede]

Hi All,

On 09/16/2016 06:52 PM, Michael Thayer wrote:

When the X server asks us to load a hardware cursor, that request is always
followed up by a request to show it if we report success, or to hide it if
we report failure.  Therefore it makes no sense to suppress the request if
the cursor is not currently visible.


Ok, I've just spend the last half hour tracing (using grep) all callers of
load_cursor_argb_check and you're right, either the cursor is already
visible (XRecolorCursor does this), or it will get shown directly after
the drmmode_load_cursor_argb_check() call.

So this patch is:

Reviewed-by: Hans de Goede 

Regards,

Hans





Signed-off-by: Michael Thayer 
---
Tested that both hardware and software cursors still work after applying the
patch.

 hw/xfree86/drivers/modesetting/drmmode_display.c | 11 +--
 hw/xfree86/drivers/modesetting/drmmode_display.h |  2 --
 2 files changed, 1 insertion(+), 12 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 41810d9..7d171a3 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -813,14 +813,7 @@ drmmode_load_cursor_argb_check(xf86CrtcPtr crtc, CARD32 
*image)
 for (i = 0; i < ms->cursor_width * ms->cursor_height; i++)
 ptr[i] = image[i];  // cpu_to_le32(image[i]);

-if (drmmode_crtc->cursor_up || !drmmode_crtc->first_cursor_load_done) {
-Bool ret = drmmode_set_cursor(crtc);
-if (!drmmode_crtc->cursor_up)
-drmmode_hide_cursor(crtc);
-drmmode_crtc->first_cursor_load_done = TRUE;
-return ret;
-}
-return TRUE;
+return drmmode_set_cursor(crtc);
 }

 static void
@@ -830,7 +823,6 @@ drmmode_hide_cursor(xf86CrtcPtr crtc)
 drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
 drmmode_ptr drmmode = drmmode_crtc->drmmode;

-drmmode_crtc->cursor_up = FALSE;
 drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, 0,
  ms->cursor_width, ms->cursor_height);
 }
@@ -839,7 +831,6 @@ static void
 drmmode_show_cursor(xf86CrtcPtr crtc)
 {
 drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
-drmmode_crtc->cursor_up = TRUE;
 drmmode_set_cursor(crtc);
 }

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.h 
b/hw/xfree86/drivers/modesetting/drmmode_display.h
index 50976b8..bd82968 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.h
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.h
@@ -91,9 +91,7 @@ typedef struct {
 uint32_t vblank_pipe;
 int dpms_mode;
 struct dumb_bo *cursor_bo;
-Bool cursor_up;
 Bool set_cursor2_failed;
-Bool first_cursor_load_done;
 uint16_t lut_r[256], lut_g[256], lut_b[256];

 drmmode_bo rotate_bo;


___
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] Enable XTRANS_SEND_FDS on FreeBSD, DragonFly and OpenBSD

[François Tigeot]

Hi,

Sure, here's the second version.

___
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

[Hans de Goede]

Hi,

On 09/23/2016 11:13 AM, Michel Dänzer wrote:

On 23/09/16 03:46 PM, Hans de Goede wrote:

On 09/20/2016 04:58 AM, Michel Dänzer wrote:


If there are other drivers which can't call xf86HandleColormaps for some
reason, a better solution would be to combine the per-screen gamma set
via pScrn->ChangeGamma with the per-CRTC gamma set via
xf86RandR12CrtcSetGamma.


Hmm, I understand what you're getting at. The problem is not if drivers
can or cannot call xf86HandleColormaps though. The problem is that there
likely will be drivers which do not (even though they would be perfectly
fine doing so).

Although I agree that your proposal is an improvement, I would prefer to
just move forward with this patch-set to provide a fall-back to ensure
that we do not have any regressions caused by pScrn->ChangeGamma being
NULL.


Leaving it as NULL would probably flush out such drivers more quickly
though. :)



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.
 */

REgards,

Hans

___
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] Enable XTRANS_SEND_FDS on FreeBSD and DragonFly too

[Matthieu Herrb]

On Fri, Sep 23, 2016 at 09:58:10AM +0200, François Tigeot wrote:
> This code is based on a local patch which had actually been sitting in
> FreeBSD ports since 2015.
> 
> Signed-off-by: François Tigeot 
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure.ac b/configure.ac
> index c09b854..b9e27d0 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1231,7 +1231,7 @@ AC_ARG_ENABLE(xtrans-send-fds,  
> AS_HELP_STRING([--disable-xtrans-send-fds], [Use
>  case "x$XTRANS_SEND_FDS" in
>  xauto)
>   case "$host_os" in
> - linux*|solaris*)
> + linux*|solaris*|freebsd*|dragonfly*)
>   XTRANS_SEND_FDS=yes
>   ;;
>   *)

Hi,

We also have a local patch in OpenBSD to enable it. Please make that:

-   linux*|solaris*)
+   linux*|solaris*|freebsd*|dragonfly*|openbsd*)

With that:

Reviewed-by: Matthieu Herrb 

Thanks,
-- 
Matthieu Herrb


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] Enable XTRANS_SEND_FDS on FreeBSD, DragonFly and OpenBSD

[François Tigeot]

This code is based on local patches which had been sitting in
FreeBSD and OpenBSD ports.

Reviewed-by: Matthieu Herrb 
Signed-off-by: François Tigeot 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index dcc3968..4fff769 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1231,7 +1231,7 @@ AC_ARG_ENABLE(xtrans-send-fds,
AS_HELP_STRING([--disable-xtrans-send-fds], [Use
 case "x$XTRANS_SEND_FDS" in
 xauto)
case "$host_os" in
-   linux*|solaris*)
+   linux*|solaris*|freebsd*|dragonfly*|openbsd*)
XTRANS_SEND_FDS=yes
;;
*)
-- 
2.9.2

___
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

[Pull request]: couple of fixes for xwayland

[Olivier Fourdan]

The following changes since commit d0c5d205a919fc1d2eb599356090b58b1bf0176d:

  dix: Make InitCoreDevices() failures more verbose. (2016-09-21 21:11:40 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~ofourdan/xserver xwayland

for you to fetch changes up to 0a20d5f8cb3f3f9a81b2795ae1865e72541022d4:

  xwayland: Clear up x_cursor on UnrealizeCursor() (2016-09-23 09:00:58 +0200)


Olivier Fourdan (2):
  xwayland: handle EAGAIN on Wayland fd
  xwayland: Clear up x_cursor on UnrealizeCursor()

Rui Matos (1):
  xwayland: Close the shm fd as early as possible

 hw/xwayland/xwayland-cursor.c |  7 ---
 hw/xwayland/xwayland-shm.c| 46 
+++---
 hw/xwayland/xwayland.c| 34 +++---
 hw/xwayland/xwayland.h|  1 +
 4 files changed, 55 insertions(+), 33 deletions(-)
___
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] modesetting: Consume all available udev events at once

[Hans de Goede]

Hi,

On 12/11/2015 01:05 PM, Daniel Martin wrote:

From: Daniel Martin 

We get multiple udev events for actions like docking a laptop into its
station or plugging a monitor to the station. By consuming as much
events as we can, we reduce the number of output re-evalutions.

I.e. having a Lenovo X250 in a ThinkPad Ultra Dock and plugging a
monitor to the station generates 5 udev events. Or having 2 monitors
attached to the station and docking the laptop generates 7 events.

It depends on the timing how many events can consumed at once.

Signed-off-by: Daniel Martin 


Thank you for the patch one small comment below.


---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 0d34ca1..eeccb82 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -1944,16 +1944,19 @@ drmmode_handle_uevents(int fd, void *closure)
 drmModeResPtr mode_res;
 xf86CrtcConfigPtr  config = XF86_CRTC_CONFIG_PTR(scrn);
 int i, j;
-Bool found;
+Bool found = FALSE;
 Bool changed = FALSE;

-dev = udev_monitor_receive_device(drmmode->uevent_monitor);
-if (!dev)
+while ((dev = udev_monitor_receive_device(drmmode->uevent_monitor))) {
+udev_device_unref(dev);
+found = TRUE;
+}
+if (!found)
 return;

 mode_res = drmModeGetResources(drmmode->fd);
 if (!mode_res)
-goto out;
+return;


This change means that you're now no longer calling RRGetInfo() in this exit
path, which seems like an unrelated change.

I've applied this patch to my tree with this bit ommitted; and I will include
it in the pull-req with fixes for 1.19 I'm working on.




 if (mode_res->count_crtcs != config->num_crtc) {
 ErrorF("number of CRTCs changed - failed to handle, %d vs %d\n", 
mode_res->count_crtcs, config->num_crtc);
@@ -2012,9 +2015,7 @@ drmmode_handle_uevents(int fd, void *closure)

 out_free_res:
 drmModeFreeResources(mode_res);
-out:
 RRGetInfo(xf86ScrnToScreen(scrn), TRUE);
-udev_device_unref(dev);
 }
 #endif




Regards,

Hans
___
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.

[Eric Anholt]

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.

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.

>> 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.


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)

[Hans de Goede]

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?

The linked to patch LGTM and is:

Reviewed-by: Hans de Goede 

Regards,

Hans
___
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 small memory leaks fixes

[Hans de Goede]

Hi David,

On 05/05/2016 10:39 AM, David CARLIER wrote:

Hi all,

This is a small patch to fix couple of small memory leaks.

Hope it s useful.


It is thanks for your patch, I've split 2 bits out into small patches
and I've dropped the os/rpcauth.c change I think that you are doing
the right thing there, but I'm not 100% sure (and if doing the free
is the right thing, it also needs to happen in the success path,
not just in the failure path).

You can see the split out patches here:

https://cgit.freedesktop.org/~jwrdegoede/xserver

I'm waiting for review from another developer for the 2 bits I
split out, the main patch will be included in my next pull-request
to get a bunch of fixes added to the xserver for 1.19

Regards,

Hans





Thanks.

Kind regards.


From 88024a5d4f36902ae66fe854d8ec93c3ed71cf8a Mon Sep 17 00:00:00 2001

From: David Carlier 
Date: Wed, 4 May 2016 22:03:19 +0100
Subject: [PATCH xserver] couple of memory leaks fixes and avoiding bit
 shifting on an unitialized value.

---
 Xext/shm.c  | 1 +
 Xext/vidmode.c  | 5 +++--
 composite/compext.c | 8 ++--
 hw/xfree86/ddc/ddc.c| 2 +-
 hw/xfree86/drivers/modesetting/driver.c | 1 +
 hw/xfree86/utils/gtf/gtf.c  | 2 ++
 os/rpcauth.c| 1 +
 7 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/Xext/shm.c b/Xext/shm.c
index b359a90..a63b42c 100644
--- a/Xext/shm.c
+++ b/Xext/shm.c
@@ -975,6 +975,7 @@ ProcPanoramiXShmCreatePixmap(ClientPtr client)
   RT_PIXMAP, pMap, RT_NONE, NULL, DixCreateAccess);
 if (result != Success) {
 pDraw->pScreen->DestroyPixmap(pMap);
+free(newPix);
 return result;
 }
 dixSetPrivate(>devPrivates, shmPixmapPrivateKey, shmdesc);
diff --git a/Xext/vidmode.c b/Xext/vidmode.c
index 499a2a8..65ce20b 100644
--- a/Xext/vidmode.c
+++ b/Xext/vidmode.c
@@ -1315,7 +1315,7 @@ ProcVidModeGetDotClocks(ClientPtr client)
 int n;
 int numClocks;
 CARD32 dotclock;
-int *Clocks = NULL;
+int *Clocks = NULL, *Ptr;
 Bool ClockProg;

 DEBUG_P("XF86VidModeGetDotClocks");
@@ -1361,6 +1361,7 @@ ProcVidModeGetDotClocks(ClientPtr client)
 swapl();
 swapl();
 }
+Ptr = Clocks;
 WriteToClient(client, sizeof(xXF86VidModeGetDotClocksReply), );
 if (!ClockProg) {
 for (n = 0; n < numClocks; n++) {
@@ -1374,7 +1375,7 @@ ProcVidModeGetDotClocks(ClientPtr client)
 }
 }

-free(Clocks);
+free(Ptr);
 return Success;
 }

diff --git a/composite/compext.c b/composite/compext.c
index f1a8255..96d07d7 100644
--- a/composite/compext.c
+++ b/composite/compext.c
@@ -762,14 +762,18 @@ PanoramiXCompositeNameWindowPixmap(ClientPtr client)
 return BadMatch;
 }

-if (!AddResource(newPix->info[i].id, RT_PIXMAP, (void *) pPixmap))
+if (!AddResource(newPix->info[i].id, RT_PIXMAP, (void *) pPixmap)) {
+free(newPix);
 return BadAlloc;
+   }

 ++pPixmap->refcnt;
 }

-if (!AddResource(stuff->pixmap, XRT_PIXMAP, (void *) newPix))
+if (!AddResource(stuff->pixmap, XRT_PIXMAP, (void *) newPix)) {
+free(newPix);
 return BadAlloc;
+}

 return Success;
 }
diff --git a/hw/xfree86/ddc/ddc.c b/hw/xfree86/ddc/ddc.c
index ee533db..b82dfc1 100644
--- a/hw/xfree86/ddc/ddc.c
+++ b/hw/xfree86/ddc/ddc.c
@@ -149,7 +149,7 @@ GetEDID_DDC1(unsigned int *s_ptr)
 return NULL;
 s_end = s_ptr + NUM;
 s_pos = s_ptr + s_start;
-d_block = malloc(EDID1_LEN);
+d_block = calloc(1, EDID1_LEN);
 if (!d_block)
 return NULL;
 d_pos = d_block;
diff --git a/hw/xfree86/drivers/modesetting/driver.c 
b/hw/xfree86/drivers/modesetting/driver.c
index fe5d5e1..0a0ca65 100644
--- a/hw/xfree86/drivers/modesetting/driver.c
+++ b/hw/xfree86/drivers/modesetting/driver.c
@@ -761,6 +761,7 @@ ms_get_drm_master_fd(ScrnInfoPtr pScrn)
 );
 }
 ms->fd = drmOpen(NULL, BusID);
+free(BusID);
 }
 else {
 const char *devicename;
diff --git a/hw/xfree86/utils/gtf/gtf.c b/hw/xfree86/utils/gtf/gtf.c
index e88387d..c31bc8f 100644
--- a/hw/xfree86/utils/gtf/gtf.c
+++ b/hw/xfree86/utils/gtf/gtf.c
@@ -692,6 +692,8 @@ main(int argc, char *argv[])
 if (o->fbmode)
 print_fb_mode(m);

+free(m);
+
 return 0;

 }
diff --git a/os/rpcauth.c b/os/rpcauth.c
index 5680489..923ffc3 100644
--- a/os/rpcauth.c
+++ b/os/rpcauth.c
@@ -111,6 +111,7 @@ authdes_ezdecode(const char *inmsg, int len)
  bad2:
 free(r.rq_clntcred);
  bad1:
+free(temp_inmsg);
 return ((char *) 0);/* ((struct authdes_cred *) NULL); */
 }



___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: 

Re: xfree86: Fix null pointer dereference

[Hans de Goede]

Hi,

On 01/13/2016 07:47 AM, Kyle Guinn wrote:

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=93675

Signed-off-by: Kyle Guinn 


Thanks for the patch, I've queued this up at:

https://cgit.freedesktop.org/~jwrdegoede/xserver

For a 1.19 bug-fix pull-req I'm preparing at.

Note I've simplified the patch to:

-if (d) {
+if (d && d->pI2CBus) {

Instead of the nested ifs you used, still many thanks
for tracking this crashed down!

Regards,

Hans




---
 hw/xfree86/i2c/xf86i2c.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/hw/xfree86/i2c/xf86i2c.c b/hw/xfree86/i2c/xf86i2c.c
index 2a8b8df..62b647c 100644
--- a/hw/xfree86/i2c/xf86i2c.c
+++ b/hw/xfree86/i2c/xf86i2c.c
@@ -615,19 +615,21 @@ void
 xf86DestroyI2CDevRec(I2CDevPtr d, Bool unalloc)
 {
 if (d) {
-I2CDevPtr *p;
+if (d->pI2CBus) {
+I2CDevPtr *p;

-/* Remove this from the list of active I2C devices. */
+/* Remove this from the list of active I2C devices. */

-for (p = >pI2CBus->FirstDev; *p != NULL; p = &(*p)->NextDev)
-if (*p == d) {
-*p = (*p)->NextDev;
-break;
-}
+for (p = >pI2CBus->FirstDev; *p != NULL; p = &(*p)->NextDev)
+if (*p == d) {
+*p = (*p)->NextDev;
+break;
+}

-xf86DrvMsg(d->pI2CBus->scrnIndex, X_INFO,
-   "I2C device \"%s:%s\" removed.\n",
-   d->pI2CBus->BusName, d->DevName);
+xf86DrvMsg(d->pI2CBus->scrnIndex, X_INFO,
+   "I2C device \"%s:%s\" removed.\n",
+   d->pI2CBus->BusName, d->DevName);
+}

 if (unalloc)
 free(d);


___
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

[Adam Jackson]

On Fri, 2016-09-23 at 01:15 +0300, Keith Packard wrote:

> +static void
> +FixCoordModePrevious(int npt, xPoint *ppt)
> +{
> +int x, y;
> +
> +x = ppt->x;
> +y = ppt->y;
> +npt--;
> +while (npt--) {
> +ppt++;
> +x = (ppt->x += x);
> +y = (ppt->y += y);
> +}
> +}

You want to make this non-static, so in the xinerama case you can do
this translation once at the top level.

> @@ -1785,9 +1800,12 @@ ProcPolyPoint(ClientPtr client)
>  }
>  VALIDATE_DRAWABLE_AND_GC(stuff->drawable, pDraw, DixWriteAccess);
>  npoint = bytes_to_int32((client->req_len << 2) - sizeof(xPolyPointReq));
> -if (npoint)
> -(*pGC->ops->PolyPoint) (pDraw, pGC, stuff->coordMode, npoint,
> +if (npoint) {
> +if (stuff->coordMode == CoordModePrevious)
> +FixCoordModePrevious(npoint, (xPoint *) [1]);
> +(*pGC->ops->PolyPoint) (pDraw, pGC, npoint,
>  (xPoint *) [1]);
> +}
>  return Success;
>  }

You're not correcting stuff->coordMode in place, which means under
xinerama you'll mutate geometry once per screen, which ain't right.

- 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 2/2] XF86VidMode: Fix free() on walked pointer

[Emil Velikov]

On 23 September 2016 at 12:50, Hans de Goede  wrote:
> Based on: https://patchwork.freedesktop.org/patch/85636/
>
> Rewritten to just not walk the pointer.
>
Since the free is just outside of context one could mention it and/or
elaborate a bit in general. Regardless the patch is spot on, so

Reviewed-by: Emi Velikov 

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

[xserver PULL for 1.19] Various modesetting and other fixes

[Hans de Goede]

Hi Adam, Keith,

Here is a pull-req consisting of a bunch of fixes written by
me reviewed by others as well as a bunch of fixes from patchwork /
the list which I've picked up and which are reviewed by me.

Note there is one unreviewed patch in here v2 of:
"glx: Always enable EXT_texture_from_pixmap for DRI swrast glx"

But I believe that Adam and I are in agreement wrt v2, so that
one should be good to go too.


The following changes since commit d0c5d205a919fc1d2eb599356090b58b1bf0176d:

  dix: Make InitCoreDevices() failures more verbose. (2016-09-21 21:11:40 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~jwrdegoede/xserver for-server-1.19

for you to fetch changes up to 01189c04a073447dc4eb474ec4cee7c59be5576e:

  Simplify, statement is always true. (2016-09-23 15:55:22 +0300)


Adam Jackson (1):
  xephyr: Don't crash if the server advertises zero xv adaptors

Daniel Martin (1):
  modesetting: Consume all available udev events at once

David CARLIER (1):
  xfree86: small memory leaks fixes

Hans de Goede (8):
  modesetting: Fix reverse prime partial update issues on secondary GPU 
outputs
  modesetting: Fix reverse prime update lagging on secondary GPU outputs
  xf86RandR12: Move calculating of shift inside init_one_component
  xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error
  glx: Always enable EXT_texture_from_pixmap for DRI swrast glx
  modesetting: Do not call drmModeSetCursor2() twice on every cursor change
  Xext: Fix a memory leak
  XF86VidMode: Fix free() on walked pointer

Keith Packard (2):
  os: Ready clients with pending output aren't flushed, so set 
NewOutputPending
  os: Clear saved poll events in listen so that edge triggering works

Kyle Guinn (1):
  xfree86: Fix null pointer dereference

Laszlo Ersek (1):
  xfree86: recognize primary BUS_PCI device in xf86IsPrimaryPlatform()

Maya Rashish (1):
  Simplify, statement is always true.

Michael Thayer (3):
  modesetting: only fall back to drmModeSetCursor() on -EINVAL
  modesetting: always set a hardware cursor when requested to load one.
  modesetting: allow switching from software to hardware cursors (v4).

Qiang Yu (1):
  config: fix GPUDevice fail when AutoAddGPU off + BusID

 Xext/shm.c   |  4 +-
 Xext/vidmode.c   |  2 +-
 glx/glxdriswrast.c   |  3 +-
 hw/kdrive/ephyr/ephyrvideo.c |  2 +-
 hw/xfree86/common/xf86pciBus.c   |  6 +--
 hw/xfree86/common/xf86platformBus.c  | 28 +--
 hw/xfree86/ddc/ddc.c |  2 +-
 hw/xfree86/drivers/modesetting/driver.c  | 29 +---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 60 +++-
 hw/xfree86/drivers/modesetting/drmmode_display.h |  2 -
 hw/xfree86/i2c/xf86i2c.c |  8 ++--
 hw/xfree86/modes/xf86RandR12.c   | 44 ++---
 hw/xfree86/utils/gtf/gtf.c   |  2 +
 os/io.c  |  3 +-
 os/ospoll.c  |  8 +++-
 15 files changed, 132 insertions(+), 71 deletions(-)

Regards,

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

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

[Matthieu Herrb]

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/

If needed I can resend the patches there.

Thanks
-- 
Matthieu Herrb


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 2/2] XF86VidMode: Fix free() on walked pointer

[Hans de Goede]

Based on: https://patchwork.freedesktop.org/patch/85636/

Rewritten to just not walk the pointer.

Signed-off-by: Hans de Goede 
---
 Xext/vidmode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Xext/vidmode.c b/Xext/vidmode.c
index 499a2a8..ea3ad13 100644
--- a/Xext/vidmode.c
+++ b/Xext/vidmode.c
@@ -1364,7 +1364,7 @@ ProcVidModeGetDotClocks(ClientPtr client)
 WriteToClient(client, sizeof(xXF86VidModeGetDotClocksReply), );
 if (!ClockProg) {
 for (n = 0; n < numClocks; n++) {
-dotclock = *Clocks++;
+dotclock = Clocks[n];
 if (client->swapped) {
 WriteSwappedDataToClient(client, 4, (char *) );
 }
-- 
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 1/2] Xext: Fix a memory leak

[Hans de Goede]

Based on: https://patchwork.freedesktop.org/patch/85636/

Rewritten to also free the resources allocated by
panoramix_setup_ids().

Signed-off-by: Hans de Goede 
---
 Xext/shm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Xext/shm.c b/Xext/shm.c
index 125000f..1b622e3 100644
--- a/Xext/shm.c
+++ b/Xext/shm.c
@@ -991,7 +991,7 @@ ProcPanoramiXShmCreatePixmap(ClientPtr client)
   RT_PIXMAP, pMap, RT_NONE, NULL, DixCreateAccess);
 if (result != Success) {
 pDraw->pScreen->DestroyPixmap(pMap);
-return result;
+break;
 }
 dixSetPrivate(>devPrivates, shmPixmapPrivateKey, shmdesc);
 shmdesc->refcnt++;
@@ -1008,7 +1008,7 @@ ProcPanoramiXShmCreatePixmap(ClientPtr client)
 }
 }
 
-if (result == BadAlloc) {
+if (result != Success) {
 while (j--)
 FreeResource(newPix->info[j].id, RT_NONE);
 free(newPix);
-- 
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 1/2] Xext: Fix a memory leak

[Hans de Goede]

Hi,

On 09/23/2016 03:23 PM, Emil Velikov wrote:

On 23 September 2016 at 12:50, Hans de Goede  wrote:

Based on: https://patchwork.freedesktop.org/patch/85636/

Rewritten to also free the resources allocated by
panoramix_setup_ids().


The codeflow is a bit nasty to read, but the patch is perfectly correct.

Reviewed-by: Emil Velikov 


Thank you for the quick reviews!

Regards,

Hans
___
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: xfree86: Fix null pointer dereference

[Hans de Goede]

Hi,

On 09/23/2016 03:33 PM, Eric Engestrom wrote:

On Fri, Sep 23, 2016 at 03:12:18PM +0300, Hans de Goede wrote:

Hi,

On 01/13/2016 07:47 AM, Kyle Guinn wrote:

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=93675

Signed-off-by: Kyle Guinn 


Thanks for the patch, I've queued this up at:

https://cgit.freedesktop.org/~jwrdegoede/xserver

For a 1.19 bug-fix pull-req I'm preparing at.

Note I've simplified the patch to:

-if (d) {
+if (d && d->pI2CBus) {

Instead of the nested ifs you used, still many thanks
for tracking this crashed down!


I find this better too, but if you do that you need to move

if (unalloc)
free(d);

out of that `if (d && d->pI2CBus)` :)


Good one, thanks for catching that.

Regards,

Hans


---
 hw/xfree86/i2c/xf86i2c.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/hw/xfree86/i2c/xf86i2c.c b/hw/xfree86/i2c/xf86i2c.c
index 2a8b8df..62b647c 100644
--- a/hw/xfree86/i2c/xf86i2c.c
+++ b/hw/xfree86/i2c/xf86i2c.c
@@ -615,19 +615,21 @@ void
 xf86DestroyI2CDevRec(I2CDevPtr d, Bool unalloc)
 {
 if (d) {
-I2CDevPtr *p;
+if (d->pI2CBus) {
+I2CDevPtr *p;

-/* Remove this from the list of active I2C devices. */
+/* Remove this from the list of active I2C devices. */

-for (p = >pI2CBus->FirstDev; *p != NULL; p = &(*p)->NextDev)
-if (*p == d) {
-*p = (*p)->NextDev;
-break;
-}
+for (p = >pI2CBus->FirstDev; *p != NULL; p = &(*p)->NextDev)
+if (*p == d) {
+*p = (*p)->NextDev;
+break;
+}

-xf86DrvMsg(d->pI2CBus->scrnIndex, X_INFO,
-   "I2C device \"%s:%s\" removed.\n",
-   d->pI2CBus->BusName, d->DevName);
+xf86DrvMsg(d->pI2CBus->scrnIndex, X_INFO,
+   "I2C device \"%s:%s\" removed.\n",
+   d->pI2CBus->BusName, d->DevName);
+}

 if (unalloc)
 free(d);


___
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


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

[Matthieu Herrb]

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.

diff --git a/glamor/glamor.c b/glamor/glamor.c
index 903f6bd..915c8a7 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -848,8 +848,6 @@ glamor_name_from_pixmap(PixmapPtr pixmap, CARD16 *stride, 
CARD32 *size)
 glamor_screen_private *glamor_priv =
 glamor_get_screen_private(pixmap->drawable.pScreen);
 
-if (!glamor_priv->dri3_enabled)
-return -1;
 switch (pixmap_priv->type) {
 case GLAMOR_TEXTURE_DRM:
 case GLAMOR_TEXTURE_ONLY:


> 
> The linked to patch LGTM and is:
> 
> Reviewed-by: Hans de Goede 
> 
> Regards,
> 
> Hans

-- 
Matthieu Herrb


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: xfree86: Fix null pointer dereference

[Eric Engestrom]

On Fri, Sep 23, 2016 at 03:12:18PM +0300, Hans de Goede wrote:
> Hi,
> 
> On 01/13/2016 07:47 AM, Kyle Guinn wrote:
> > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=93675
> > 
> > Signed-off-by: Kyle Guinn 
> 
> Thanks for the patch, I've queued this up at:
> 
> https://cgit.freedesktop.org/~jwrdegoede/xserver
> 
> For a 1.19 bug-fix pull-req I'm preparing at.
> 
> Note I've simplified the patch to:
> 
> -if (d) {
> +if (d && d->pI2CBus) {
> 
> Instead of the nested ifs you used, still many thanks
> for tracking this crashed down!

I find this better too, but if you do that you need to move

if (unalloc)
free(d);

out of that `if (d && d->pI2CBus)` :)

(It had no reason to be there in the first place anyway, as free(NULL) is safe)

Cheers,
  Eric

> 
> Regards,
> 
> Hans
> 
> 
> 
> > ---
> >  hw/xfree86/i2c/xf86i2c.c | 22 --
> >  1 file changed, 12 insertions(+), 10 deletions(-)
> > 
> > diff --git a/hw/xfree86/i2c/xf86i2c.c b/hw/xfree86/i2c/xf86i2c.c
> > index 2a8b8df..62b647c 100644
> > --- a/hw/xfree86/i2c/xf86i2c.c
> > +++ b/hw/xfree86/i2c/xf86i2c.c
> > @@ -615,19 +615,21 @@ void
> >  xf86DestroyI2CDevRec(I2CDevPtr d, Bool unalloc)
> >  {
> >  if (d) {
> > -I2CDevPtr *p;
> > +if (d->pI2CBus) {
> > +I2CDevPtr *p;
> > 
> > -/* Remove this from the list of active I2C devices. */
> > +/* Remove this from the list of active I2C devices. */
> > 
> > -for (p = >pI2CBus->FirstDev; *p != NULL; p = &(*p)->NextDev)
> > -if (*p == d) {
> > -*p = (*p)->NextDev;
> > -break;
> > -}
> > +for (p = >pI2CBus->FirstDev; *p != NULL; p = &(*p)->NextDev)
> > +if (*p == d) {
> > +*p = (*p)->NextDev;
> > +break;
> > +}
> > 
> > -xf86DrvMsg(d->pI2CBus->scrnIndex, X_INFO,
> > -   "I2C device \"%s:%s\" removed.\n",
> > -   d->pI2CBus->BusName, d->DevName);
> > +xf86DrvMsg(d->pI2CBus->scrnIndex, X_INFO,
> > +   "I2C device \"%s:%s\" removed.\n",
> > +   d->pI2CBus->BusName, d->DevName);
> > +}
> > 
> >  if (unalloc)
> >  free(d);
> > 
___
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: Do not call drmModeSetCursor2() twice on every cursor change

[Michael Thayer]

Each xf86ScreenSetCursor() call calls:

xf86DriverLoadCursorARGB()
infoPtr->ShowCursor()

In succession, ending up in 2 drmModeSetCursor2() calls, with the second
effectively being a no-op. Keep track of having set the cursor already
in drmmode_load_cursor_argb_check() and unless hide() was called in
the mean time make drmmode_show_cursor() a no-op.

Signed-off-by: Hans de Goede 
---
Note this patch applies on top of Michael Thayer's
"modesetting: allow switching from software to hardware cursors (v4)"
series


Sorry about this, for some reason this and a few other messages did not 
make it to my mailbox.  Looks good to me, but if you like I can apply it 
when I have time and check in gdb that it does what it says on the box.


Otherwise,

Reviewed-by: Michael Thayer 

Regards,

Michael


---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 7 ++-
 hw/xfree86/drivers/modesetting/drmmode_display.h | 1 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 46e981b..23c1db1 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -783,6 +783,8 @@ drmmode_set_cursor(xf86CrtcPtr crtc)
 if (ret)
 /* fallback to swcursor */
 return FALSE;
+
+drmmode_crtc->cursor_up = TRUE;
 return TRUE;
 }

@@ -817,6 +819,7 @@ drmmode_hide_cursor(xf86CrtcPtr crtc)
 drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
 drmmode_ptr drmmode = drmmode_crtc->drmmode;

+drmmode_crtc->cursor_up = FALSE;
 drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, 0,
  ms->cursor_width, ms->cursor_height);
 }
@@ -825,7 +828,9 @@ static void
 drmmode_show_cursor(xf86CrtcPtr crtc)
 {
 drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
-drmmode_set_cursor(crtc);
+
+if (!drmmode_crtc->cursor_up)
+drmmode_set_cursor(crtc);
 }

 static void
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.h 
b/hw/xfree86/drivers/modesetting/drmmode_display.h
index f979b99..f774250 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.h
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.h
@@ -91,6 +91,7 @@ typedef struct {
 uint32_t vblank_pipe;
 int dpms_mode;
 struct dumb_bo *cursor_bo;
+Bool cursor_up;
 uint16_t lut_r[256], lut_g[256], lut_b[256];

 drmmode_bo rotate_bo;
--
2.9.3


--
Michael Thayer | VirtualBox engineer
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister 
der Handelskammer Midden-Nederland, Nr. 30143697

Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
___
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 1/2] Xext: Fix a memory leak

[Emil Velikov]

On 23 September 2016 at 12:50, Hans de Goede  wrote:
> Based on: https://patchwork.freedesktop.org/patch/85636/
>
> Rewritten to also free the resources allocated by
> panoramix_setup_ids().
>
The codeflow is a bit nasty to read, but the patch is perfectly correct.

Reviewed-by: Emil Velikov 

-Emil
___
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 05/10 v2] test: Add a little xinit-like program for starting servers for testing.

[Julien Cristau]

On Fri, Sep 23, 2016 at 10:58:54 +0300, Eric Anholt wrote:

> 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.
> 
> Signed-off-by: Eric Anholt 
> ---
>  test/.gitignore |   1 +
>  test/Makefile.am|  13 ++-
>  test/simple-xinit.c | 223 
> 
>  3 files changed, 233 insertions(+), 4 deletions(-)
>  create mode 100644 test/simple-xinit.c
> 
Two other things I noticed:
- lack of error checking for fork()
- this allocation:
> +char **args_storage = calloc(argc + 2, sizeof(char **));
  should be calloc(argc + 2, sizeof(char *))
  (no actual difference, though, so meh)

Other than that the series looks good to me.

Cheers,
Julien
___
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

[Aaron Plattner]

On 09/22/2016 04:30 PM, Bob Terek wrote:
> On 09/21/2016 10:22 AM, Aaron Plattner wrote:
>> On 09/20/2016 02:07 AM, Eric Engestrom wrote:
>>> On Tue, Sep 20, 2016 at 01:34:40PM +0700, Antoine Martin wrote:
 Signed-off-by: Antoine Martin 
>>>
>>> Reviewed-by: Eric Engestrom 
>>
>> Looks good to me too (although I'm cheating since this chunk is
>> identical to part of
>> https://patchwork.freedesktop.org/patch/41058/)
> 
> 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?

> 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.

> -- 
> 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 1/1] Simplify, statement is always true.

[Aaron Plattner]

On 09/21/2016 05:08 PM, Maya Rashish wrote:
> pVideo->bus is uint8_t, always less than 256.
> 
> Signed-off-by: Maya Rashish 
> ---
>  hw/xfree86/common/xf86pciBus.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/hw/xfree86/common/xf86pciBus.c b/hw/xfree86/common/xf86pciBus.c
> index 8158c2b..bed4434 100644
> --- a/hw/xfree86/common/xf86pciBus.c
> +++ b/hw/xfree86/common/xf86pciBus.c
> @@ -1457,11 +1457,7 @@ xf86PciConfigureNewDev(void *busData, struct 
> pci_device *pVideo,
>  
>  pVideo = (struct pci_device *) busData;
>  
> -if (pVideo->bus < 256)
> -snprintf(busnum, sizeof(busnum), "%d", pVideo->bus);
> -else
> -snprintf(busnum, sizeof(busnum), "%d@%d",
> - pVideo->bus & 0x00ff, pVideo->bus >> 8);
> +snprintf(busnum, sizeof(busnum), "%d", pVideo->bus);
>  
>  XNFasprintf(, "PCI:%s:%d:%d",
>  busnum, pVideo->dev, pVideo->func);
> 

Presumably this was to handle the old-style encoding of PCI domain into
the bus field -- we don't want to just drop the bus entirely, right? So
this should probably be

  if (pVideo->domain > 0)
  snprintf(busnum, sizeof(busnum), "%d@%d", pVideo->bus,
pVideo->domain);
  else
  snprintf(busnum, sizeof(busnum), "%d", pVideo->bus);

-- Aaron
___
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 05/10] test: Add a little xinit-like program for starting servers for testing.

[Ray Strode]

Hey cool,

On Friday, September 23, 2016, Eric Anholt  wrote:
>
> 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.

Any chance you want to work on the xinit changes proposed here?
https://lists.x.org/archives/xorg-devel/2015-March/045948.html

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