Re-send: [PATCH] modesetting: allow switching from software to hardware cursors.

[Michael Thayer]

Currently if modesetting ever fails to set a hardware cursor it will switch
to using a software cursor and never go back.  Change this to try a hardware
cursor first every time a new one is set.  This is needed because hardware
may be able to handle some cursors in harware and others not, or virtual
hardware may be able to handle hardware cursors at some times and not 
others.


Signed-off-by: Michael Thayer 
---
Re-sending as this did not seem to get noticed much the first time.

 hw/xfree86/drivers/modesetting/drmmode_display.c | 47 
++--

 1 file changed, 20 insertions(+), 27 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c

index 0d34ca1..36c3093 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -485,44 +485,36 @@ drmmode_set_cursor_position(xf86CrtcPtr crtc, int 
x, int y)
 drmModeMoveCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, 
x, y);

 }
 -static void
+static Bool
 drmmode_set_cursor(xf86CrtcPtr crtc)
 {
 drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
 drmmode_ptr drmmode = drmmode_crtc->drmmode;
 uint32_t handle = drmmode_crtc->cursor_bo->handle;
 modesettingPtr ms = modesettingPTR(crtc->scrn);
-static Bool use_set_cursor2 = TRUE;
 int ret;
 -if (use_set_cursor2) {
-xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
-CursorPtr cursor = xf86_config->cursor;
-
-ret =
-drmModeSetCursor2(drmmode->fd, 
drmmode_crtc->mode_crtc->crtc_id,

-  handle, ms->cursor_width, ms->cursor_height,
-  cursor->bits->xhot, cursor->bits->yhot);
-if (!ret)
-return;
-if (ret == -EINVAL)
-use_set_cursor2 = FALSE;
-}
+xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
+CursorPtr cursor = xf86_config->cursor;
 -ret = drmModeSetCursor(drmmode->fd, 
drmmode_crtc->mode_crtc->crtc_id, handle,

-   ms->cursor_width, ms->cursor_height);
+ret =
+drmModeSetCursor2(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
+  handle, ms->cursor_width, ms->cursor_height,
+  cursor->bits->xhot, cursor->bits->yhot);
+if (!ret)
+return TRUE;
 -if (ret) {
-xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
-xf86CursorInfoPtr cursor_info = xf86_config->cursor_info;
+/* -EINVAL can mean bad cursor parameters or Cursor2 API not 
supported. */

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

 -cursor_info->MaxWidth = cursor_info->MaxHeight = 0;
-drmmode_crtc->drmmode->sw_cursor = TRUE;
-/* fallback to swcursor */
-}
+if (ret)
+return FALSE; /* fallback to swcursor */
+return TRUE;
 }
 -static void
+static Bool
 drmmode_load_cursor_argb(xf86CrtcPtr crtc, CARD32 *image)
 {
 modesettingPtr ms = modesettingPTR(crtc->scrn);
@@ -537,7 +529,8 @@ drmmode_load_cursor_argb(xf86CrtcPtr crtc, CARD32 
*image)

 ptr[i] = image[i];  // cpu_to_le32(image[i]);
  if (drmmode_crtc->cursor_up)
-drmmode_set_cursor(crtc);
+return drmmode_set_cursor(crtc);
+return TRUE;
 }
  static void
@@ -799,7 +792,7 @@ static const xf86CrtcFuncsRec drmmode_crtc_funcs = {
 .set_cursor_position = drmmode_set_cursor_position,
 .show_cursor = drmmode_show_cursor,
 .hide_cursor = drmmode_hide_cursor,
-.load_cursor_argb = drmmode_load_cursor_argb,
+.load_cursor_argb_check = drmmode_load_cursor_argb,
  .gamma_set = drmmode_crtc_gamma_set,
 .destroy = NULL,/* XXX */
--
2.5.0

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

[Bug 94414] Radeon RV370 w/ acceleration enabled exhibits problem with resolutions above 1440x900

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 QA Contact|xorg-t...@lists.x.org   |dri-devel@lists.freedesktop
   ||.org
  Component|Driver/Radeon   |Drivers/Gallium/r300
Product|xorg|Mesa
   Assignee|xorg-driver-ati@lists.x.org |dri-devel@lists.freedesktop
   ||.org

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 94414] Radeon RV370 w/ acceleration enabled exhibits problem with resolutions above 1440x900

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #122194|text/plain  |image/png
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 32789] [RADEON:KMS:DDX] VSync loss after rotation to portrait mode

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #14 from Michel Dänzer  ---
With
https://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=798c4fd16d339b1ad5fd729cc884be084c60e38b
(and xserver >= 1.16), Option "TearFree" eliminates tearing with rotation.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 90789] Vsync doesn't work for rotated display

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Michel Dänzer  ---
With
https://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=798c4fd16d339b1ad5fd729cc884be084c60e38b
(and xserver >= 1.16), Option "TearFree" eliminates tearing with rotation.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Re: [PATCH] [RFC] glamor: implement write-only prepares

[Michel Dänzer]

On 10.03.2016 10:51, Dave Airlie wrote:
> From: Dave Airlie 
> 
> For some putimages we know we won't ever care about the data we readback,
> we are going to trash it with the putimage contents. So implement
> GLAMOR_ACCESS_WO mode.
> 
> This will avoid doing the readbacks. Use it for putimages that are copy
> with a solid planemask.
> 
> inspired by Ilia and xlock -mode wator which does loads of XYBitmap
> putimages.
> 
> Signed-off-by: Dave Airlie 

Maybe you can also take some inspiration from
https://patchwork.freedesktop.org/patch/31020/ : In
glamor_prep_pixmap_box, it updated the access check and used
GL_STREAM_DRAW for GLAMOR_ACCESS_WO.


> diff --git a/glamor/glamor_prepare.c b/glamor/glamor_prepare.c
> index 5a73e6c..1c53165 100644
> --- a/glamor/glamor_prepare.c
> +++ b/glamor/glamor_prepare.c
> @@ -101,13 +101,14 @@ glamor_prep_pixmap_box(PixmapPtr pixmap, 
> glamor_access_t access, BoxPtr box)
>  priv->map_access = access;
>  }
>  
> -glamor_download_boxes(pixmap, RegionRects(), 
> RegionNumRects(),
> -  0, 0, 0, 0, pixmap->devPrivate.ptr, 
> pixmap->devKind);
> +if (priv->map_access != GLAMOR_ACCESS_WO)
> +glamor_download_boxes(pixmap, RegionRects(), 
> RegionNumRects(),
> +  0, 0, 0, 0, pixmap->devPrivate.ptr, 
> pixmap->devKind);
>  
>  RegionUninit();
>  
>  if (glamor_priv->has_rw_pbo) {
> -if (priv->map_access == GLAMOR_ACCESS_RW)
> +if (priv->map_access == GLAMOR_ACCESS_RW || priv->map_access == 
> GLAMOR_ACCESS_WO)
>  gl_access = GL_READ_WRITE;
>  else
>  gl_access = GL_READ_ONLY;
> @@ -144,7 +145,7 @@ glamor_fini_pixmap(PixmapPtr pixmap)
>  pixmap->devPrivate.ptr = NULL;
>  }
>  
> -if (priv->map_access == GLAMOR_ACCESS_RW) {
> +if (priv->map_access == GLAMOR_ACCESS_RW || priv->map_access == 
> GLAMOR_ACCESS_WO) {
>  glamor_upload_boxes(pixmap,
>  RegionRects(>prepare_region),
>  RegionNumRects(>prepare_region),

My patch used GL_WRITE_ONLY for GLAMOR_ACCESS_WO. Not sure it's worth it
though.


Other than that, your patch looks good to me.


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

[Bug 94414] Radeon RV370 w/ acceleration enabled exhibits problem with resolutions above 1440x900

[bugzilla-daemon]

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

--- Comment #8 from Jean-Philippe Gariépy  ---
Note that I'm seeing this "r300: CS space validation failed." message. 

This seems to come from Mesa:
mesa/src/gallium/drivers/r300/r300_render.c

Not sure what is the exact cause for this message.  What else can I try?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 94414] Radeon RV370 w/ acceleration enabled exhibits problem with resolutions above 1440x900

[bugzilla-daemon]

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

Jean-Philippe Gariépy  changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|RESOLVED|REOPENED

--- Comment #7 from Jean-Philippe Gariépy  ---
Sorry for the delay. I was trying to gather all the files for diagnostic.

I'm using Gnome 3.18 (classic).

# uname -a 
Linux localhost.localdomain 4.4.3-300.fc23.i686+PAE #1 SMP Fri Feb 26 19:01:29
UTC 2016 i686 i686 i386 GNU/Linux

/etc/X11/xorg.conf.d/00-gawi.conf:

Section "Device"
  Identifier "device"
  Driver "radeon"
  Option "Accel"  "true"
  #Option "EXAVSync" "true"
  #Option "EXAPixmaps" "false"
  #Option "SwapBuffersWait" "true"
  #Option "AccelMethod"  "exa"
  #Option "ColorTiling" "false"
  #Option "ColorTiling2D" "false"
  #Option "DRI" "3"
  #Option "TearFree" "false"
EndSection

I'm not using wayland for GDM.

I've tried lowering the depth to 16bpp but I have the same problems.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 94414] Radeon RV370 w/ acceleration enabled exhibits problem with resolutions above 1440x900

[bugzilla-daemon]

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

--- Comment #5 from Jean-Philippe Gariépy  ---
Created attachment 122192
  --> https://bugs.freedesktop.org/attachment.cgi?id=122192=edit
journalctl (filtered with gdm-x-session and gnome-shell.desktop)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 94414] Radeon RV370 w/ acceleration enabled exhibits problem with resolutions above 1440x900

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #4 from Michel Dänzer  ---
No description of the problem => no valid bug report. Feel free to reopen with
a description of the problem and the Xorg log file.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 94414] Radeon RV370 w/ acceleration enabled exhibits problem with resolutions above 1440x900

