Re: [PATCH app/xdpyinfo] Use XRANDR 1.2 extension for reporting dimensions and resolution per output

2017-04-12 Thread Michel Dänzer 
On 13/04/17 12:52 PM, Keith Packard wrote:
> Pali Rohár  writes:
> 
>> Current usage of DisplayWidthMM() and DisplayHeightMM() does not make sense
>> for multi-monitor configuration. In most cases DPI is set to 96 as there is
>> no sane value.
>>
>> Instead when XRANDR 1.2 extension is supported, report dimensions and
>> resolution information per XRANDR monitor output. It should provide
>> correct DPI value.
> 
> I'd be happy for this to be reported as additional information, but I
> suspect there are numerous shell scripts which parse the old information
> which will get confused by any change in the format.

In which case it should probably only be printed with -ext RANDR, to be
consistent with other extensions.


-- 
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: [PATCH app/xdpyinfo] Use XRANDR 1.2 extension for reporting dimensions and resolution per output

2017-04-12 Thread Keith Packard 
Pali Rohár  writes:

> Current usage of DisplayWidthMM() and DisplayHeightMM() does not make sense
> for multi-monitor configuration. In most cases DPI is set to 96 as there is
> no sane value.
>
> Instead when XRANDR 1.2 extension is supported, report dimensions and
> resolution information per XRANDR monitor output. It should provide
> correct DPI value.

I'd be happy for this to be reported as additional information, but I
suspect there are numerous shell scripts which parse the old information
which will get confused by any change in the format.

-- 
-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 app/xdpyinfo] Use XRANDR 1.2 extension for reporting dimensions and resolution per output

2017-04-12 Thread Pali Rohár 
Current usage of DisplayWidthMM() and DisplayHeightMM() does not make sense
for multi-monitor configuration. In most cases DPI is set to 96 as there is
no sane value.

Instead when XRANDR 1.2 extension is supported, report dimensions and
resolution information per XRANDR monitor output. It should provide
correct DPI value.

Lot of users complains about incorrect DPI reported by xdpyinfo, see bug:
https://bugs.freedesktop.org/show_bug.cgi?id=23705

Signed-off-by: Pali Rohár 
---
Without this patch `xdpyinfo | grep -A 4 ^screen` reports:

screen #0:
  dimensions:1600x900 pixels (423x238 millimeters)
  resolution:96x96 dots per inch
  depths (7):24, 1, 4, 8, 15, 16, 32
  root window id:0xf8

Where DPI and also monitor dimensions in millimeters is incorrect.
After applying this patch `xdpyinfo | grep -A 4 ^screen` reports:

screen #0:
  output: eDP1
dimensions:1600x900 pixels (310x170 millimeters)
resolution:131x134 dots per inch
  depths (7):24, 1, 4, 8, 15, 16, 32

And both DPI and monitor dimensions (for eDP1) are correct.
---
 Makefile.am  |2 ++
 configure.ac |   12 
 xdpyinfo.c   |   86 ++
 3 files changed, 82 insertions(+), 18 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 2f21dda..496094e 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -35,6 +35,7 @@ AM_CFLAGS = \
$(DPY_XCOMPOSITE_CFLAGS) \
$(DPY_XINERAMA_CFLAGS) \
$(DPY_DMX_CFLAGS) \
+   $(DPY_XRANDR_CFLAGS) \
$(DPY_XTST_CFLAGS)
 
 xdpyinfo_LDADD = \
@@ -49,6 +50,7 @@ xdpyinfo_LDADD = \
$(DPY_XCOMPOSITE_LIBS) \
$(DPY_XINERAMA_LIBS) \
$(DPY_DMX_LIBS) \
+   $(DPY_XRANDR_LIBS) \
$(DPY_XTST_LIBS)
 
 xdpyinfo_SOURCES = \
diff --git a/configure.ac b/configure.ac
index 73dce26..4473faa 100644
--- a/configure.ac
+++ b/configure.ac
@@ -132,6 +132,18 @@ else
echo "without dmx"
 fi
 
+AC_ARG_WITH(xrandr, AS_HELP_STRING([--without-xrandr],[Disable xrandr 1.2 
support.]),
+   [USE_XRANDR="$withval"], [USE_XRANDR="yes"])
+if test "x$USE_XRANDR" != "xno" ; then
+   PKG_CHECK_MODULES(DPY_XRANDR, xrandr >= 1.2,
+   [SAVE_CPPFLAGS="$CPPFLAGS"
+   CPPFLAGS="$CPPFLAGS $DPY_XRANDR_CFLAGS $DPY_X11_CFLAGS"
+   AC_CHECK_HEADERS([X11/extensions/Xrandr.h],,,[#include 
])
+   CPPFLAGS="$SAVE_CPPFLAGS"],[echo "not found"])
+else
+   echo "without xrandr 1.2"
+fi
+
 PKG_CHECK_MODULES(DPY_XTST, xtst,
[SAVE_CPPFLAGS="$CPPFLAGS"
CPPFLAGS="$CPPFLAGS $DPY_XTST_CFLAGS $DPY_X11_CFLAGS"
diff --git a/xdpyinfo.c b/xdpyinfo.c
index 152e32c..7a75fdc 100644
--- a/xdpyinfo.c
+++ b/xdpyinfo.c
@@ -76,6 +76,10 @@ in this Software without prior written authorization from 
The Open Group.
 #  define DMX
 # endif
 
+# if HAVE_X11_EXTENSIONS_XRANDR_H
+#  define XRANDR
+# endif
+
 #endif
 
 #ifdef WIN32
@@ -137,6 +141,9 @@ in this Software without prior written authorization from 
The Open Group.
 #ifdef DMX
 #include 
 #endif
+#ifdef XRANDR
+#include 
+#endif
 #include 
 #include 
 #include 
@@ -455,27 +462,70 @@ print_screen_info(Display *dpy, int scr)
 double xres, yres;
 int ndepths = 0, *depths = NULL;
 unsigned int width, height;
-
-/*
- * there are 2.54 centimeters to an inch; so there are 25.4 millimeters.
- *
- * dpi = N pixels / (M millimeters / (25.4 millimeters / 1 inch))
- * = N pixels / (M inch / 25.4)
- * = N * 25.4 pixels / M inch
- */
-
-xres = double) DisplayWidth(dpy,scr)) * 25.4) /
-   ((double) DisplayWidthMM(dpy,scr)));
-yres = double) DisplayHeight(dpy,scr)) * 25.4) /
-   ((double) DisplayHeightMM(dpy,scr)));
+#ifdef XRANDR
+int event_base, error_base;
+int major, minor;
+XRRScreenResources *res = NULL;
+XRROutputInfo *output;
+XRRCrtcInfo *crtc;
+#endif
 
 printf ("\n");
 printf ("screen #%d:\n", scr);
