[PATCH xserver] glamor: use drmGetDeviceNameFromFD2 when available

2017-03-06 Thread Qiang Yu 
This is for glamor can support fd from DRM render node
which is useful for a render only DDX.

Signed-off-by: Qiang Yu 
---
 configure.ac| 3 +++
 glamor/glamor_egl.c | 4 
 include/dix-config.h.in | 3 +++
 3 files changed, 10 insertions(+)

diff --git a/configure.ac b/configure.ac
index 110027d..ac11e65 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2166,6 +2166,9 @@ if test "x$GLAMOR" = xyes; then
AC_MSG_ERROR([Glamor for Xorg requires $LIBGBM])
fi
fi
+
+   PKG_CHECK_MODULES(LIBDRM, "libdrm >= 2.4.74",
+   [AC_DEFINE(GLAMOR_HAS_DRM_NAME_FROM_FD_2, 1, [Have 
GLAMOR_HAS_DRM_NAME_FROM_FD_2])], [])
 fi
 AM_CONDITIONAL([GLAMOR_EGL], [test "x$GBM" = xyes])
 
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index 4bde637..ca94227 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -685,7 +685,11 @@ glamor_egl_screen_init(ScreenPtr screen, struct 
glamor_context *glamor_ctx)
 /* To do DRI3 device FD generation, we need to open a new fd
  * to the same device we were handed in originally.
  */
+#ifdef GLAMOR_HAS_DRM_NAME_FROM_FD_2
+glamor_egl->device_path = drmGetDeviceNameFromFd2(glamor_egl->fd);
+#else
 glamor_egl->device_path = drmGetDeviceNameFromFd(glamor_egl->fd);