[bugzilla-daemon]

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

--- Comment #3 from Jean-Philippe Gariépy  ---
Created attachment 122189
  --> https://bugs.freedesktop.org/attachment.cgi?id=122189=edit
dmesg

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[PATCH] [RFC] glamor: implement write-only prepares

[Dave Airlie]

From: Dave Airlie 

For some putimages we know we won't ever care about the data we readback,
we are going to trash it with the putimage contents. So implement
GLAMOR_ACCESS_WO mode.

This will avoid doing the readbacks. Use it for putimages that are copy
with a solid planemask.

inspired by Ilia and xlock -mode wator which does loads of XYBitmap
putimages.

Signed-off-by: Dave Airlie 
---
 glamor/glamor_image.c   | 6 +-
 glamor/glamor_prepare.c | 9 +
 glamor/glamor_priv.h| 1 +
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/glamor/glamor_image.c b/glamor/glamor_image.c
index 3158749..87fdcf6 100644
--- a/glamor/glamor_image.c
+++ b/glamor/glamor_image.c
@@ -88,7 +88,11 @@ static void
 glamor_put_image_bail(DrawablePtr drawable, GCPtr gc, int depth, int x, int y,
   int w, int h, int leftPad, int format, char *bits)
 {
-if (glamor_prepare_access_box(drawable, GLAMOR_ACCESS_RW, x, y, w, h))
+int access = GLAMOR_ACCESS_RW;
+
+if (gc->alu == GXcopy && glamor_pm_is_solid(gc->depth, gc->planemask))
+access = GLAMOR_ACCESS_WO;
+if (glamor_prepare_access_box(drawable, access, x, y, w, h))
 fbPutImage(drawable, gc, depth, x, y, w, h, leftPad, format, bits);
 glamor_finish_access(drawable);
 }
diff --git a/glamor/glamor_prepare.c b/glamor/glamor_prepare.c
index 5a73e6c..1c53165 100644
--- a/glamor/glamor_prepare.c
+++ b/glamor/glamor_prepare.c
@@ -101,13 +101,14 @@ glamor_prep_pixmap_box(PixmapPtr pixmap, glamor_access_t 
access, BoxPtr box)
 priv->map_access = access;
 }
 
-glamor_download_boxes(pixmap, RegionRects(), 
RegionNumRects(),
-  0, 0, 0, 0, pixmap->devPrivate.ptr, pixmap->devKind);
+if (priv->map_access != GLAMOR_ACCESS_WO)
+glamor_download_boxes(pixmap, RegionRects(), 
RegionNumRects(),
+  0, 0, 0, 0, pixmap->devPrivate.ptr, 
pixmap->devKind);
 
 RegionUninit();
 
 if (glamor_priv->has_rw_pbo) {
-if (priv->map_access == GLAMOR_ACCESS_RW)
+if (priv->map_access == GLAMOR_ACCESS_RW || priv->map_access == 
GLAMOR_ACCESS_WO)
 gl_access = GL_READ_WRITE;
 else
 gl_access = GL_READ_ONLY;
@@ -144,7 +145,7 @@ glamor_fini_pixmap(PixmapPtr pixmap)
 pixmap->devPrivate.ptr = NULL;
 }
 