-printf ("  dimensions:%dx%d pixels (%dx%d millimeters)\n",
-   XDisplayWidth (dpy, scr),  XDisplayHeight (dpy, scr),
-   XDisplayWidthMM(dpy, scr), XDisplayHeightMM (dpy, scr));
-printf ("  resolution:%dx%d dots per inch\n",
-   (int) (xres + 0.5), (int) (yres + 0.5));
+
+#ifdef XRANDR
+if (XRRQueryExtension (dpy, _base, _base) &&
+XRRQueryVersion (dpy, , ) &&
+(major >= 1 || (major == 1 && minor >= 2)) &&
+(res = XRRGetScreenResources (dpy, RootWindow (dpy, scr
+{
+for (i = 0; i < res->noutput; ++i) {
+output = XRRGetOutputInfo (dpy, res, res->outputs[i]);
+if (!output || !output->crtc || output->connection != RR_Connected)
+continue;
+
+crtc = XRRGetCrtcInfo (dpy, res, output->crtc);
+if (!crtc) {
+XRRFreeOutputInfo (output);
+continue;
+}
+
+printf ("  output:

Re: [PATCH xserver] xfree86/modes: Make colormap/gamma glue code work with RandR disabled

2017-04-12 Thread Mariusz Bialonczyk 
On Wed, 12 Apr 2017 18:34:39 +0900
Michel Dänzer  wrote:

> From: Michel Dänzer 
> 
> E.g. because Xinerama is enabled.
> 
> Fixes crash on startup and wrong colours in that case.
> 
> Bugzilla: https://bugs.freedesktop.org/100293
> Bugzilla: https://bugs.freedesktop.org/100294
> Fixes: 62f44052573b ("xfree86/modes: Move gamma initialization to
>   xf86RandR12Init12 v2")
> 
> Signed-off-by: Michel Dänzer 

Tested-by: Mariusz Bialonczyk 
---

Indeed, xorg is not crashing and colors are correct with xinerama.
Thank you very much for the fix! :)
Please merge this upstream.

regards,
-- 
Mariusz Białończyk | xmpp/e-mail: ma...@skyboo.net
http://manio.skyboo.net | https://github.com/manio
___
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] Improved autoconfig drivers matching

2017-04-12 Thread Emil Velikov 
On 12 April 2017 at 23:05, Aaron Plattner  wrote:
> On 07/12/2016 04:31 PM, Emil Velikov wrote:

>> Since xf86platformBus.h is part of the SDK, If we do this, then the
>> new header must become one as well (should be listed in sdk_HEADERS).
>> Alternatively we can forward declare XF86MatchedDrivers and include
>> the header in EXTRA_DIST. Not sure if the latter is a good idea
>> though, since the actual ABI will be undefined/private.
>>
>> Or better yet, neither of the two exported symbols
>> (xf86PlatformDeviceCheckBusID, xf86PlatformMatchDriver) is used and
>> imho we can remove them. Seems that the header is used solely for the
>> ODEV management, which isn't platform devices specific and one can
>> just move those parts into a separate header and use _it_ in the SDK ?
>>
>> But all that (everything but the sdk_HEADERS/EXTRA_DIST fix) is added
>> bogus, which shouldn't stop the patch from landing.

> Another customer ran into this recently. Adam, can this be merged? I don't
> think Emil's reply was a nack.

Precisely. My earlier message should have read:

xf86MatchDrivers.h must be in the sdk_HEADERS or you'll need build
hacks in each driver. With that the patch is
Reviewed-by: Emil Velikov 

Regards,
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] Improved autoconfig drivers matching

2017-04-12 Thread Aaron Plattner 
Another customer ran into this recently. Adam, can this be merged? I 
don't think Emil's reply was a nack.


On 07/12/2016 04:31 PM, Emil Velikov wrote:

On 23 July 2015 at 00:42, Karol Kosik  wrote:

Implementation of new drivers matching algorithm. New approach
doesn't add duplicate drivers and ease drivers matching phase.

Signed-off-by: Karol Kosik 
---
  hw/xfree86/common/xf86AutoConfig.c   | 124 +++
  hw/xfree86/common/xf86MatchDrivers.h |  40 +++
  hw/xfree86/common/xf86pciBus.c   |  52 ++-
  hw/xfree86/common/xf86pciBus.h   |  13 ++--
  hw/xfree86/common/xf86platformBus.c  |  31 +++--
  hw/xfree86/common/xf86platformBus.h  |   5 +-
  6 files changed, 150 insertions(+), 115 deletions(-)
  create mode 100644 hw/xfree86/common/xf86MatchDrivers.h

diff --git a/hw/xfree86/common/xf86AutoConfig.c 
b/hw/xfree86/common/xf86AutoConfig.c
index 6b8d0eb..440434c 100644
--- a/hw/xfree86/common/xf86AutoConfig.c
+++ b/hw/xfree86/common/xf86AutoConfig.c
@@ -37,6 +37,7 @@
  #include "xf86Parser.h"
  #include "xf86tokens.h"
  #include "xf86Config.h"
+#include "xf86MatchDrivers.h"
  #include "xf86Priv.h"
  #include "xf86_OSlib.h"
  #include "xf86platformBus.h"
@@ -89,7 +90,7 @@
  static const char **builtinConfig = NULL;
  static int builtinLines = 0;

-static void listPossibleVideoDrivers(char *matches[], int nmatches);
+static void listPossibleVideoDrivers(XF86MatchedDrivers *md);

  /*
   * A built-in config file is stored as an array of strings, with each string
@@ -140,33 +141,58 @@ AppendToConfig(const char *s)
  AppendToList(s, , );
  }

+void
+xf86AddMatchedDriver(XF86MatchedDrivers *md, const char *driver)
+{
+int j;
+int nmatches = md->nmatches;
+
+for (j = 0; j < nmatches; ++j) {
+if (xf86NameCmp(md->matches[j], driver) == 0) {
+// Driver already in matched drivers
+return;
+}
+}
+
+if (nmatches < MATCH_DRIVERS_LIMIT) {
+md->matches[nmatches] = xnfstrdup(driver);
+md->nmatches++;
+}
+else {
+xf86Msg(X_WARNING, "Too many drivers registered, can't add %s\n", 
driver);
+}
+}
+
  Bool
  xf86AutoConfig(void)
  {
-char *deviceList[20];
-char **p;
+XF86MatchedDrivers md;
+int i;
  const char **cp;
  char buf[1024];
  ConfigStatus ret;

-listPossibleVideoDrivers(deviceList, 20);
+listPossibleVideoDrivers();

-for (p = deviceList; *p; p++) {
-snprintf(buf, sizeof(buf), BUILTIN_DEVICE_SECTION, *p, 0, *p);
+for (i = 0; i < md.nmatches; i++) {
+snprintf(buf, sizeof(buf), BUILTIN_DEVICE_SECTION,
+md.matches[i], 0, md.matches[i]);
  AppendToConfig(buf);
-snprintf(buf, sizeof(buf), BUILTIN_SCREEN_SECTION, *p, 0, *p, 0);
+snprintf(buf, sizeof(buf), BUILTIN_SCREEN_SECTION,
+md.matches[i], 0, md.matches[i], 0);
  AppendToConfig(buf);
  }

  AppendToConfig(BUILTIN_LAYOUT_SECTION_PRE);
-for (p = deviceList; *p; p++) {
-snprintf(buf, sizeof(buf), BUILTIN_LAYOUT_SCREEN_LINE, *p, 0);
+for (i = 0; i < md.nmatches; i++) {
+snprintf(buf, sizeof(buf), BUILTIN_LAYOUT_SCREEN_LINE,
+md.matches[i], 0);
  AppendToConfig(buf);
  }
  AppendToConfig(BUILTIN_LAYOUT_SECTION_POST);

-for (p = deviceList; *p; p++) {
-free(*p);
+for (i = 0; i < md.nmatches; i++) {
+free(md.matches[i]);
  }

  xf86MsgVerb(X_DEFAULT, 0,
@@ -190,22 +216,19 @@ xf86AutoConfig(void)
  }

  static void
-listPossibleVideoDrivers(char *matches[], int nmatches)
+listPossibleVideoDrivers(XF86MatchedDrivers *md)
  {
  int i;

-for (i = 0; i < nmatches; i++) {
-matches[i] = NULL;
-}
-i = 0;
+md->nmatches = 0;

  #ifdef XSERVER_PLATFORM_BUS
-i = xf86PlatformMatchDriver(matches, nmatches);
+xf86PlatformMatchDriver(md);
  #endif
  #ifdef sun
  /* Check for driver type based on /dev/fb type and if valid, use
 it instead of PCI bus probe results */
-if (xf86Info.consoleFd >= 0 && (i < (nmatches - 1))) {
+if (xf86Info.consoleFd >= 0) {
  struct vis_identifier visid;
  const char *cp;
  int iret;
@@ -231,7 +254,7 @@ listPossibleVideoDrivers(char *matches[], int nmatches)

  /* Special case from before the general case was set */
  if (strcmp(visid.name, "NVDAnvda") == 0) {
-matches[i++] = xnfstrdup("nvidia");
+xf86AddMatchedDriver(md, "nvidia");
  }

  /* General case - split into vendor name (initial all-caps
@@ -241,55 +264,48 @@ listPossibleVideoDrivers(char *matches[], int nmatches)
  /* find end of all uppercase vendor section */
  }
  if ((cp != visid.name) && (*cp != '\0')) {
-char *driverName = xnfstrdup(cp);

Re: [PATCH xserver] xfree86/modes: Make colormap/gamma glue code work with RandR disabled

2017-04-12 Thread Alex Deucher 
On Wed, Apr 12, 2017 at 5:34 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> E.g. because Xinerama is enabled.
>
> Fixes crash on startup and wrong colours in that case.
>
> Bugzilla: https://bugs.freedesktop.org/100293
> Bugzilla: https://bugs.freedesktop.org/100294
> Fixes: 62f44052573b ("xfree86/modes: Move gamma initialization to
>   xf86RandR12Init12 v2")
>
> Signed-off-by: Michel Dänzer 

Reviewed-by: Alex Deucher 

> ---
>  hw/xfree86/modes/xf86RandR12.c | 136 
> +++--
>  1 file changed, 91 insertions(+), 45 deletions(-)
>
> diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
> index 900048df9..55d88e331 100644
> --- a/hw/xfree86/modes/xf86RandR12.c
> +++ b/hw/xfree86/modes/xf86RandR12.c
> @@ -1246,33 +1246,50 @@ xf86RandR12CrtcSet(ScreenPtr pScreen,
>  }
>
>  static void
> -xf86RandR12CrtcComputeGamma(ScreenPtr pScreen, RRCrtcPtr randr_crtc)
> +xf86RandR12CrtcComputeGamma(xf86CrtcPtr crtc, LOCO *palette,
> +int palette_red_size, int palette_green_size,
> +int palette_blue_size, CARD16 *gamma_red,
> +CARD16 *gamma_green, CARD16 *gamma_blue,
> +int gamma_size)
>  {
> -XF86RandRInfoPtr randrp = XF86RANDRINFO(pScreen);
> -xf86CrtcPtr crtc = randr_crtc->devPrivate;
>  int gamma_slots;
> -CARD16 value;
> +unsigned shift;
> +CARD32 value;
>  int i, j;
>
> -gamma_slots = crtc->gamma_size / randrp->palette_red_size;
> -for (i = 0; i < randrp->palette_red_size; i++) {
> -value = randr_crtc->gammaRed[randrp->palette[i].red];
> +for (shift = 0; (gamma_size << shift) < (1 << 16); shift++);
> +
> +gamma_slots = crtc->gamma_size / palette_red_size;
> +for (i = 0; i < palette_red_size; i++) {
> +value = palette[i].red;
> +if (gamma_red)
> +value = gamma_red[value];
> +else
> +value <<= shift;
>
>  for (j = 0; j < gamma_slots; j++)
>  crtc->gamma_red[i * gamma_slots + j] = value;
>  }
>
> -gamma_slots = crtc->gamma_size / randrp->palette_green_size;
> -for (i = 0; i < randrp->palette_green_size; i++) {
> -value = randr_crtc->gammaGreen[randrp->palette[i].green];
> +gamma_slots = crtc->gamma_size / palette_green_size;
> +for (i = 0; i < palette_green_size; i++) {
> +value = palette[i].green;
> +if (gamma_green)
> +value = gamma_green[value];
> +else
> +value <<= shift;
>
>  for (j = 0; j < gamma_slots; j++)
>  crtc->gamma_green[i * gamma_slots + j] = value;
>  }
>
> -gamma_slots = crtc->gamma_size / randrp->palette_blue_size;
> -for (i = 0; i < randrp->palette_blue_size; i++) {
> -value = randr_crtc->gammaBlue[randrp->palette[i].blue];
> +gamma_slots = crtc->gamma_size / palette_blue_size;
> +for (i = 0; i < palette_blue_size; i++) {
> +value = palette[i].blue;
> +if (gamma_blue)
> +value = gamma_blue[value];
> +else
> +value <<= shift;
>
>  for (j = 0; j < gamma_slots; j++)
>  crtc->gamma_blue[i * gamma_slots + j] = value;
> @@ -1280,10 +1297,8 @@ xf86RandR12CrtcComputeGamma(ScreenPtr pScreen, 
> RRCrtcPtr randr_crtc)
>  }
>
>  static void
> -xf86RandR12CrtcReloadGamma(RRCrtcPtr randr_crtc)
> +xf86RandR12CrtcReloadGamma(xf86CrtcPtr crtc)
>  {
> -xf86CrtcPtr crtc = randr_crtc->devPrivate;
> -
>  if (!crtc->scrn->vtSema || !crtc->funcs->gamma_set)
>  return;
>
> @@ -1305,7 +1320,14 @@ xf86RandR12CrtcSetGamma(ScreenPtr pScreen, RRCrtcPtr 
> randr_crtc)
>  return FALSE;
>
>  if (randrp->palette_size) {
> -xf86RandR12CrtcComputeGamma(pScreen, randr_crtc);
> +xf86RandR12CrtcComputeGamma(crtc, randrp->palette,
> +randrp->palette_red_size,
> +randrp->palette_green_size,
> +randrp->palette_blue_size,
> +randr_crtc->gammaRed,
> +randr_crtc->gammaGreen,
> +randr_crtc->gammaBlue,
> +randr_crtc->gammaSize);
>  } else {
>  memcpy(crtc->gamma_red, randr_crtc->gammaRed,
> crtc->gamma_size * sizeof(crtc->gamma_red[0]));
> @@ -1315,7 +1337,7 @@ xf86RandR12CrtcSetGamma(ScreenPtr pScreen, RRCrtcPtr 
> randr_crtc)
> crtc->gamma_size * sizeof(crtc->gamma_blue[0]));
>  }
>
> -xf86RandR12CrtcReloadGamma(randr_crtc);
> +xf86RandR12CrtcReloadGamma(crtc);
>
>  return TRUE;
>  }
> @@ -1390,6 +1412,13 @@ xf86RandR12OutputInitGamma(xf86OutputPtr output)
>   * different gamma
>   */
>

Re: [PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

2017-04-12 Thread Manasi Navare 
On Wed, Apr 12, 2017 at 11:00:18AM -0700, Eric Anholt wrote:
> Martin Peres  writes:
> 
> > On 11/04/17 04:47, Eric Anholt wrote:
> >> Martin Peres  writes:
> >>
> >>> Despite all the careful planing of the kernel, a link may become
> >>> insufficient to handle the currently-set mode. At this point, the
> >>> kernel should mark this particular configuration as being broken
> >>> and potentially prune the mode before setting the offending connector's
> >>> link-status to BAD and send the userspace a hotplug event. This may
> >>> happen right after a modeset or later on.
> >>>
> >>> Upon receiving a hot-plug event, we iterate through the connectors to
> >>> re-apply the currently-set mode on all the connectors that have a
> >>> link-status property set to BAD. This modeset may fail immediatly if
> >>> the kernel has already pruned the mode we are trying to set but it
> >>> does not matter as -modesetting has no business picking another
> >>> mode if the modeset did fail. To make users aware of this problem
> >>
> >> I think I'd like to replace the "This modeset" sentence with "The kernel
> >> may be able to get the link to work by dropping to using a lower link
> >> bpp (with the same display bpp).  However, the modeset may fail if the
> >> kernel has pruned the mode, so to make users aware..."  Does that sound
> >> good to you?
> >
> > Yep, nice improvement. Thanks!
> 
> Pushed.  Thanks, and sorry this took *so* long.

Thanks Eric for your review and for pushing the patch.
Thanks Martin for the patch. 

Do you know which Xserver release would this be part of?
Which Xserver version would be required for the entire end to end
testing with this feature?

Regards
Manasi



> ___
> 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: [PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

2017-04-12 Thread Eric Anholt 
Martin Peres  writes:

> On 11/04/17 04:47, Eric Anholt wrote:
>> Martin Peres  writes:
>>
>>> Despite all the careful planing of the kernel, a link may become
>>> insufficient to handle the currently-set mode. At this point, the
>>> kernel should mark this particular configuration as being broken
>>> and potentially prune the mode before setting the offending connector's
>>> link-status to BAD and send the userspace a hotplug event. This may
>>> happen right after a modeset or later on.
>>>
>>> Upon receiving a hot-plug event, we iterate through the connectors to
>>> re-apply the currently-set mode on all the connectors that have a
>>> link-status property set to BAD. This modeset may fail immediatly if
>>> the kernel has already pruned the mode we are trying to set but it
>>> does not matter as -modesetting has no business picking another
>>> mode if the modeset did fail. To make users aware of this problem
>>
>> I think I'd like to replace the "This modeset" sentence with "The kernel
>> may be able to get the link to work by dropping to using a lower link
>> bpp (with the same display bpp).  However, the modeset may fail if the
>> kernel has pruned the mode, so to make users aware..."  Does that sound
>> good to you?
>
> Yep, nice improvement. Thanks!

Pushed.  Thanks, and sorry this took *so* long.


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

Re: [PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

2017-04-12 Thread Martin Peres 

On 11/04/17 04:47, Eric Anholt wrote:

Martin Peres  writes:


Despite all the careful planing of the kernel, a link may become
insufficient to handle the currently-set mode. At this point, the
kernel should mark this particular configuration as being broken
and potentially prune the mode before setting the offending connector's
link-status to BAD and send the userspace a hotplug event. This may
happen right after a modeset or later on.

Upon receiving a hot-plug event, we iterate through the connectors to
re-apply the currently-set mode on all the connectors that have a
link-status property set to BAD. This modeset may fail immediatly if
the kernel has already pruned the mode we are trying to set but it
does not matter as -modesetting has no business picking another
mode if the modeset did fail. To make users aware of this problem


I think I'd like to replace the "This modeset" sentence with "The kernel
may be able to get the link to work by dropping to using a lower link
bpp (with the same display bpp).  However, the modeset may fail if the
kernel has pruned the mode, so to make users aware..."  Does that sound
good to you?


Yep, nice improvement. Thanks!



I'll give this patch a day or two for anyone else to complain, then I'll
push.


a warning is outputed in the logs to warn about having a
potentially-black display.

This patch does not modify the current behaviour of always propagating
the events to the randr clients. This allows desktop environments to
re-probe the connectors and select a new resolution based on the new
(currated) mode list if a mode disapeared. This behaviour is expected in
order to pass the Display Port compliance tests.

Signed-off-by: Martin Peres 




___
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: [PATCH] release.sh: redefine GPGKEY if already existing

2017-04-12 Thread Emil Velikov 
On 7 April 2017 at 14:26, Andres Gomez  wrote:
> GPGKEY may already exist in the environment. In that case, just
> redefine it adding "-u"
>
> Signed-off-by: Andres Gomez 
> Cc: Emil Velikov 
> Cc: Peter Hutterer 
> ---
>  release.sh | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/release.sh b/release.sh
> index f976f94..e5e699d 100755
> --- a/release.sh
> +++ b/release.sh
> @@ -808,6 +808,11 @@ if [ "x$GPG" = "x" ] ; then
>  fi
>  fi
>
> +# Redefine GPGKEY if needed
> +if [ "x$GPGKEY" != "x" ] ; then
> +GPGKEY="-u $GPGKEY"
> +fi
> +
Fine with me.
Reviewed-by: Emil Velikov 

I'll push this over the weekend if nobody objects or beats me to it.
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] xwayland: Small comment edit

2017-04-12 Thread Daniel Stone 
Hi Roman,

On 11 April 2017 at 14:52, Roman Gilg  wrote:
> Be more precise in describing the return value.

Thanks! I don't commit to the X server, but someone should pick this
up and merge shortly.

Reviewed-by: Daniel Stone 

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

[PATCH xserver] xfree86/modes: Make colormap/gamma glue code work with RandR disabled

2017-04-12 Thread Michel Dänzer 
From: Michel Dänzer 

E.g. because Xinerama is enabled.

Fixes crash on startup and wrong colours in that case.

Bugzilla: https://bugs.freedesktop.org/100293
Bugzilla: https://bugs.freedesktop.org/100294
Fixes: 62f44052573b ("xfree86/modes: Move gamma initialization to
  xf86RandR12Init12 v2")

Signed-off-by: Michel Dänzer 
---
 hw/xfree86/modes/xf86RandR12.c | 136 +++--
 1 file changed, 91 insertions(+), 45 deletions(-)

diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
index 900048df9..55d88e331 100644
--- a/hw/xfree86/modes/xf86RandR12.c
+++ b/hw/xfree86/modes/xf86RandR12.c
@@ -1246,33 +1246,50 @@ xf86RandR12CrtcSet(ScreenPtr pScreen,
 }
 
 static void
-xf86RandR12CrtcComputeGamma(ScreenPtr pScreen, RRCrtcPtr randr_crtc)
+xf86RandR12CrtcComputeGamma(xf86CrtcPtr crtc, LOCO *palette,
+int palette_red_size, int palette_green_size,
+int palette_blue_size, CARD16 *gamma_red,
+CARD16 *gamma_green, CARD16 *gamma_blue,
+int gamma_size)
 {
-XF86RandRInfoPtr randrp = XF86RANDRINFO(pScreen);
-xf86CrtcPtr crtc = randr_crtc->devPrivate;
 int gamma_slots;
-CARD16 value;
+unsigned shift;
+CARD32 value;
 int i, j;
 
-gamma_slots = crtc->gamma_size / randrp->palette_red_size;
-for (i = 0; i < randrp->palette_red_size; i++) {
-value = randr_crtc->gammaRed[randrp->palette[i].red];
+for (shift = 0; (gamma_size << shift) < (1 << 16); shift++);
+
+gamma_slots = crtc->gamma_size / palette_red_size;
+for (i = 0; i < palette_red_size; i++) {
+value = palette[i].red;
+if (gamma_red)
+value = gamma_red[value];
+else
+value <<= shift;
 
 for (j = 0; j < gamma_slots; j++)
 crtc->gamma_red[i * gamma_slots + j] = value;
 }
 
-gamma_slots = crtc->gamma_size / randrp->palette_green_size;
-for (i = 0; i < randrp->palette_green_size; i++) {
-value = randr_crtc->gammaGreen[randrp->palette[i].green];
+gamma_slots = crtc->gamma_size / palette_green_size;
+for (i = 0; i < palette_green_size; i++) {
+value = palette[i].green;
+if (gamma_green)
+value = gamma_green[value];
+else
+value <<= shift;
 
 for (j = 0; j < gamma_slots; j++)
 crtc->gamma_green[i * gamma_slots + j] = value;
 }
 
-gamma_slots = crtc->gamma_size / randrp->palette_blue_size;
-for (i = 0; i < randrp->palette_blue_size; i++) {
-value = randr_crtc->gammaBlue[randrp->palette[i].blue];
+gamma_slots = crtc->gamma_size / palette_blue_size;
+for (i = 0; i < palette_blue_size; i++) {
+value = palette[i].blue;
+if (gamma_blue)
+value = gamma_blue[value];
+else
+value <<= shift;
 
 for (j = 0; j < gamma_slots; j++)
 crtc->gamma_blue[i * gamma_slots + j] = value;
@@ -1280,10 +1297,8 @@ xf86RandR12CrtcComputeGamma(ScreenPtr pScreen, RRCrtcPtr 
randr_crtc)
 }
 
 static void
-xf86RandR12CrtcReloadGamma(RRCrtcPtr randr_crtc)
+xf86RandR12CrtcReloadGamma(xf86CrtcPtr crtc)
 {
-xf86CrtcPtr crtc = randr_crtc->devPrivate;
-
 if (!crtc->scrn->vtSema || !crtc->funcs->gamma_set)
 return;
 
@@ -1305,7 +1320,14 @@ xf86RandR12CrtcSetGamma(ScreenPtr pScreen, RRCrtcPtr 
randr_crtc)
 return FALSE;
 
 if (randrp->palette_size) {
-xf86RandR12CrtcComputeGamma(pScreen, randr_crtc);
+xf86RandR12CrtcComputeGamma(crtc, randrp->palette,
+randrp->palette_red_size,
+randrp->palette_green_size,
+randrp->palette_blue_size,
+randr_crtc->gammaRed,
+randr_crtc->gammaGreen,
+randr_crtc->gammaBlue,
+randr_crtc->gammaSize);
 } else {
 memcpy(crtc->gamma_red, randr_crtc->gammaRed,
crtc->gamma_size * sizeof(crtc->gamma_red[0]));
@@ -1315,7 +1337,7 @@ xf86RandR12CrtcSetGamma(ScreenPtr pScreen, RRCrtcPtr 
randr_crtc)
crtc->gamma_size * sizeof(crtc->gamma_blue[0]));
 }
 
-xf86RandR12CrtcReloadGamma(randr_crtc);
+xf86RandR12CrtcReloadGamma(crtc);
 
 return TRUE;
 }
@@ -1390,6 +1412,13 @@ xf86RandR12OutputInitGamma(xf86OutputPtr output)
  * different gamma
  */
 if (gamma_red != 1.0 || gamma_green != 1.0 || gamma_blue != 1.0) {
+if (!output->crtc->randr_crtc) {
+xf86DrvMsg(output->scrn->scrnIndex, X_WARNING,
+   "Gamma correction for output %s not possible because "
+   "RandR is disabled\n", output->name);
+return TRUE;
+}
+

Re: [PATCH 2/2 v3] Add keyboard shortcuts inhibitor

2017-04-12 Thread Jonas Ådahl 
On Wed, Apr 05, 2017 at 02:30:15PM +0200, Olivier Fourdan wrote:
> This adds a new protocol to let Wayland clients specify that they want
> all keyboard events to be send to the client, regardless of the
> compositor own shortcuts.
> 
> This is for use by virtual machine and remote connections viewers.

Look out for style nits (especially now that Yong has cleaned up
inconsistencies in the other protocol XML files!), but there are some
other comments below too.

> 
> Signed-off-by: Olivier Fourdan 
> ---
>  v2: Clarify that that the compositor is under no obligation to ignore
>  every shortcut (ajax)
>  Add "inhibit_active" and "inhibit_inactive" events to notify clients
>  Add "already_inhibited" error
>  v3: Rename "inhibit_active" and "inhibit_inactive" events to simply
>  "active" and "inactive" and fix some Tab in the middle of the text.
> 
>  Makefile.am|   1 +
>  unstable/keyboard-shortcuts-inhibit/README |   4 +
>  .../keyboard-shortcuts-inhibit-unstable-v1.xml | 132 
> +
>  3 files changed, 137 insertions(+)
>  create mode 100644 unstable/keyboard-shortcuts-inhibit/README
>  create mode 100644 
> unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index 12465e6..d100c13 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -13,6 +13,7 @@ unstable_protocols =
> \
>   unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> \
>   unstable/idle-inhibit/idle-inhibit-unstable-v1.xml  
> \
>   unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml  
> \
> + 
> unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
>  \
>   $(NULL)
>  
>  stable_protocols =   
> \
> diff --git a/unstable/keyboard-shortcuts-inhibit/README 
> b/unstable/keyboard-shortcuts-inhibit/README
> new file mode 100644
> index 000..63ff335
> --- /dev/null
> +++ b/unstable/keyboard-shortcuts-inhibit/README
> @@ -0,0 +1,4 @@
> +Compositor shortcuts inhibit protocol
> +
> +Maintainers:
> +Olivier Fourdan 
> diff --git 
> a/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
>  
> b/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
> new file mode 100644
> index 000..bb35de1
> --- /dev/null
> +++ 
> b/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
> @@ -0,0 +1,132 @@
> +
> +
> +
> +  
> + Copyright © 2017 Red Hat Inc.
> +
> + 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.

Indentation issue.

> +  
> +
> +  
> + This protocol specifies a way for a client to request the compositor
> + to ignore its own keyboard shortcuts, so that all keyboard events
> + get forwarded to a surface.
> +
> + Warning! The protocol described in this file is experimental and
> + backward incompatible changes may be made. Backward compatible
> + changes may be added together with the corresponding interface
> + version bump.
> + Backward incompatible changes are done by bumping the version
> + number in the protocol and interface names and resetting the
> + interface version. Once the protocol is to be declared stable,
> + the 'z' prefix and the version number in the protocol and
> + interface names are removed and the interface version number is
> + reset.

Indentation issue

> +  
> +
> +  
> +

Stray newline, and missing .

> +
> +  
> + Destroy the keyboard shortcuts inhibitor manager.
> +  
> +
> +
> +
> +  
> + Create a new

Re: [PATCH 1/2] Introduce keyboard grabbing protocol for Xwayland

2017-04-12 Thread Jonas Ådahl 
On Mon, Apr 03, 2017 at 09:45:46AM -0400, Olivier Fourdan wrote:
> Hey Peter,
> 
> Thanks for the review!
> 
> > woohoo, grabs. My favourite topic! ;)
> > 
> > Mostly ok, a few complaints regarding the documentation but the protocol is
> > fine from my POV.
> > 
> > On Wed, Mar 22, 2017 at 05:27:22PM +0100, Olivier Fourdan wrote:
> > > This patch introduces a new protocol for grabbing the keyboard from
> > > Xwayland.
> > > 
> > > This is needed for X11 applications that map an override redirect window
> > > (ths not focused by the window manager) and issue an active grab on the
> > 
> > /me buys a 'u'
> 
> oh, 'u' are so overpriced these days... ^_~
> 
> > > keyboard to capture all keyboard events.
> > > 
> > > Signed-off-by: Olivier Fourdan 
> > > ---
> > >  Makefile.am|   2 +
> > >  configure.ac   |   2 +-
> > >  unstable/xwayland-keyboard-grab/README |   4 +
> > >  .../xwayland-keyboard-grab-unstable-v1.xml | 101
> > >  +
> > >  4 files changed, 108 insertions(+), 1 deletion(-)
> > >  create mode 100644 unstable/xwayland-keyboard-grab/README
> > >  create mode 100644
> > >  unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
> > > 
> > > diff --git a/Makefile.am b/Makefile.am
> > > index e693afa..d100c13 100644
> > > --- a/Makefile.am
> > > +++ b/Makefile.am
> > > @@ -12,6 +12,8 @@ unstable_protocols =
> > > \
> > >   unstable/tablet/tablet-unstable-v2.xml  
> > > \
> > >   unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> > > \
> > >   unstable/idle-inhibit/idle-inhibit-unstable-v1.xml  
> > > \
> > > + unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml  
> > > \
> > > +
> > >   
> > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
> > > \
> > >   $(NULL)
> > >  
> > >  stable_protocols =   
> > > \
> > > diff --git a/configure.ac b/configure.ac
> > > index fbb0ec2..e98bceb 100644
> > > --- a/configure.ac
> > > +++ b/configure.ac
> > > @@ -1,7 +1,7 @@
> > >  AC_PREREQ([2.64])
> > >  
> > >  m4_define([wayland_protocols_major_version], [1])
> > > -m4_define([wayland_protocols_minor_version], [7])
> > > +m4_define([wayland_protocols_minor_version], [8])
> > >  m4_define([wayland_protocols_version],
> > >
> > > [wayland_protocols_major_version.wayland_protocols_minor_version])
> > >  
> > > diff --git a/unstable/xwayland-keyboard-grab/README
> > > b/unstable/xwayland-keyboard-grab/README
> > > new file mode 100644
> > > index 000..dbe45a5
> > > --- /dev/null
> > > +++ b/unstable/xwayland-keyboard-grab/README
> > > @@ -0,0 +1,4 @@
> > > +Xwayland keyboard grabbing protocol
> > > +
> > > +Maintainers:
> > > +Olivier Fourdan 
> > > diff --git
> > > a/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
> > > b/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
> > > new file mode 100644
> > > index 000..31dc365
> > > --- /dev/null
> > > +++
> > > b/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
> > > @@ -0,0 +1,101 @@
> > > +
> > > +
> > > +
> > > +  
> > > + Copyright © 2017 Red Hat Inc.
> > > +
> > > + 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.
> > > +  
> > > +
> > > +  
> > > + This protocol specifies a way for Xwayland to request all keyboard
> > > + events to be forwarded to a surface even when the surface does not
> > > + have keyboard focus.
> > > +
> > > + Unlike the X11 protocol, Wayland doesn't have the notion of
> > > + active grab on

Re: [PATCH 1/2] Introduce keyboard grabbing protocol for Xwayland

2017-04-12 Thread Jonas Ådahl 
On Wed, Mar 22, 2017 at 05:27:22PM +0100, Olivier Fourdan wrote:
> This patch introduces a new protocol for grabbing the keyboard from
> Xwayland.
> 
> This is needed for X11 applications that map an override redirect window
> (ths not focused by the window manager) and issue an active grab on the
> keyboard to capture all keyboard events.
> 

Here are some input; I'll also send some others as a reply to another
mail in this thread, but these are more "standalone" and nitpick:y.

> Signed-off-by: Olivier Fourdan 
> ---
>  Makefile.am|   2 +
>  configure.ac   |   2 +-
>  unstable/xwayland-keyboard-grab/README |   4 +
>  .../xwayland-keyboard-grab-unstable-v1.xml | 101 
> +
>  4 files changed, 108 insertions(+), 1 deletion(-)
>  create mode 100644 unstable/xwayland-keyboard-grab/README
>  create mode 100644 
> unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index e693afa..d100c13 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -12,6 +12,8 @@ unstable_protocols =
> \
>   unstable/tablet/tablet-unstable-v2.xml  
> \
>   unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> \
>   unstable/idle-inhibit/idle-inhibit-unstable-v1.xml  
> \
> + unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml  
> \
> + 
> unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
>  \
>   $(NULL)
>  
>  stable_protocols =   
> \
> diff --git a/configure.ac b/configure.ac
> index fbb0ec2..e98bceb 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1,7 +1,7 @@
>  AC_PREREQ([2.64])
>  
>  m4_define([wayland_protocols_major_version], [1])
> -m4_define([wayland_protocols_minor_version], [7])
> +m4_define([wayland_protocols_minor_version], [8])

Leave the version bumping to the release process.

>  m4_define([wayland_protocols_version],
>[wayland_protocols_major_version.wayland_protocols_minor_version])
>  
> diff --git a/unstable/xwayland-keyboard-grab/README 
> b/unstable/xwayland-keyboard-grab/README
> new file mode 100644
> index 000..dbe45a5
> --- /dev/null
> +++ b/unstable/xwayland-keyboard-grab/README
> @@ -0,0 +1,4 @@
> +Xwayland keyboard grabbing protocol
> +
> +Maintainers:
> +Olivier Fourdan 
> diff --git 
> a/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml 
> b/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
> new file mode 100644
> index 000..31dc365
> --- /dev/null
> +++ b/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
> @@ -0,0 +1,101 @@
> +
> +
> +
> +  
> + Copyright © 2017 Red Hat Inc.
> +
> + 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.

Indentation seems wrong.

> +  
> +
> +  
> + This protocol specifies a way for Xwayland to request all keyboard
> + events to be forwarded to a surface even when the surface does not
> + have keyboard focus.
> +
> + Unlike the X11 protocol, Wayland doesn't have the notion of
> + active grab on the keyboard.
> +
> + When an X11 client acquires an active grab on the keyboard, all
> + key events are reported only to the grabbing X11 client.
> + When running in Xwayland, X11 applications may acquire an active
> + grab but that cannot be translated to the Wayland compositor who
> + may set the input focus to some other surface, thus breaking the
> + X11 client assumption that all key events are reported.
> +
> + When an X11 client