+#endif
 
 if (!dri3_screen_init(screen, _dri3_info)) {
 xf86DrvMsg(scrn->scrnIndex, X_ERROR,
diff --git a/include/dix-config.h.in b/include/dix-config.h.in
index d357910..c3f956d 100644
--- a/include/dix-config.h.in
+++ b/include/dix-config.h.in
@@ -518,6 +518,9 @@
 /* Build glamor/gbm has linear support */
 #undef GLAMOR_HAS_GBM_LINEAR
 
+/* Build glamor use new drmGetDeviceNameFromFD2 */
+#undef GLAMOR_HAS_DRM_NAME_FROM_FD_2
+
 /* byte order */
 #undef X_BYTE_ORDER
 
-- 
2.7.4

___
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 xf86-video-dummy] Add glamor acceleration which enables native OpenGL support

2017-03-06 Thread Qiang Yu 
Enable glamor acceleration in xorg.conf by:
Section "Device"
  ...
  Driver "dummy"
  Option "Render" "/dev/dri/renderD128"
  ...
EndSection

GPU is chosen by the Render option which specifies the render
node of the GPU DRM device.

We could use the dumb buffer instead of gbm buffer as the
screen front buffer. But dumb buffer requires open
/dev/dri/cardx which has the limitation of only one instance
of OpenGL enabled xserver can start.

With gbm buffer, we can use /dev/dri/renderDx which has no
limitation on the number of OpenGL enabled xserver and even
won't conflict with a "real" xserver using radeon/amdgpu DDX.

Due to using renderDx, only DRI3 OpenGL is supported.

DGA is disabled when glamor is enabled, we can enable it with
new gbm_bo_map/unmap API, but consider a more effiction way
is just using DRI3BufferFromPixmap for the root window pixmap.

Signed-off-by: Qiang Yu 
---
 configure.ac   |  26 ++
 src/Makefile.am|   7 ++-
 src/dummy.h|   9 
 src/dummy_dga.c|   3 ++
 src/dummy_driver.c | 143 -
 5 files changed, 176 insertions(+), 12 deletions(-)

diff --git a/configure.ac b/configure.ac
index 4eb7fae..7239b63 100644
--- a/configure.ac
+++ b/configure.ac
@@ -68,6 +68,32 @@ AM_CONDITIONAL([DGA], [test "x$DGA" = xyes])
 # Obtain compiler/linker options for the driver dependencies
 PKG_CHECK_MODULES(XORG, [xorg-server >= 1.4.99.901] xproto fontsproto 
$REQUIRED_MODULES)
 
+# Check glamor support
+AC_ARG_ENABLE(glamor,
+ AS_HELP_STRING([--disable-glamor],
+[Disable glamor, a new GL-based acceleration 
[default=enabled]]),
+ [GLAMOR="$enableval"],
+ [GLAMOR=yes])
+
+SAVE_CPPFLAGS="$CPPFLAGS"
+CPPFLAGS="$CPPFLAGS $XORG_CFLAGS"
+if test "x$GLAMOR" != "xno"; then
+   AC_CHECK_HEADERS([glamor.h], , [GLAMOR=no], [#include "xorg-server.h"])
+fi
+CPPFLAGS="$SAVE_CPPFLAGS"
+
+if test "x$GLAMOR" != "xno"; then
+   PKG_CHECK_MODULES(GBM, [gbm], , [GLAMOR=no])
+fi
+
+AC_MSG_CHECKING([whether to include GLAMOR support])
+AC_MSG_RESULT([$GLAMOR])
+
+if test "x$GLAMOR" != "xno"; then
+AC_DEFINE(USE_GLAMOR, 1, [Enable glamor acceleration])
+fi
+AM_CONDITIONAL(GLAMOR, test x$GLAMOR != xno)
+
 # Checks for libraries.
 
 
diff --git a/src/Makefile.am b/src/Makefile.am
index da1dd9a..9faa9c4 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -25,7 +25,7 @@
 # _ladir passes a dummy rpath to libtool so the thing will actually link
 # TODO: -nostdlib/-Bstatic/-lgcc platform magic, not installing the .a, etc.
 
-AM_CFLAGS = $(XORG_CFLAGS) $(PCIACCESS_CFLAGS)
+AM_CFLAGS = $(XORG_CFLAGS)
 
 dummy_drv_la_LTLIBRARIES = dummy_drv.la
 dummy_drv_la_LDFLAGS = -module -avoid-version
@@ -38,6 +38,11 @@ dummy_drv_la_SOURCES = \
  dummy_driver.c \
  dummy.h
 
+if GLAMOR
+AM_CFLAGS += $(GBM_CFLAGS)
+dummy_drv_la_LIBADD += $(GBM_LIBS)
+endif
+
 if DGA
 dummy_drv_la_SOURCES +=\
  dummy_dga.c
diff --git a/src/dummy.h b/src/dummy.h
index c3fdd6e..1eecdec 100644
--- a/src/dummy.h
+++ b/src/dummy.h
@@ -42,6 +42,9 @@ typedef struct _color
 int blue;
 } dummy_colors;
 
+struct gbm_device;
+struct gbm_bo;
+
 typedef struct dummyRec 
 {
 DGAModePtr DGAModes;
@@ -72,6 +75,12 @@ typedef struct dummyRec
 pointer* FBBase;
 Bool(*CreateWindow)() ; /* wrapped CreateWindow */
 Bool prop;
+
+/* DRI support */
+int fd;
+CreateScreenResourcesProcPtr createScreenResources;
+struct gbm_device *gbm;
+struct gbm_bo *front_bo;
 } DUMMYRec, *DUMMYPtr;
 
 /* The privates of the DUMMY driver */
diff --git a/src/dummy_dga.c b/src/dummy_dga.c
index d16d09f..8335874 100644
--- a/src/dummy_dga.c
+++ b/src/dummy_dga.c
@@ -165,6 +165,9 @@ DUMMY_OpenFramebuffer(
 ){
 DUMMYPtr pDUMMY = DUMMYPTR(pScrn);
 
+if (pDUMMY->FBBase == NULL)
+   return FALSE;
+
 *name = NULL;  /* no special device */
 *mem = (unsigned char*)pDUMMY->FBBase;
 *size = pScrn->videoRam * 1024;
diff --git a/src/dummy_driver.c b/src/dummy_driver.c
index 2656602..174695c 100644
--- a/src/dummy_driver.c
+++ b/src/dummy_driver.c
@@ -49,6 +49,15 @@
 #include 
 #endif
 
+#ifdef USE_GLAMOR
+#define GLAMOR_FOR_XORG
+#include 
+#include 
+#endif
+
+#include 
+#include 
+
 /* Mandatory functions */
 static const OptionInfoRec *   DUMMYAvailableOptions(int chipid, int busid);
 static void DUMMYIdentify(int flags);
@@ -115,11 +124,13 @@ static SymTabRec DUMMYChipsets[] = {
 };
 
 typedef enum {
-OPTION_SW_CURSOR
+OPTION_SW_CURSOR,
+OPTION_RENDER,
 } DUMMYOpts;
 
 static const OptionInfoRec DUMMYOptions[] = {
 { OPTION_SW_CURSOR,"SWcursor", OPTV_BOOLEAN,   {0}, FALSE },
+{ OPTION_RENDER,   "Render",   OPTV_STRING,{0}, FALSE },
 { -1,  NULL,   OPTV_NONE,  {0}, FALSE }
 };
 
@@ -189,15 +200,21 @@ DUMMYGetRec(ScrnInfoPtr pScrn)
 
 if

Re: [PATCH xserver 2/2] glamor: Always purge the FBO cache in BlockHandler

2017-03-06 Thread Michel Dänzer 
On 07/03/17 03:02 AM, Eric Anholt wrote:
> Michel Dänzer  writes:
> 
>> From: Michel Dänzer 
>>
>> Or if the cache watermark is reached, whichever comes earlier.
>>
>> This slightly simplifies the FBO cache management, and prevents it from
>> potentially holding entries for a long time, while preserving the main
>> benefit of the cache for bursts of drawing operations.
>>
>> Signed-off-by: Michel Dänzer 
> 
> For re-adding an FBO cache, I would need to see that we have
> APPLE_object_purgeable used so that the FBO cache can be evicted, and
> use proper timers to garbage collect the FBOs instead of waiting for N
> blockhandlers, which is only vaguely related to wall time.

Right, I already came to the conclusion that a time based expiry
mechanism would be needed (limiting until the next BlockHandler as in
patch 2 actually seems too restrictive and still results in some minor
regressions).

I'll play around some more to see if we can make do without the glamor
FBO cache, and take your feedback and Max's into account otherwise, thanks.


-- 
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: [ANNOUNCE] xorg-server 1.19.2

2017-03-06 Thread Adam Jackson 
On Fri, 2017-03-03 at 17:32 -0800, Jeremy Huddleston Sequoia wrote:
> What do you propose instead of autotools?  I agree that it is utter
> garbage, and I dislike the license ... but I certainly don't like any
> of the alternatives either.  CMake, JAM, and the rest are pretty much
> all crap for one reason or another.  And hopefully you agree that
> it's at least leagues better than imake!  If there was a good
> alternative, I'd be happy to help with transitioning us away from
> autotools, but I just don't see any good option.

I wasn't really proposing anything. But if I had to, in rough order of
preference: meson, gnu make, portable make subset.

- 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: [RFC PATCH xserver] xwayland: make sure client is not gone in sync callback

2017-03-06 Thread Adam Jackson 
On Mon, 2017-03-06 at 09:32 -0500, Olivier Fourdan wrote:

> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=100040
> Tested-by: Mark B 

remote: I: patch #141671 updated using rev 
64ca14b85e45b13628396f21d1903e311f92a9e1.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   5c44169..64ca14b  master -> master

- 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] sdksyms: Tighten up the symbols we add to the magic table

2017-03-06 Thread Adam Jackson 
On Mon, 2017-03-06 at 18:23 +, Jon Turney wrote:

> Unfortunately, one of the possible definitions of _X_EXPORT in 
> Xfuncproto.h is empty, in which case, this leaves us with nothing in 
> sdksyms.c

Though this be true, I'm not sure how it can matter. We only build
xfree86 on systems where _X_EXPORT expands to something non-empty. And
we rely on it expanding to something non-empty because we build the
rest of the server with hidden visibility, so we need a positive way to
declare that a symbol is exported; if the system does not have this
facility, then the server isn't going to export the correct set of
symbols to the drivers anyway.

- 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 1/2] Revert "glamor: Remove the FBO cache."

2017-03-06 Thread Marek Olšák 
On Fri, Mar 3, 2017 at 9:46 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> This reverts commit 950ffb8d6fd1480f305e38c571bda44f247f1de2 (and parts
> of commit 4b5326aeba539249fcded91bf7806a708eeca651).
>
> It halved (or worse) the performance with some x11perf tests on
> radeonsi, even though radeonsi has a BO cache.
>
> Signed-off-by: Michel Dänzer 
> ---
>
> I suspect the reason why radeonsi's BO cache can't make up for the lack of
> the glamor FBO cache is that the former can only return idle BOs. So
> while the glamor FBO cache allows re-using the same FBO over and over
> for a series of operations using temporary pixmaps of the same size, the
> radeonsi BO cache has to keep using different BOs until a command stream
> is flushed to the GPU and processed by it.

I don't think the radeonsi cache is sufficient here. It only hides the
kernel overhead. It doesn't hide any overhead of Mesa itself.

Marek
___
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] sdksyms: Tighten up the symbols we add to the magic table