-if (priv->map_access == GLAMOR_ACCESS_RW) {
+if (priv->map_access == GLAMOR_ACCESS_RW || priv->map_access == 
GLAMOR_ACCESS_WO) {
 glamor_upload_boxes(pixmap,
 RegionRects(>prepare_region),
 RegionNumRects(>prepare_region),
diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h
index a70f10e..6df10b6 100644
--- a/glamor/glamor_priv.h
+++ b/glamor/glamor_priv.h
@@ -317,6 +317,7 @@ typedef struct glamor_screen_private {
 typedef enum glamor_access {
 GLAMOR_ACCESS_RO,
 GLAMOR_ACCESS_RW,
+GLAMOR_ACCESS_WO,
 } glamor_access_t;
 
 enum glamor_fbo_state {
-- 
2.5.0

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

Re: [PATCH xserver 1/5] xfree86/modes: Refactor xf86_use_hw_cursor_argb to use xf86_use_hw_cursor

[Keith Packard]

Michel Dänzer  writes:

> Sounds good to me.
>
> One thing that might be nice to do as part of your patch would be moving
> the xf86_config->cursor = NULL assignment from xf86_cursors_init to
> xf86_hide_cursors. That way xf86_config->cursor would always be NULL
> while the cursor layer isn't using the hardware cursor.

HideCursor gets called when setting the cursor image if
HARDWARE_CURSOR_UPDATE_UNHIDDEN isn't set, which means we'd have to save
the pointer in the LoadCursorImageCheck and LoadCursorARGBCheck
functions.

The LoadCursorImageCheck function doesn't get the CursorPtr.  So, we
need the xf86CurrentCursor function that I had written before.

From c133e4d9fac39862d7922f59080cc7ce40d1108b Mon Sep 17 00:00:00 2001
From: Keith Packard 
Date: Wed, 9 Mar 2016 11:13:14 -0800
Subject: [PATCH xserver] xfree86: Set xf86CrtcConfigRec cursor pointer to NULL
 in HideCursor

This makes the cursor pointer held by xf86Cursors.c get reset to NULL
whenever the cursor isn't displayed, and means that the reference
count held in xf86Cursor.c is sufficient to cover the reference in
xf86Cursors.c.

As HideCursor may be called in the cursor loading path after
UseHWCursor or UseHWCursorARGB when HARDWARE_CURSOR_UPDATE_UNHIDDEN
isn't set in the Flags field, the setting of the cursor pointer had to
be moved to the LoadCursor paths.

LoadCursorARGBCheck gets the cursor pointer, but LoadCursorImageCheck
does not. For LoadCursorImageCheck, I added a new function,
xf86CurrentCursor, which returns the current cursor. With this new
function, we can eliminate the cursor pointer from the
xf86CrtcConfigRec, once drivers are converted over to use it.

Signed-off-by: Keith Packard 
---
 hw/xfree86/modes/xf86Cursors.c | 18 ++
 hw/xfree86/ramdac/xf86Cursor.c |  9 +
 hw/xfree86/ramdac/xf86Cursor.h |  1 +
 3 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/hw/xfree86/modes/xf86Cursors.c b/hw/xfree86/modes/xf86Cursors.c
index 5df1ab7..8f9d589 100644
--- a/hw/xfree86/modes/xf86Cursors.c
+++ b/hw/xfree86/modes/xf86Cursors.c
@@ -287,7 +287,7 @@ xf86_set_cursor_colors(ScrnInfoPtr scrn, int bg, int fg)
 {
 ScreenPtr screen = scrn->pScreen;
 xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
-CursorPtr cursor = xf86_config->cursor;
+CursorPtr cursor = xf86CurrentCursor(screen);
 int c;
 CARD8 *bits = cursor ?
 dixLookupScreenPrivate(>devPrivates, CursorScreenKey, screen)
@@ -325,6 +325,7 @@ xf86_hide_cursors(ScrnInfoPtr scrn)
 int c;
 
 xf86_config->cursor_on = FALSE;
+xf86_config->cursor = NULL;
 for (c = 0; c < xf86_config->num_crtc; c++) {
 xf86CrtcPtr crtc = xf86_config->crtc[c];
 
@@ -456,6 +457,7 @@ xf86_crtc_load_cursor_image(xf86CrtcPtr crtc, CARD8 *src)
 CARD8 *cursor_image;
 const Rotation rotation = xf86_crtc_cursor_rotation(crtc);
 
+xf86_config->cursor = xf86CurrentCursor(xf86ScrnToScreen(scrn));
 crtc->cursor_argb = FALSE;
 
 if (rotation == RR_Rotate_0)
@@ -517,11 +519,6 @@ xf86_use_hw_cursor(ScreenPtr screen, CursorPtr cursor)
 xf86CursorInfoPtr cursor_info = xf86_config->cursor_info;
 int c;
 
-cursor = RefCursor(cursor);
-if (xf86_config->cursor)
-FreeCursor(xf86_config->cursor, None);
-xf86_config->cursor = cursor;
-
 if (cursor->bits->width > cursor_info->MaxWidth ||
 cursor->bits->height > cursor_info->MaxHeight)
 return FALSE;
@@ -593,6 +590,7 @@ xf86_load_cursor_argb(ScrnInfoPtr scrn, CursorPtr cursor)
 xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
 int c;
 
+xf86_config->cursor = cursor;
 for (c = 0; c < xf86_config->num_crtc; c++) {
 xf86CrtcPtr crtc = xf86_config->crtc[c];
 
@@ -638,7 +636,6 @@ xf86_cursors_init(ScreenPtr screen, int max_width, int max_height, int flags)
 cursor_info->LoadCursorARGBCheck = xf86_load_cursor_argb;
 }
 
-xf86_config->cursor = NULL;
 xf86_hide_cursors(scrn);
 
 return xf86InitCursor(screen, cursor_info);
@@ -681,7 +678,7 @@ xf86_reload_cursors(ScreenPtr screen)
 if (!cursor_info)
 return;
 
-cursor = xf86_config->cursor;
+cursor = xf86CurrentCursor(screen);
 GetSpritePosition(inputInfo.pointer, , );
 if (!(cursor_info->Flags & HARDWARE_CURSOR_UPDATE_UNHIDDEN))
 (*cursor_info->HideCursor) (scrn);
@@ -716,8 +713,5 @@ xf86_cursors_fini(ScreenPtr screen)
 }
 free(xf86_config->cursor_image);
 xf86_config->cursor_image = NULL;
-if (xf86_config->cursor) {
-FreeCursor(xf86_config->cursor, None);
-xf86_config->cursor = NULL;
-}
+xf86_config->cursor = NULL;
 }
diff --git a/hw/xfree86/ramdac/xf86Cursor.c b/hw/xfree86/ramdac/xf86Cursor.c
index c061b80..dda4349 100644
--- a/hw/xfree86/ramdac/xf86Cursor.c
+++ b/hw/xfree86/ramdac/xf86Cursor.c
@@ -462,6 +462,15 @@ xf86ForceHWCursor(ScreenPtr pScreen, Bool on)
 }
 }
 
+CursorPtr

Re: [PATCH] xv: Build left-shift constants from ints not longs

[Adam Jackson]

On Wed, 2016-03-09 at 10:59 -0500, Olivier Fourdan wrote:

> Reviewed-by: Olivier Fourdan 

remote: I: patch #76365 updated using rev 
723881f31d65353e80660e6d8cd9785e6ec1b430.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/proto/videoproto
   3841508..723881f  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] glamor: do not build Xv support when --disable-xv

[Adam Jackson]

On Wed, 2016-03-09 at 16:45 +0100, Olivier Fourdan wrote:
> Signed-off-by: Olivier Fourdan 

Merged this and the xwayland xv support:

remote: E: failed to find patch for rev 
da7724d3d277c6c8a814881785b716896802629a.
remote: I: patch #76376 updated using rev 
25ce263fd88684be9370025f93ba3a2bfc72ff1a.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   d11fdff..25ce263  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: [PULL] hw/xwin cleanup patches

[Adam Jackson]

On Wed, 2016-03-09 at 16:31 +, Jon Turney wrote:
> The following changes since commit 24042b4e367803dd64f3fcdc1bef7b2bf36c4145:
> 
>   modesetting: Allow CRTC transforms to actually take effect (2016-03-09 
> 16:46:13 +0900)
> 
> are available in the git repository at:
> 
>   git://people.freedesktop.org/~jturney/xserver 
> 
> for you to fetch changes up to d11fdff50c91575e977a63617806a61bca98cd35:
> 
>   hw/xwin: Tidy-up of winmsg.h (2016-03-09 16:13:54 +)

Merged, thanks:

remote: I: 0 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   24042b4..d11fdff  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 xf86-video-ati 2/2] present: Return rotated CRTCs from radeon_present_get_crtc

[Alex Deucher]

On Wed, Mar 9, 2016 at 4:46 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> Sync-to-vblank works fine with rotation. We're still checking for
> rotation in radeon_present_check_flip.
>
> Returning NULL from here resulted in the xserver present code falling
> back to the fake CRTC running at 1 fps.
>
> Signed-off-by: Michel Dänzer 

For the series:
Reviewed-by: Alex Deucher 

> ---
>  src/radeon_present.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/radeon_present.c b/src/radeon_present.c
> index 286b3f4..e0a549d 100644
> --- a/src/radeon_present.c
> +++ b/src/radeon_present.c
> @@ -77,8 +77,7 @@ radeon_present_get_crtc(WindowPtr window)
>  window->drawable.y,
>  window->drawable.y + 
> window->drawable.height);
>
> -/* Make sure the CRTC is valid and this is the real front buffer */
> -if (crtc != NULL && !crtc->rotatedData)
> +if (crtc)
> randr_crtc = crtc->randr_crtc;
>
>  return randr_crtc;
> --
> 2.7.0
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-ati@lists.x.org
> https://lists.x.org/mailman/listinfo/xorg-driver-ati
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[PULL] hw/xwin cleanup patches

[Jon Turney]

The following changes since commit 24042b4e367803dd64f3fcdc1bef7b2bf36c4145:

  modesetting: Allow CRTC transforms to actually take effect (2016-03-09 
16:46:13 +0900)

are available in the git repository at:

  git://people.freedesktop.org/~jturney/xserver 

for you to fetch changes up to d11fdff50c91575e977a63617806a61bca98cd35:

  hw/xwin: Tidy-up of winmsg.h (2016-03-09 16:13:54 +)


Jon Turney (13):
  hw/xwin: Remove the long-broken -silent-dup-error option
  hw/xwin: Ignore the obsolete, undocumented -internalwm option
  hw/xwin: Remove fInternalWM flag
  hw/xwin: Remove winIsInternalWMRunning(), which now always returns FALSE
  hw/xwin: Remove allowOtherWM, which is now always FALSE
  hw/xwin: Remove WM_(UN|)MANAGE messages, which are now never sent
  hw/xwin: Remove WM_WM_MAP message, which is now unused
  hw/xwin: Return FALSE to indicate failure in winSetEngine()
  hw/xwin: Remove unused HotKeyAltTab engine function
  hw/xwin: Remove unused FinishCreateWindowsWindow engine function
  hw/xwin: Use NULL rather than NoopDDA for unimplemented engine functions
  hw/xwin: Remove GC privates, unused since native GDI engine removal
  hw/xwin: Tidy-up of winmsg.h

 hw/xwin/InitOutput.c  |  87 ---
 hw/xwin/man/XWin.man  |   7 --
 hw/xwin/win.h |  27 +
 hw/xwin/winallpriv.c  |   7 --
 hw/xwin/winconfig.c   |   5 +-
 hw/xwin/winengine.c   |   2 +-
 hw/xwin/winglobals.c  |   1 -
 hw/xwin/winglobals.h  |   1 -
 hw/xwin/winmsg.c  |  33 +-
 hw/xwin/winmsg.h  |  17 +--
 hw/xwin/winmultiwindowwindow.c|  16 ---
 hw/xwin/winmultiwindowwm.c|  59 +-
 hw/xwin/winprocarg.c  |  13 +--
 hw/xwin/winscrinit.c  |  10 +-
 hw/xwin/winshadddnl.c |   6 -
 hw/xwin/winshadgdi.c  |  12 +-
 hw/xwin/winwin32rootless.c|  65 ---
 hw/xwin/winwin32rootlesswindow.c  |  13 ---
 hw/xwin/winwin32rootlesswndproc.c | 227 +-
 hw/xwin/winwindow.h   |   5 +-
 hw/xwin/winwndproc.c  |  46 +---
 21 files changed, 39 insertions(+), 620 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: [PATCH] xv: Build left-shift constants from ints not longs

[Olivier Fourdan]

- Original Message -
> Looks good to me.
> 
> Funny that we have:
> #define XvNumReasons (XvLastReason + 1)
> and a few lines below it:
> #define XvAnyReasonMask   ((1L< Anyway,
> 
> Reviewed-by: Olivier Fourdan 
> 
___
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] xv: Build left-shift constants from ints not longs

[Olivier Fourdan]

- Original Message -
> We typically store these in ints in server, leading to warnings like:
> 
> xwayland-glamor-xv.c: In function ‘xwl_glamor_xv_add_adaptors’:
> xwayland-glamor-xv.c:339:16: warning: large integer implicitly truncated
> to unsigned type [-Woverflow]
>  pa->type = XvWindowMask | XvInputMask | XvImageMask;;
> ^
> 
> Signed-off-by: Adam Jackson 
> ---
>  Xv.h | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/Xv.h b/Xv.h
> index ef3f786..f662df6 100644
> --- a/Xv.h
> +++ b/Xv.h
> @@ -59,8 +59,8 @@ typedef XID XvEncodingID;
>  #define XvInput  0
>  #define XvOutput 1
>  
> -#define XvInputMask  (1L< -#define XvOutputMask (1L< +#define XvInputMask  (1< +#define XvOutputMask (1<  #define XvVideoMask   0x0004
>  #define XvStillMask   0x0008
>  #define XvImageMask   0x0010
> @@ -100,13 +100,13 @@ typedef XID XvEncodingID;
>  
>  #define XvNumReasons (XvLastReason + 1)
>  
> -#define XvStartedMask (1L< -#define XvStoppedMask (1L< -#define XvBusyMask(1L< -#define XvPreemptedMask   (1L< -#define XvHardErrorMask   (1L< +#define XvStartedMask (1< +#define XvStoppedMask (1< +#define XvBusyMask(1< +#define XvPreemptedMask   (1< +#define XvHardErrorMask   (1<  
> -#define XvAnyReasonMask   ((1L< +#define XvAnyReasonMask   ((1<  #define XvNoReasonMask0
>  
>  /* Errors */

Looks good to me.

Funny that we have:
#define XvNumReasons (XvLastReason + 1)
and a few lines below it:
#define XvAnyReasonMask   ((1L<
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver] glamor: do not build Xv support when --disable-xv

[Olivier Fourdan]

Signed-off-by: Olivier Fourdan 
---
 glamor/Makefile.am | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/glamor/Makefile.am b/glamor/Makefile.am
index c488029..c631c53 100644
--- a/glamor/Makefile.am
+++ b/glamor/Makefile.am
@@ -46,10 +46,14 @@ libglamor_la_SOURCES = \
glamor_compositerects.c\
glamor_utils.c\
glamor_utils.h\
-   glamor_xv.c \
glamor_sync.c \
glamor.h
 
+if XV
+libglamor_la_SOURCES += \
+   glamor_xv.c
+endif
+
 libglamor_egl_stubs_la_SOURCES = glamor_egl_stubs.c
 
 sdk_HEADERS = glamor.h
-- 
2.5.0

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

[PATCH xserver v4] xwayland: add glamor Xv adaptor

[Olivier Fourdan]

This adds an Xv adaptor using glamor.

Signed-off-by: Olivier Fourdan 
---
 v2: Plug leak of Xv adaptor and glamor private ports array on closure
 v3: Get the adaptor size from the GL_MAX_TEXTURE_SIZE
 v4: Fix double comma and unsigned int warning, fix build with --disable-xv

 hw/xwayland/Makefile.am  |   7 +-
 hw/xwayland/xwayland-glamor-xv.c | 413 +++
 hw/xwayland/xwayland-glamor.c|   5 +
 hw/xwayland/xwayland.h   |   5 +
 4 files changed, 429 insertions(+), 1 deletion(-)
 create mode 100644 hw/xwayland/xwayland-glamor-xv.c

diff --git a/hw/xwayland/Makefile.am b/hw/xwayland/Makefile.am
index 0905082..0e6a1ea 100644
--- a/hw/xwayland/Makefile.am
+++ b/hw/xwayland/Makefile.am
@@ -32,7 +32,12 @@ Xwayland_LDFLAGS = $(LD_EXPORT_SYMBOLS_FLAG)
 
 
 if GLAMOR_EGL
-Xwayland_SOURCES += xwayland-glamor.c
+Xwayland_SOURCES +=\
+   xwayland-glamor.c
+if XV
+Xwayland_SOURCES +=\
+   xwayland-glamor-xv.c
+endif
 
 nodist_Xwayland_SOURCES =  \