2017-03-06 Thread Jon Turney 

On 16/02/2017 19:00, Adam Jackson wrote:

The code as written would match anything declared extern. _X_EXPORT is
what we really mean here. That's a macro, so check for what it expands
to and skip if not found.
---
 hw/xfree86/sdksyms.sh | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/xfree86/sdksyms.sh b/hw/xfree86/sdksyms.sh
index cf26892..10909d0 100755
--- a/hw/xfree86/sdksyms.sh
+++ b/hw/xfree86/sdksyms.sh
@@ -343,6 +343,10 @@ BEGIN {
n = 1;
 }

+# only match _X_EXPORT
+if ($n !~ /^(__attribute__..visibility..default|__global)/)
+next;
+
# skip attribute, if any
while ($n ~ /^(__attribute__|__global)/ ||
# skip modifiers, if any



Unfortunately, one of the possible definitions of _X_EXPORT in 
Xfuncproto.h is empty, in which case, this leaves us with nothing in 
sdksyms.c


This would be much easier if we could use -fdirectives-only, but I guess 
this needs to be cpp-agnostic.


Not sure how to fix this short of having a define to make Xfuncproto.h 
not define the _X_EXPORT macro, and turning that on when sdksyms.sh 
invokes cpp, and having sdksyms.sh recognize a literal X_EXPORT...


___
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] glamor: Always purge the FBO cache in BlockHandler