drm-client-protocol.h   \
diff --git a/hw/xwayland/xwayland-glamor-xv.c b/hw/xwayland/xwayland-glamor-xv.c
new file mode 100644
index 000..22c81a0
--- /dev/null
+++ b/hw/xwayland/xwayland-glamor-xv.c
@@ -0,0 +1,413 @@
+/*
+ * Copyright (c) 1998-2003 by The XFree86 Project, Inc.
+ * Copyright © 2013 Red Hat
+ * Copyright © 2014 Intel Corporation
+ * Copyright © 2016 Red Hat
+ *
+ * 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.
+ *
+ * Authors:
+ *  Olivier Fourdan 
+ *
+ * Derived from the glamor_xf86_xv, ephyr_glamor_xv and xf86xv
+ * implementations
+ */
+
+#include "xwayland.h"
+#include "glamor_priv.h"
+
+#include 
+
+#define NUM_FORMATS3
+#define NUM_PORTS  16
+#define ADAPTOR_NAME   "glamor textured video"
+#define ENCODER_NAME   "XV_IMAGE"
+
+static DevPrivateKeyRec xwlXvScreenPrivateKeyRec;
+#define xwlXvScreenPrivateKey ()
+
+typedef struct {
+XvAdaptorPtr glxv_adaptor; /* We have only one adaptor, glamor Xv */
+glamor_port_private *port_privates;
+
+CloseScreenProcPtr CloseScreen;
+} xwlXvScreenRec, *xwlXvScreenPtr;
+
+typedef struct {
+char depth;
+short class;
+} xwlVideoFormatRec, *xwlVideoFormatPtr;
+
+static xwlVideoFormatRec Formats[NUM_FORMATS] = {
+{15, TrueColor},
+{16, TrueColor},
+{24, TrueColor}
+};
+
+static int
+xwl_glamor_xv_stop_video(XvPortPtr   pPort,
+ DrawablePtr pDraw)
+{
+glamor_port_private *gpp = (glamor_port_private *) (pPort->devPriv.ptr);
+
+if (pDraw->type != DRAWABLE_WINDOW)
+return BadAlloc;
+
+glamor_xv_stop_video(gpp);
+
+return Success;
+}
+
+static int
+xwl_glamor_xv_set_port_attribute(XvPortPtr pPort,
+ Atom  attribute,
+ INT32 value)
+{
+glamor_port_private *gpp = (glamor_port_private *) (pPort->devPriv.ptr);
+
+return glamor_xv_set_port_attribute(gpp, attribute, value);
+}
+
+static int
+xwl_glamor_xv_get_port_attribute(XvPortPtr pPort,
+ Atom  attribute,
+ INT32*pValue)
+{
+glamor_port_private *gpp = (glamor_port_private *) (pPort->devPriv.ptr);
+
+return glamor_xv_get_port_attribute(gpp, attribute, pValue);
+}
+
+static int
+xwl_glamor_xv_query_best_size(XvPortPtr pPort,
+  CARD8 motion,
+  CARD16vid_w,
+  CARD16vid_h,
+  CARD16drw_w,
+  CARD16drw_h,
+  unsigned int *p_w,
+  unsigned int *p_h)
+{
+*p_w = drw_w;
+*p_h = drw_h;
+
+return Success;
+}
+
+static int

Re: [PATCH] Add Compose sequence for U+1F4A9.

[Adam Jackson]

On Wed, 2016-03-09 at 14:35 +0100, Daniel Albers wrote:
> Signed-off-by: Daniel Albers 

Merged, thanks:

remote: I: patch #76361 updated using rev 
e1011b9e2f6c82255959cf3cc1d8cda402ded0a9.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/lib/libX11
   6d7bb04..e1011b9  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 v3] xwayland: add glamor Xv adaptor

[Adam Jackson]

On Tue, 2016-03-08 at 10:15 -0500, Olivier Fourdan wrote:
> Hi Adam,
> 
> I had posted a revisited version using GL_MAX_TEXTURE_SIZE to
> determine the encoder size as per your review last week, is there
> anything else that needs rework?

This adds a warning, but I don't think that's your fault:

xwayland-glamor-xv.c: In function ‘xwl_glamor_xv_add_adaptors’:
xwayland-glamor-xv.c:339:16: warning: large integer implicitly truncated to 
unsigned type [-Woverflow]
 pa->type = XvWindowMask | XvInputMask | XvImageMask;;
^

% grep Xv.*put /usr/include/X11/extensions/*h
/usr/include/X11/extensions/Xv.h:#define XvInput  0
/usr/include/X11/extensions/Xv.h:#define XvOutput 1
/usr/include/X11/extensions/Xv.h:#define XvInputMask  (1L<

[PATCH] xv: Build left-shift constants from ints not longs

[Adam Jackson]

We typically store these in ints in server, leading to warnings like:

xwayland-glamor-xv.c: In function ‘xwl_glamor_xv_add_adaptors’:
xwayland-glamor-xv.c:339:16: warning: large integer implicitly truncated
to unsigned type [-Woverflow]
 pa->type = XvWindowMask | XvInputMask | XvImageMask;;
^

Signed-off-by: Adam Jackson 
---
 Xv.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/Xv.h b/Xv.h
index ef3f786..f662df6 100644
--- a/Xv.h
+++ b/Xv.h
@@ -59,8 +59,8 @@ typedef XID XvEncodingID;
 #define XvInput  0
 #define XvOutput 1
 
-#define XvInputMask  (1L<

Re: [PULL] Reviewed cursor changes

[Adam Jackson]

On Wed, 2016-03-09 at 16:51 +0900, Michel Dänzer wrote:
> Hi Keith / Adam,
> 
> 
> the following changes since commit a3e681eafa5355b8bb3b099d47983f14f0d5e197:
> 
>   glamor: Source pictures are always depth 32 (2016-03-08 15:17:19 -0500)
> 
> are available in the git repository at:
> 
>   git://people.freedesktop.org/~daenzer/xserver for-master
> 
> for you to fetch changes up to 24042b4e367803dd64f3fcdc1bef7b2bf36c4145:
> 
>   modesetting: Allow CRTC transforms to actually take effect (2016-03-09 
> 16:46:13 +0900)

Merged, thanks:

remote: I: patch #75216 updated using rev 
c3e4e9fc5d84bfc17b3ed63f67488ea25ba150ce.
remote: I: patch #76114 updated using rev 
a4ffa8721debb34bd36fd4624890d9c26886c618.
remote: I: patch #69024 updated using rev 
b04767c84deafc44993723add4b1c5163fc11711.
remote: I: patch #68753 updated using rev 
24042b4e367803dd64f3fcdc1bef7b2bf36c4145.
remote: I: 4 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   a3e681e..24042b4  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

[PATCH] Add Compose sequence for U+1F4A9.

[Daniel Albers]

Signed-off-by: Daniel Albers 
---
 nls/en_US.UTF-8/Compose.pre | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre
index 2041757..d88fe36 100644
--- a/nls/en_US.UTF-8/Compose.pre
+++ b/nls/en_US.UTF-8/Compose.pre
@@ -278,6 +278,8 @@ XCOMM Other symbols
: "☹"   U2639 # WHITE FROWNING FACE
: ""   # PERSON 
RAISING BOTH HANDS IN CELEBRATION
 
+: ""  U1F4A9 # PILE OF POO
+
: ""  U1F595 # REVERSED HAND WITH 
MIDDLE FINGER EXTENDED
  : ""  U1F596 # RAISED HAND WITH PART 
BETWEEN MIDDLE AND RING FINGERS
 
-- 
2.7.0

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

Re: Problem with X starting when certain USB configurations exist

[Adam Jackson]

On Tue, 2016-03-08 at 16:10 -0800, russell.poffenber...@xcerra.com wrote:

> So could there be a bug, or a newer (read fixed) int10 driver in the
> Centos 7 version that can be ported to Centos 6.7? Where can I find
> the package or code for this driver that I may be able to compile for
> Centos 6.7? 

Interesting. CentOS 7 might behave differently, but it's very unlikely
to be the X server or X vesa driver causing that difference; the X code
supporting vesa is basically identical between 6.7 and 7.1. It's more
likely to be a difference in the boot loader (grub-0.97 vs. grub2) or
in the kernel.

- ajax
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: When to call XDamageSubtract ()

[Adam Jackson]

On Tue, 2016-03-08 at 23:56 +, adlo wrote:
> I am writing a window switcher application using GTK that shows live
> previews of windows.
> 
> Should I call XDamageSubtract () before or after I update the image
> widget in response to a damage event?

Before, but in another sense, neither.  X requests are processed as an
arbitrary shuffle of in-order atomic requests from clients.  If you
subtract before updating, the other client might update the window
again in between, which will generate more damage and you'll do excess
work, but at least the preview will look right.  If you subtract after
updating, the client may have updated the window in between, which (if
you're using a damage mode other than RawRectangles, which you have to
be in order for Subtract to mean anything) might not get reported, and
your preview image will be out of sync.

Better is to do XGrabServer/XUngrabServer around the two operations,
which will prevent any other client from updating in between, in which
case the order doesn't matter.  You should attempt to minimize the
amount of work you do while the server is grabbed (eg just do the
ShmGetImage/CopyArea and DamageSubtract, don't do any other requests
that would generate a reply) and you should minimize the number of
grabs you do (you'll get events far faster than the 60fps your display
is probably running at so you should throttle your own framerate) in
order to keep the server responsive to other clients.

- ajax
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [PATCH xserver] xwayland: Make it possible to force CLOCK_MONOTONIC

[Daniel Stone]

Hi,

On 9 March 2016 at 04:27, Jonas Ådahl  wrote:
> By default the X server will try CLOCK_MONOTONIC_COARSE before
> CLOCK_MONOTONIC. This causes various issues for Wayland display
> servers who may get their internal timestamps from the CLOCK_MONOTONIC,
> since it may very well happen that a timestamp from CLOCK_MONOTONIC
> retrieved before a sending an X request will still be "later" than the
> timestamp the X server than gets after receiving the request, due to
> the fact that CLOCK_MONOTONIC_COARSE has a lower resolution.

For reference, this isn't anything to do with Wayland core protocol or
similar, but that evdev devices can provide events with
CLOCK_MONOTONIC timestamps, which we try to match.

The original reason for using CLOCK_MONOTONIC_COARSE over
CLOCK_MONOTONIC is that the former had a runtime power impact by
battering HPET. I don't know if that still holds up on modern systems.

> FWIW, I would be just as fine with always forcing CLOCK_MONOTONIC for Xwayland
> if the command line argument seems unnecessary.

This one is :
Reviewed-by: Daniel Stone 

and just forcing Xwayland to do it unconditionally is:
Acked-by: Daniel Stone 

> @@ -86,6 +88,10 @@ ddxProcessArgument(int argc, char *argv[], int i)
>  else if (strcmp(argv[i], "-shm") == 0) {
>  return 1;
>  }
> +else if (strcmp(argv[i], "-forceMonotonic") == 0) {
> +ForceClockId(CLOCK_MONOTONIC);
> +return 1;
> +}

Needs #ifdef MONOTONIC_CLOCK.

> +#ifdef MONOTONIC_CLOCK
> +static clockid_t clockid;
> +#endif
> +
>  OsSigHandlerPtr
>  OsSignal(int sig, OsSigHandlerPtr handler)
>  {
> @@ -427,6 +431,26 @@ GiveUp(int sig)
>  errno = olderrno;
>  }
>
> +#ifdef MONOTONIC_CLOCK
> +void
> +ForceClockId(clockid_t forced_clockid)
> +{
> +struct timespec tp;
> +
> +if (clockid) {
> +ErrorF("Warning: clock id was forced after it was initialized.\n");

Turn this into a BUG(), especially as the one below is a FatalError ...

Cheers,
Daniel
___
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 4/4] xwayland: sync event queue to check compositor reply

[Olivier Fourdan]

- Original Message -
> - Original Message -
> > Read and dispatch pending Wayland events to make sure we do nto miss a
> > possible reply from the compositor prior to discard a key repeat.
> > 
> > Signed-off-by: Olivier Fourdan 
> > ---
> >  hw/xwayland/xwayland-input.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
> > index 28d8b54..89f6faf 100644
> > --- a/hw/xwayland/xwayland-input.c
> > +++ b/hw/xwayland/xwayland-input.c
> > @@ -546,6 +546,9 @@ keyboard_check_repeat (DeviceIntPtr dev, XkbSrvInfoPtr
> > xkbi, unsigned key)
> >  struct xwl_screen *xwl_screen = xwl_seat->xwl_screen;
> >  struct wl_callback *callback;
> >  
> > +/* Make sure we didn't miss a possible reply from the compositor */
> > +xwl_sync_events (xwl_screen);
> > +
> 
> Unfortunately it still cause a deadlock apprently:
> 
> #0  0x7fab4b6f93a0 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1  0x7fab4df3249b in read_events (display=0x17f7b80) at
> src/wayland-client.c:1326
> #2  wl_display_read_events (display=0x17f7b80) at src/wayland-client.c:1396
> #3  0x00423e34 in xwl_read_events (xwl_screen=,
> xwl_screen=) at xwayland.c:465
> #4  0x00424adf in xwl_sync_events
> (xwl_screen=xwl_screen@entry=0x17f7910) at xwayland.c:524
> #5  0x00424e15 in keyboard_check_repeat (dev=,
> xkbi=, key=) at xwayland-input.c:536
> #6  0x00525417 in AccessXRepeatKeyExpire (timer=,
> now=, arg=0x22c61f0) at xkbAccessX.c:321
> #7  0x0058b6c3 in DoTimer (timer=0x2923510, now=now@entry=3317763,
> prev=prev@entry=0x81f6f8 ) at WaitFor.c:420
> #8  0x0058c36a in WaitForSomething
> (pClientsReady=pClientsReady@entry=0x17efab0) at WaitFor.c:291
> #9  0x005572ee in Dispatch () at dispatch.c:359
> #10 0x0055b503 in dix_main (argc=10, argv=0x7ffca1cbd528,
> envp=) at main.c:300
> #11 0x7fab4bfaa0c1 in __libc_start_main () from /lib64/libc.so.6
> #12 0x00423599 in _start ()
> 
> And that will freeze both the Xwayland server and the compositor, so not
> good.

That is actually fixed with v2 of the patch #3 (ie call prepare_read() before 
read() to avoid the deadlock as Pekka pointed out on irc).

Cheers,
Olivier
___
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 3/4 v2] xwayland: refactor Wayland event handling

[Olivier Fourdan]

To be able to reuse some code.

Signed-off-by: Olivier Fourdan 
---
 v2: call prepre_read() before read() so we don't end up in a deadlock

 hw/xwayland/xwayland.c | 44 
 hw/xwayland/xwayland.h |  2 ++
 2 files changed, 34 insertions(+), 12 deletions(-)

diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 151e044..748abdf 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -460,14 +460,13 @@ static const struct wl_registry_listener 
registry_listener = {
 };
 
 static void
-socket_handler(int fd, int ready, void *data)
+xwl_read_events (struct xwl_screen *xwl_screen)
 {
-struct xwl_screen *xwl_screen = data;
 int ret;
 
 ret = wl_display_read_events(xwl_screen->display);
 if (ret == -1)
-FatalError("failed to dispatch Wayland events: %s\n", strerror(errno));
+FatalError("failed to read Wayland events: %s\n", strerror(errno));
 
 xwl_screen->prepare_read = 0;
 
@@ -477,18 +476,10 @@ socket_handler(int fd, int ready, void *data)
 }
 
 static void