2017-03-06 Thread Eric Anholt 
Michel Dänzer  writes:

> From: Michel Dänzer 
>
> Or if the cache watermark is reached, whichever comes earlier.
>
> This slightly simplifies the FBO cache management, and prevents it from
> potentially holding entries for a long time, while preserving the main
> benefit of the cache for bursts of drawing operations.
>
> Signed-off-by: Michel Dänzer 

For re-adding an FBO cache, I would need to see that we have
APPLE_object_purgeable used so that the FBO cache can be evicted, and
use proper timers to garbage collect the FBOs instead of waiting for N
blockhandlers, which is only vaguely related to wall time.


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] Workaround a sdksyms problem with gcc5 on Cygwin

2017-03-06 Thread Jon Turney 
The linemarkers in the preprocessor output from gcc5 on Cygwin have
canonicalized paths to included files (e.g. xserver/build/../include/misc.h
is canonicalized to xserver/build/include/misc.h). (see gcc svn rev 210264,
which causes the transformation performed by -fcanonical-system-headers to
be applied to all include pathnames)

These canonicalized paths won't match $topdir, so sdksyms doesn't look at
the contents of those headers for sdk exported symbols.

Workaround this by canonicalizing all the paths we consider, using readlink.

v2:
Keep a cache of readlink results so it isn't quite so dreadfully slow.
---
 hw/xfree86/sdksyms.sh | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/hw/xfree86/sdksyms.sh b/hw/xfree86/sdksyms.sh