-wakeup_handler(void *data, int err, void *pRead)
-{
-}
-
-static void
-block_handler(void *data, OSTimePtr pTimeout, void *pRead)
+xwl_dispatch_events (struct xwl_screen *xwl_screen)
 {
-struct xwl_screen *xwl_screen = data;
 int ret;
 
-xwl_screen_post_damage(xwl_screen);
-
 while (xwl_screen->prepare_read == 0 &&
wl_display_prepare_read(xwl_screen->display) == -1) {
 ret = wl_display_dispatch_pending(xwl_screen->display);
@@ -504,6 +495,35 @@ block_handler(void *data, OSTimePtr pTimeout, void *pRead)
 FatalError("failed to write to XWayland fd: %s\n", strerror(errno));
 }
 
+static void
+socket_handler(int fd, int ready, void *data)
+{
+struct xwl_screen *xwl_screen = data;
+
+xwl_read_events (xwl_screen);
+}
+
+static void
+wakeup_handler(void *data, int err, void *pRead)
+{
+}
+
+static void
+block_handler(void *data, OSTimePtr pTimeout, void *pRead)
+{
+struct xwl_screen *xwl_screen = data;
+
+xwl_screen_post_damage(xwl_screen);
+xwl_dispatch_events (xwl_screen);
+}
+
+void
+xwl_sync_events (struct xwl_screen *xwl_screen)
+{
+xwl_dispatch_events (xwl_screen);
+xwl_read_events (xwl_screen);
+}
+
 static CARD32
 add_client_fd(OsTimerPtr timer, CARD32 time, void *arg)
 {
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index aaf3b40..5fc0cfa 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -155,6 +155,8 @@ struct xwl_output {
 
 struct xwl_pixmap;
 
+void xwl_sync_events (struct xwl_screen *xwl_screen);
+
 Bool xwl_screen_init_cursor(struct xwl_screen *xwl_screen);
 
 struct xwl_screen *xwl_screen_get(ScreenPtr screen);
-- 
2.5.0

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

[PATCH xf86-video-ati 2/2] present: Return rotated CRTCs from radeon_present_get_crtc

[Michel Dänzer]

From: Michel Dänzer 

Sync-to-vblank works fine with rotation. We're still checking for
rotation in radeon_present_check_flip.

Returning NULL from here resulted in the xserver present code falling
back to the fake CRTC running at 1 fps.

Signed-off-by: Michel Dänzer 
---
 src/radeon_present.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/radeon_present.c b/src/radeon_present.c
index 286b3f4..e0a549d 100644
--- a/src/radeon_present.c
+++ b/src/radeon_present.c
@@ -77,8 +77,7 @@ radeon_present_get_crtc(WindowPtr window)
 window->drawable.y,
 window->drawable.y + window->drawable.height);
 
-/* Make sure the CRTC is valid and this is the real front buffer */
-if (crtc != NULL && !crtc->rotatedData)
+if (crtc)
randr_crtc = crtc->randr_crtc;
 
 return randr_crtc;
-- 
2.7.0

___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[PATCH xf86-video-ati 1/2] present: Clear drmmode->fb_id before calling set_mode_major for unflip

[Michel Dänzer]

From: Michel Dänzer 

Without this, drmmode_set_mode_major may just re-set the FB for the
last flipped BO, in which case the display will probably freeze.

Reproduction recipe: Enable rotation while a fullscreen client is
flipping.

Signed-off-by: Michel Dänzer 
---
 src/radeon_present.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/radeon_present.c b/src/radeon_present.c
index 68be1c7..286b3f4 100644
--- a/src/radeon_present.c
+++ b/src/radeon_present.c
@@ -382,6 +382,12 @@ radeon_present_unflip(ScreenPtr screen, uint64_t event_id)
return;
 
 modeset:
+/* info->drmmode.fb_id still points to the FB for the last flipped BO.
+ * Clear it, drmmode_set_mode_major will re-create it
+ */
+drmModeRmFB(info->drmmode.fd, info->drmmode.fb_id);
+info->drmmode.fb_id = 0;
+
 for (i = 0; i < config->num_crtc; i++) {
xf86CrtcPtr crtc = config->crtc[i];
drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
-- 
2.7.0

___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Re: [PATCH xserver 4/4] xwayland: sync event queue to check compositor reply

[Olivier Fourdan]

- Original Message -
> Read and dispatch pending Wayland events to make sure we do nto miss a
> possible reply from the compositor prior to discard a key repeat.
> 
> Signed-off-by: Olivier Fourdan 
> ---
>  hw/xwayland/xwayland-input.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
> index 28d8b54..89f6faf 100644
> --- a/hw/xwayland/xwayland-input.c
> +++ b/hw/xwayland/xwayland-input.c
> @@ -546,6 +546,9 @@ keyboard_check_repeat (DeviceIntPtr dev, XkbSrvInfoPtr
> xkbi, unsigned key)
>  struct xwl_screen *xwl_screen = xwl_seat->xwl_screen;
>  struct wl_callback *callback;
>  
> +/* Make sure we didn't miss a possible reply from the compositor */
> +xwl_sync_events (xwl_screen);
> +

Unfortunately it still cause a deadlock apprently:

#0  0x7fab4b6f93a0 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#1  0x7fab4df3249b in read_events (display=0x17f7b80) at 
src/wayland-client.c:1326
#2  wl_display_read_events (display=0x17f7b80) at src/wayland-client.c:1396
#3  0x00423e34 in xwl_read_events (xwl_screen=, 
xwl_screen=) at xwayland.c:465
#4  0x00424adf in xwl_sync_events 
(xwl_screen=xwl_screen@entry=0x17f7910) at xwayland.c:524
#5  0x00424e15 in keyboard_check_repeat (dev=, 
xkbi=, key=) at xwayland-input.c:536
#6  0x00525417 in AccessXRepeatKeyExpire (timer=, 
now=, arg=0x22c61f0) at xkbAccessX.c:321
#7  0x0058b6c3 in DoTimer (timer=0x2923510, now=now@entry=3317763, 
prev=prev@entry=0x81f6f8 ) at WaitFor.c:420
#8  0x0058c36a in WaitForSomething 
(pClientsReady=pClientsReady@entry=0x17efab0) at WaitFor.c:291
#9  0x005572ee in Dispatch () at dispatch.c:359
#10 0x0055b503 in dix_main (argc=10, argv=0x7ffca1cbd528, 
envp=) at main.c:300
#11 0x7fab4bfaa0c1 in __libc_start_main () from /lib64/libc.so.6
#12 0x00423599 in _start ()

And that will freeze both the Xwayland server and the compositor, so not good.