index 10909d0..767ce21 100755
--- a/hw/xfree86/sdksyms.sh
+++ b/hw/xfree86/sdksyms.sh
@@ -296,7 +296,7 @@ cat > sdksyms.c << EOF
 
 EOF
 
-topdir=$1
+topdir=$(readlink -f $1)
 shift
 LC_ALL=C
 export LC_ALL
@@ -314,11 +314,24 @@ BEGIN {
 printf("sdksyms.c:") > "sdksyms.dep";
 }
 /^# [0-9]+ "/ {
-#   Process text after a include in a relative path or when the
-# processed file has a basename matching $top_srcdir.
-#   Note that indexing starts at 1; 0 means no match, and there
-# is a starting ".
-sdk = $3 !~ /^"\// || index($3, topdir) == 2;
+# Match preprocessor linemarkers which have the form:
+# # linenum "filename" flags
+#
+# Only process text for sdk exports where the linemarker filename has a
+# relative path, or an absolute path matching $top_srcdir.
+#
+
+# canonicalize filename
+if ($3 in canonicalized) {
+   c = canonicalized[$3]
+} else {
+   cmd = "readlink -f " $3
+   cmd | getline c
+   close(cmd)
+canonicalized[$3] = c
+}
+# note that index() starts at 1; 0 means no match.
+sdk = $3 !~ /^"\// || index(c, topdir) == 1;
 
 if (sdk && $3 ~ /\.h"$/) {
# remove quotes
-- 
2.8.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] xwayland: clear cursor frame callback

2017-03-06 Thread Pekka Paalanen 
On Mon,  6 Mar 2017 15:03:53 +0100
Olivier Fourdan  wrote:

> After an X cursor is unrealized, the seat's corresponding x_cursor is
> cleared, but if a frame callback was pending at the time, it will
> remain and thus prevent any further cursor update, leaving the window
> with no cursor.
> 
> Make sure to destroy the frame callback if any when that occurs, so that
> next time a cursor needs to be set, it won't be ignored for a frame
> callback that will never be triggered.
> 
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1389327
> Signed-off-by: Olivier Fourdan 
> ---
>  hw/xwayland/xwayland-cursor.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/xwayland/xwayland-cursor.c b/hw/xwayland/xwayland-cursor.c
> index 0c1cd34..12d1fe1 100644
> --- a/hw/xwayland/xwayland-cursor.c
> +++ b/hw/xwayland/xwayland-cursor.c
> @@ -96,14 +96,22 @@ xwl_unrealize_cursor(DeviceIntPtr device, ScreenPtr 
> screen, CursorPtr cursor)
>  }
>  
>  static void
> +clear_frame_callback(struct xwl_seat *xwl_seat)
> +{
> +   if (xwl_seat->cursor_frame_cb) {
> +   wl_callback_destroy (xwl_seat->cursor_frame_cb);
> +   xwl_seat->cursor_frame_cb = NULL;
> +   }
> +}
> +
> +static void
>  frame_callback(void *data,
> struct wl_callback *callback,
> uint32_t time)
>  {
>  struct xwl_seat *xwl_seat = data;
>  
> -wl_callback_destroy (xwl_seat->cursor_frame_cb);
> -xwl_seat->cursor_frame_cb = NULL;
> +clear_frame_callback(xwl_seat);
>  if (xwl_seat->cursor_needs_update) {
>  xwl_seat->cursor_needs_update = FALSE;
>  xwl_seat_set_cursor(xwl_seat);
> @@ -127,6 +135,8 @@ xwl_seat_set_cursor(struct xwl_seat *xwl_seat)
>  if (!xwl_seat->x_cursor) {
>  wl_pointer_set_cursor(xwl_seat->wl_pointer,
>xwl_seat->pointer_enter_serial, NULL, 0, 0);
> +clear_frame_callback(xwl_seat);
> +xwl_seat->cursor_needs_update = FALSE;
>  return;
>  }
>  

Hi,

the rationale sounds good to me, and the code looks fine though I have
not checked the surrounding code not shown in the patch context.

Would it be better to call it clear_cursor_frame_callback() instead?

In any case:
Reviewed-by: Pekka Paalanen 


Thanks,
pq


pgpPZukoJDo_V.pgp
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: [RFC PATCH xserver] xwayland: make sure client is not gone in sync callback

2017-03-06 Thread Olivier Fourdan 
> in XWayland, dri3_send_open_reply() is called from a sync callback, so
> there is a possibility that the client might be gone when we get to the
> callback eventually, which leads to a crash in _XSERVTransSendFd() from
> WriteFdToClient() .
> 
> Check if clientGone has been set in the sync callback handler to avoid
> this.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99149
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1416553
> Signed-off-by: Olivier Fourdan 
> ---
>  This seems to be a fairly rare occurence, but we do have bugs filed both
>  upstream and downstream for this.
>  I don't have any core file unfortunately so this is based solely on
>  the addresses returned by the crash handler, thus the "RFC" on this
>  patch...
> 
>  hw/xwayland/xwayland-glamor.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
> index b3d0aab..65c3c00 100644
> --- a/hw/xwayland/xwayland-glamor.c
> +++ b/hw/xwayland/xwayland-glamor.c
> @@ -435,9 +435,12 @@ static void
>  sync_callback(void *data, struct wl_callback *callback, uint32_t serial)
>  {
>  struct xwl_auth_state *state = data;
> +ClientPtr client = state->client;
>  
> -dri3_send_open_reply(state->client, state->fd);
> -AttendClient(state->client);
> +if (!client->clientGone) {
> +dri3_send_open_reply(client, state->fd);
> +AttendClient(client);
> +}
>  free(state);
>  wl_callback_destroy(callback);
>  }
> --

The fix has been succesfully tested in bug 100040

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=100040
Tested-by: Mark B 
___
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] xwayland: clear cursor frame callback

2017-03-06 Thread Olivier Fourdan 
After an X cursor is unrealized, the seat's corresponding x_cursor is
cleared, but if a frame callback was pending at the time, it will
remain and thus prevent any further cursor update, leaving the window
with no cursor.

Make sure to destroy the frame callback if any when that occurs, so that
next time a cursor needs to be set, it won't be ignored for a frame
callback that will never be triggered.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1389327
Signed-off-by: Olivier Fourdan 
---
 hw/xwayland/xwayland-cursor.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/hw/xwayland/xwayland-cursor.c b/hw/xwayland/xwayland-cursor.c
index 0c1cd34..12d1fe1 100644
--- a/hw/xwayland/xwayland-cursor.c
+++ b/hw/xwayland/xwayland-cursor.c
@@ -96,14 +96,22 @@ xwl_unrealize_cursor(DeviceIntPtr device, ScreenPtr screen, 
CursorPtr cursor)
 }
 
 static void
+clear_frame_callback(struct xwl_seat *xwl_seat)
+{
+   if (xwl_seat->cursor_frame_cb) {
+   wl_callback_destroy (xwl_seat->cursor_frame_cb);
+   xwl_seat->cursor_frame_cb = NULL;
+   }
+}
+
+static void
 frame_callback(void *data,
struct wl_callback *callback,
uint32_t time)
 {
 struct xwl_seat *xwl_seat = data;
 
-wl_callback_destroy (xwl_seat->cursor_frame_cb);
-xwl_seat->cursor_frame_cb = NULL;
+clear_frame_callback(xwl_seat);
 if (xwl_seat->cursor_needs_update) {
 xwl_seat->cursor_needs_update = FALSE;
 xwl_seat_set_cursor(xwl_seat);
@@ -127,6 +135,8 @@ xwl_seat_set_cursor(struct xwl_seat *xwl_seat)
 if (!xwl_seat->x_cursor) {
 wl_pointer_set_cursor(xwl_seat->wl_pointer,
   xwl_seat->pointer_enter_serial, NULL, 0, 0);
+clear_frame_callback(xwl_seat);
+xwl_seat->cursor_needs_update = FALSE;
 return;
 }
 
-- 
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