>  if (!xwl_seat->sync_pending) {
>  callback = wl_display_sync (xwl_screen->display);
>  wl_callback_add_listener(callback, _listener, xwl_seat);
> --
> 2.5.0

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

[PATCH xserver 4/4] xwayland: sync event queue to check compositor reply

[Olivier Fourdan]

Read and dispatch pending Wayland events to make sure we do nto miss a
possible reply from the compositor prior to discard a key repeat.

Signed-off-by: Olivier Fourdan 
---
 hw/xwayland/xwayland-input.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index 28d8b54..89f6faf 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -546,6 +546,9 @@ keyboard_check_repeat (DeviceIntPtr dev, XkbSrvInfoPtr 
xkbi, unsigned key)
 struct xwl_screen *xwl_screen = xwl_seat->xwl_screen;
 struct wl_callback *callback;
 
+/* Make sure we didn't miss a possible reply from the compositor */
+xwl_sync_events (xwl_screen);
+
 if (!xwl_seat->sync_pending) {
 callback = wl_display_sync (xwl_screen->display);
 wl_callback_add_listener(callback, _listener, xwl_seat);
-- 
2.5.0

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

[PATCH xserver 3/4] xwayland: refactor Wayland event handling

[Olivier Fourdan]

To be able to reuse some code.

Signed-off-by: Olivier Fourdan 
---
 hw/xwayland/xwayland.c | 44 
 hw/xwayland/xwayland.h |  2 ++
 2 files changed, 34 insertions(+), 12 deletions(-)

diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 151e044..4c0ed0d 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -460,14 +460,13 @@ static const struct wl_registry_listener 
registry_listener = {
 };
 
 static void
-socket_handler(int fd, int ready, void *data)
+xwl_read_events (struct xwl_screen *xwl_screen)
 {
-struct xwl_screen *xwl_screen = data;
 int ret;
 
 ret = wl_display_read_events(xwl_screen->display);
 if (ret == -1)
-FatalError("failed to dispatch Wayland events: %s\n", strerror(errno));
+FatalError("failed to read Wayland events: %s\n", strerror(errno));
 
 xwl_screen->prepare_read = 0;
 
@@ -477,18 +476,10 @@ socket_handler(int fd, int ready, void *data)
 }
 
 static void
-wakeup_handler(void *data, int err, void *pRead)
-{
-}
-
-static void
-block_handler(void *data, OSTimePtr pTimeout, void *pRead)
+xwl_dispatch_events (struct xwl_screen *xwl_screen)
 {
-struct xwl_screen *xwl_screen = data;
 int ret;
 
-xwl_screen_post_damage(xwl_screen);
-
 while (xwl_screen->prepare_read == 0 &&
wl_display_prepare_read(xwl_screen->display) == -1) {
 ret = wl_display_dispatch_pending(xwl_screen->display);
@@ -504,6 +495,35 @@ block_handler(void *data, OSTimePtr pTimeout, void *pRead)
 FatalError("failed to write to XWayland fd: %s\n", strerror(errno));
 }
 
+static void
+socket_handler(int fd, int ready, void *data)
+{
+struct xwl_screen *xwl_screen = data;
+
+xwl_read_events (xwl_screen);
+}
+
+static void
+wakeup_handler(void *data, int err, void *pRead)
+{
+}
+
+static void
+block_handler(void *data, OSTimePtr pTimeout, void *pRead)
+{
+struct xwl_screen *xwl_screen = data;
+
+xwl_screen_post_damage(xwl_screen);
+xwl_dispatch_events (xwl_screen);
+}
+
+void
+xwl_sync_events (struct xwl_screen *xwl_screen)
+{
+xwl_read_events (xwl_screen);
+xwl_dispatch_events (xwl_screen);
+}
+
 static CARD32
 add_client_fd(OsTimerPtr timer, CARD32 time, void *arg)
 {
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index aaf3b40..5fc0cfa 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -155,6 +155,8 @@ struct xwl_output {
 
 struct xwl_pixmap;
 
+void xwl_sync_events (struct xwl_screen *xwl_screen);
+
 Bool xwl_screen_init_cursor(struct xwl_screen *xwl_screen);
 
 struct xwl_screen *xwl_screen_get(ScreenPtr screen);
-- 
2.5.0

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

[PATCH xserver 2/4 v3] xwayland: add a server sync before repeating keys

[Olivier Fourdan]

Key repeat is handled by the X server, but input events need to be
processed and forwarded by the Wayland compositor first.

Make sure the Wayland compositor is actually processing events, to
avoid repeating keys in Xwayland while the Wayland compositor cannot
deal with input events for whatever reason, thus not dispatching key
release events, leading to repeated keys while the user has already
released the key.

Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762618
Signed-off-by: Olivier Fourdan 
---
 v2: A slightly less hack-y-ish version of the patch
 Use xwl_seat to store the pending sync, set up callback fpr keyboard
 in seat_handle_capabilities() and add a call to _dispatch_pending()
 in the callback function to make sure we didn't miss a reply
 v3: Small clean-up,
 Remove the call to wl_display_dispatch_pending() that we added
 in v2 as we shall do it in two other separate patches to follow.

 hw/xwayland/xwayland-input.c | 38 ++
 hw/xwayland/xwayland.h   |  2 ++
 2 files changed, 40 insertions(+)

diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index f9e3255..28d8b54 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -527,6 +527,40 @@ keyboard_handle_modifiers(void *data, struct wl_keyboard 
*keyboard,
 }
 
 static void
+sync_callback(void *data, struct wl_callback *callback, uint32_t serial)
+{
+struct xwl_seat *xwl_seat = data;
+
+xwl_seat->sync_pending = FALSE;
+wl_callback_destroy(callback);
+}
+
+static const struct wl_callback_listener sync_listener = {
+   sync_callback
+};
+
+static Bool
+keyboard_check_repeat (DeviceIntPtr dev, XkbSrvInfoPtr xkbi, unsigned key)
+{
+struct xwl_seat *xwl_seat = dev->public.devicePrivate;
+struct xwl_screen *xwl_screen = xwl_seat->xwl_screen;
+struct wl_callback *callback;
+
+if (!xwl_seat->sync_pending) {
+callback = wl_display_sync (xwl_screen->display);
+wl_callback_add_listener(callback, _listener, xwl_seat);
+xwl_seat->sync_pending = TRUE;
+
+return TRUE;
+}
+
+ErrorF("Key repeat discarded, Wayland compositor doesn't seem to "
+   "be processing events fast enough!\n");
+
+return FALSE;
+}
+
+static void
 keyboard_handle_repeat_info (void *data, struct wl_keyboard *keyboard,
  int32_t rate, int32_t delay)
 {
@@ -716,6 +750,7 @@ seat_handle_capabilities(void *data, struct wl_seat *seat,
  enum wl_seat_capability caps)
 {
 struct xwl_seat *xwl_seat = data;
+DeviceIntPtr master;
 
 if (caps & WL_SEAT_CAPABILITY_POINTER && xwl_seat->wl_pointer == NULL) {
 xwl_seat->wl_pointer = wl_seat_get_pointer(seat);
@@ -748,6 +783,9 @@ seat_handle_capabilities(void *data, struct wl_seat *seat,
 ActivateDevice(xwl_seat->keyboard, TRUE);
 }
 EnableDevice(xwl_seat->keyboard, TRUE);
+master = GetMaster(xwl_seat->keyboard, MASTER_KEYBOARD);
+if (master)
+master->key->xkbInfo->checkRepeat = keyboard_check_repeat;
 } else if (!(caps & WL_SEAT_CAPABILITY_KEYBOARD) && xwl_seat->wl_keyboard) 
{
 wl_keyboard_release(xwl_seat->wl_keyboard);
 xwl_seat->wl_keyboard = NULL;
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index 2a54183..aaf3b40 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -138,6 +138,8 @@ struct xwl_seat {
 size_t keymap_size;
 char *keymap;
 struct wl_surface *keyboard_focus;
+
+Bool sync_pending;
 };
 
 struct xwl_output {
-- 
2.5.0

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

[PATCH xserver 1/4 v2] xkb: add hook to allow/deny AccessX key repeat

[Olivier Fourdan]

The xserver generates the key repeat by itself.

But when used with another server processing inputs first (e.g. a
Wayland compositor), the other server may be busy dealing with some
other things and not queue up key release events in time.

Add a vfunc in XkbSrvInfo to possibly add a check before re-emitting a
keypress event in the AccessX timer handler, so that the key repeat has
a chance to be denied if the server processing the input is not ready.

Signed-off-by: Olivier Fourdan 
---
 v2: No change, just add 2 more patches to the series

 include/xkbsrv.h | 6 ++
 xkb/xkbAccessX.c | 4 +++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/include/xkbsrv.h b/include/xkbsrv.h
index cc6307a..05d5a03 100644
--- a/include/xkbsrv.h
+++ b/include/xkbsrv.h
@@ -142,6 +142,10 @@ typedef struct _XkbFilter {
 struct _XkbFilter *next;
 } XkbFilterRec, *XkbFilterPtr;
 
+typedef Bool (*XkbSrvCheckRepeatPtr) (DeviceIntPtr dev,
+  struct _XkbSrvInfo * /* xkbi */ ,
+  unsigned /* keycode */);
+
 typedef struct _XkbSrvInfo {
 XkbStateRec prev_state;
 XkbStateRec state;
@@ -189,6 +193,8 @@ typedef struct _XkbSrvInfo {
 
 int szFilters;
 XkbFilterPtr filters;
+
+XkbSrvCheckRepeatPtr checkRepeat;
 } XkbSrvInfoRec, *XkbSrvInfoPtr;
 
 #defineXkbSLI_IsDefault(1L<<0)
diff --git a/xkb/xkbAccessX.c b/xkb/xkbAccessX.c
index 02e820b..f59a187 100644
--- a/xkb/xkbAccessX.c
+++ b/xkb/xkbAccessX.c
@@ -89,6 +89,7 @@ AccessXInit(DeviceIntPtr keybd)
 xkbi->repeatKeyTimer = NULL;
 xkbi->krgTimer = NULL;
 xkbi->beepTimer = NULL;
+xkbi->checkRepeat = NULL;
 ctrls->repeat_delay = XkbDfltRepeatDelay;
 ctrls->repeat_interval = XkbDfltRepeatInterval;
 ctrls->debounce_delay = 300;
@@ -317,7 +318,8 @@ AccessXRepeatKeyExpire(OsTimerPtr timer, CARD32 now, void 
*arg)
 if (xkbi->repeatKey == 0)
 return 0;
 
-AccessXKeyboardEvent(dev, ET_KeyPress, xkbi->repeatKey, TRUE);
+if (xkbi->checkRepeat == NULL || xkbi->checkRepeat (dev, xkbi, 
xkbi->repeatKey))
+AccessXKeyboardEvent(dev, ET_KeyPress, xkbi->repeatKey, TRUE);
 
 return xkbi->desc->ctrls->repeat_interval;
 }
-- 
2.5.0

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