[PATCH xserver] xwayland: fix order of calloc() args

2016-11-22 Thread Pekka Paalanen 
From: Pekka Paalanen 

The definition by the manual is:
calloc(size_t nmemb, size_t size)

Swap the arguments of calloc() calls to be the right way around.

Presumably this makes no functional difference, but better follow the
spec.

Signed-off-by: Pekka Paalanen 
---
 hw/xwayland/xwayland-input.c  | 6 +++---
 hw/xwayland/xwayland-output.c | 2 +-
 hw/xwayland/xwayland.c| 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index 0526122..cc03961 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -847,7 +847,7 @@ touch_handle_down(void *data, struct wl_touch *wl_touch,
 if (surface == NULL)
 return;
 
-xwl_touch = calloc(sizeof *xwl_touch, 1);
+xwl_touch = calloc(1, sizeof *xwl_touch);
 if (xwl_touch == NULL) {
 ErrorF("touch_handle_down ENOMEM");
 return;
@@ -1118,7 +1118,7 @@ create_input_device(struct xwl_screen *xwl_screen, 
uint32_t id, uint32_t version
 {
 struct xwl_seat *xwl_seat;
 
-xwl_seat = calloc(sizeof *xwl_seat, 1);
+xwl_seat = calloc(1, sizeof *xwl_seat);
 if (xwl_seat == NULL) {
 ErrorF("create_input ENOMEM\n");
 return;
@@ -1445,7 +1445,7 @@ xwl_pointer_warp_emulator_create(struct xwl_seat 
*xwl_seat)
 {
 struct xwl_pointer_warp_emulator *warp_emulator;
 
-warp_emulator = calloc(sizeof *warp_emulator, 1);
+warp_emulator = calloc(1, sizeof *warp_emulator);
 if (!warp_emulator) {
 ErrorF("%s: ENOMEM", __func__);
 return NULL;
diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index ef3b6f6..f3ce763 100644
--- a/hw/xwayland/xwayland-output.c
+++ b/hw/xwayland/xwayland-output.c
@@ -242,7 +242,7 @@ xwl_output_create(struct xwl_screen *xwl_screen, uint32_t 
id)
 static int serial;
 char name[256];
 
-xwl_output = calloc(sizeof *xwl_output, 1);
+xwl_output = calloc(1, sizeof *xwl_output);
 if (xwl_output == NULL) {
 ErrorF("create_output ENOMEM\n");
 return NULL;
diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index c277870..9e1ecf8 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -319,7 +319,7 @@ xwl_realize_window(WindowPtr window)
 return ret;
 }
 
-xwl_window = calloc(sizeof *xwl_window, 1);
+xwl_window = calloc(1, sizeof *xwl_window);
 if (xwl_window == NULL)
 return FALSE;
 
@@ -688,7 +688,7 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
 Pixel red_mask, blue_mask, green_mask;
 int ret, bpc, green_bpc, i;
 
-xwl_screen = calloc(sizeof *xwl_screen, 1);
+xwl_screen = calloc(1, sizeof *xwl_screen);
 if (xwl_screen == NULL)
 return FALSE;
 xwl_screen->wm_fd = -1;
-- 
2.7.3

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

Re: [PATCH xserver] configure: Enable glamor when building just Xwayland

2016-11-22 Thread Alan Coopersmith 

On 11/22/16 04:58 PM, Eric Anholt wrote:

Adam Jackson  writes:


Signed-off-by: Adam Jackson 
---
 configure.ac | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 6fd853b..93c81a6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2138,10 +2138,7 @@ AM_CONDITIONAL([XORG_DRIVER_MODESETTING], [test 
"x$XORG_DRIVER_MODESETTING" = xy

 dnl glamor
 if test "x$GLAMOR" = xauto; then
-   if test "x$XORG" = xyes; then
-   GLAMOR=yes
-   fi
-   if test "x$XEPHYR" = xyes; then
+   if echo "$XORG" "$XEPHYR" "$XWAYLAND" | grep -q yes ; then
GLAMOR=yes
fi
 fi


Doesn't that want a "> /dev/null" to not spit the 'yes' into the
configure output?  Other than that, this is great.


Isn't that what the -q option to grep does?

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] configure: Enable glamor when building just Xwayland

2016-11-22 Thread Eric Anholt 
Adam Jackson  writes:

> Signed-off-by: Adam Jackson 
> ---
>  configure.ac | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 6fd853b..93c81a6 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2138,10 +2138,7 @@ AM_CONDITIONAL([XORG_DRIVER_MODESETTING], [test 
> "x$XORG_DRIVER_MODESETTING" = xy
>  
>  dnl glamor
>  if test "x$GLAMOR" = xauto; then
> - if test "x$XORG" = xyes; then
> - GLAMOR=yes
> - fi
> - if test "x$XEPHYR" = xyes; then
> + if echo "$XORG" "$XEPHYR" "$XWAYLAND" | grep -q yes ; then
>   GLAMOR=yes
>   fi
>  fi

Doesn't that want a "> /dev/null" to not spit the 'yes' into the
configure output?  Other than that, this is great.


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

[PATCH xserver] configure: Enable glamor when building just Xwayland

2016-11-22 Thread Adam Jackson 
Signed-off-by: Adam Jackson 
---
 configure.ac | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 6fd853b..93c81a6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2138,10 +2138,7 @@ AM_CONDITIONAL([XORG_DRIVER_MODESETTING], [test 
"x$XORG_DRIVER_MODESETTING" = xy
 
 dnl glamor
 if test "x$GLAMOR" = xauto; then
-   if test "x$XORG" = xyes; then
-   GLAMOR=yes
-   fi
-   if test "x$XEPHYR" = xyes; then
+   if echo "$XORG" "$XEPHYR" "$XWAYLAND" | grep -q yes ; then
GLAMOR=yes
fi
 fi
-- 
2.9.3

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

Re: [PATCH xserver] configure: Enable glamor when building just Xwayland

2016-11-22 Thread Daniel Stone 
On 22 November 2016 at 15:51, Adam Jackson  wrote:
> Signed-off-by: Adam Jackson 

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

Re: [PATCH xserver 2/2] randr: rrCheckPixmapBounding: do not shrink the screen_pixmap

2016-11-22 Thread Hans de Goede 

Hi,

On 22-11-16 15:28, Hans de Goede wrote:

The purpose of rrCheckPixmapBounding is to make sure that the
screen_pixmap is *large* enough for the slave-output which crtc is
being configured.

However until now rrCheckPixmapBounding would also shrink the
screen_pixmap in certain scenarios leading to various problems.

For example: Take a laptop with its internalscreen on a slave-output and
currently disabled and an external monitor at 1920x1080+0+0.
Now lets say that we want to drive the external monitor at its native
resolution of 2560x1440 and have the internal screen mirror the top left
part of the external monitor, so we run:

  $ xrandr --output eDP --mode 1920x1080 --pos 0x0 --output HDMI \
  --mode 2560x1440 --pos 0x0

Here xrandr utility first calls RRSetScreenSize to 2560x1440, then it
calls RRSetCrtc 1920x1080+0+0 on the eDP, since this is a slave output,
rrCheckPixmapBounding gets called and resizes the screen_pixmap to
1920x1080, undoing the RRSetScreenSize. Then RRSetCrtc 2560x1440+0+0
gets called on the HDMI, depending on crtc->transforms this will
either result in a BadValue error from ProcRRSetCrtcConfig; or
it will succeed, but the monitor ends up running at 2560x1440
while showing a 1920x1080 screen_pixmap + black borders on the right
and bottom. Neither of which is what we want.

This commit removes the troublesome shrinking behavior, fixing this.

Note:

1) One could argue that this will leave us with a too large screen_pixmap
in some cases, but rrCheckPixmapBounding only gets called for slave
outputs, so xrandr clients already must manually shrink the screen_pixmap
after disabling crtcs in normal setups.

2) An alternative approach would be to also call rrCheckPixmapBounding
on RRSetCrtc on normal (non-slave) outputs, but that would result in
2 unnecessary resizes of the screen_pixmap in the above example, which
seems undesirable.

Cc: Nikhil Mahale 
Cc: Dave Airlie 
Signed-off-by: Hans de Goede 


p.s.

Nikhil, this should actually fix the issue you were trying to fix with this
patch: https://patchwork.freedesktop.org/patch/88159/

Also I'm pretty sure your patch did not actually fix this, as it
disabled the BadValue check for slave-outputs (GPU-screens), but the
BadValue error will actually trigger when setting up the non-slave
output, after calling RRSetCrtc on the slave-output and
rrCheckPixmapBounding has shrunk the screen_pixmap.

Also just disabling the check is no good, the shrinking is the problem,
not the check.

Regards,

Hans




---
 randr/rrcrtc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index ac853ea..d1a51f0 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -689,6 +689,12 @@ rrCheckPixmapBounding(ScreenPtr pScreen,
 new_width = newsize->x2;
 new_height = newsize->y2;

+if (new_width < screen_pixmap->drawable.width)
+new_width = screen_pixmap->drawable.width;
+
+if (new_height < screen_pixmap->drawable.height)
+new_height = screen_pixmap->drawable.height;
+
 if (new_width == screen_pixmap->drawable.width &&
 new_height == screen_pixmap->drawable.height) {
 } else {


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

[PATCH xserver 1/2] randr: rrCheckPixmapBounding: Do not substract crtc non 0 x, y from screen size

2016-11-22 Thread Hans de Goede 
The purpose of rrCheckPixmapBounding is to make sure that the
screen_pixmap is large enough for the slave-output which crtc is
being configured.

This should include crtc->x and crtc->y, otherwise the crtc might
still end up scanning out an area outside of the screen-pixmap.

For example: Take a laptop with an external monitor on a slave-output at
1920x1080+0+0 and its internal-screen at 3840x2160+1920+0 and in
gnome-settings-daemon move the external monitor to be on the ri ght of
the internal screen rather then on the left. First g-s-d will do a
RRSetScreenSize to 5760*2160 (which is a nop), then it calls RRSetCrtc
to move the slave output to 1920x1080+3840+0, since this is a slave
output, rrCheckPixmapBounding gets called, since the 2 crtcs now overlap
the code before this commit would shrinks the screen_pixmap to 3180*2160.
Then g-s-d calls RRSetCrtc to move the internal screen to 3180*2160+0+0.

And we end up with the slave-output configured to scan-out an area
which completely falls outside of the screen-pixmap (and end up with
a black display on the external monitor).

This commit fixes this by not substracting the x1 and y1 coordinates
of the union-ed region when determining the new screen_pixmap size.

Cc: Nikhil Mahale 
Cc: Dave Airlie 
Signed-off-by: Hans de Goede 
---
 randr/rrcrtc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index 5d404e8..ac853ea 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -686,8 +686,8 @@ rrCheckPixmapBounding(ScreenPtr pScreen,
 }
 
 newsize = RegionExtents(_region);
-new_width = newsize->x2 - newsize->x1;
-new_height = newsize->y2 - newsize->y1;
+new_width = newsize->x2;
+new_height = newsize->y2;
 
 if (new_width == screen_pixmap->drawable.width &&
 new_height == screen_pixmap->drawable.height) {
-- 
2.9.3

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

[PATCH xserver 2/2] randr: rrCheckPixmapBounding: do not shrink the screen_pixmap

2016-11-22 Thread Hans de Goede 
The purpose of rrCheckPixmapBounding is to make sure that the
screen_pixmap is *large* enough for the slave-output which crtc is
being configured.

However until now rrCheckPixmapBounding would also shrink the
screen_pixmap in certain scenarios leading to various problems.

For example: Take a laptop with its internalscreen on a slave-output and
currently disabled and an external monitor at 1920x1080+0+0.
Now lets say that we want to drive the external monitor at its native
resolution of 2560x1440 and have the internal screen mirror the top left
part of the external monitor, so we run:

  $ xrandr --output eDP --mode 1920x1080 --pos 0x0 --output HDMI \
  --mode 2560x1440 --pos 0x0

Here xrandr utility first calls RRSetScreenSize to 2560x1440, then it
calls RRSetCrtc 1920x1080+0+0 on the eDP, since this is a slave output,
rrCheckPixmapBounding gets called and resizes the screen_pixmap to
1920x1080, undoing the RRSetScreenSize. Then RRSetCrtc 2560x1440+0+0
gets called on the HDMI, depending on crtc->transforms this will
either result in a BadValue error from ProcRRSetCrtcConfig; or
it will succeed, but the monitor ends up running at 2560x1440
while showing a 1920x1080 screen_pixmap + black borders on the right
and bottom. Neither of which is what we want.

This commit removes the troublesome shrinking behavior, fixing this.

Note:

1) One could argue that this will leave us with a too large screen_pixmap
in some cases, but rrCheckPixmapBounding only gets called for slave
outputs, so xrandr clients already must manually shrink the screen_pixmap
after disabling crtcs in normal setups.

2) An alternative approach would be to also call rrCheckPixmapBounding
on RRSetCrtc on normal (non-slave) outputs, but that would result in
2 unnecessary resizes of the screen_pixmap in the above example, which
seems undesirable.

Cc: Nikhil Mahale 
Cc: Dave Airlie 
Signed-off-by: Hans de Goede 
---
 randr/rrcrtc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index ac853ea..d1a51f0 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -689,6 +689,12 @@ rrCheckPixmapBounding(ScreenPtr pScreen,
 new_width = newsize->x2;
 new_height = newsize->y2;
 
+if (new_width < screen_pixmap->drawable.width)
+new_width = screen_pixmap->drawable.width;
+
+if (new_height < screen_pixmap->drawable.height)
+new_height = screen_pixmap->drawable.height;
+
 if (new_width == screen_pixmap->drawable.width &&
 new_height == screen_pixmap->drawable.height) {
 } else {
-- 
2.9.3

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

[PATCH xserver] xwayland: Don't send KeyRelease events on wl_keyboard::leave

2016-11-22 Thread Rui Matos 
Commits 816015648ffe660ddaa0f7d4d192e555b723c372 and
fee0827a9a695600765f3d04376fc9babe497401 made it so that
wl_keyboard::enter doesn't result in X clients getting KeyPress events
while still updating our internal xkb state to be in sync with the
host compositor.

wl_keyboard::leave needs to be handled in the same way as its
semantics from an X client POV should be the same as an X grab getting
triggered, i.e. X clients shouldn't get KeyRelease events for keys
that are still down at that point.

This patch uses LeaveNotify for these events on wl_keyboard::leave and
changes the current use of KeymapNotify to EnterNotify instead just to
keep some symmetry between both cases.

ProcessDeviceEvent() is changed to still deactivate X grabs if needed
since EVENT_SOURCE_FOCUS can now happen for KeyReleases too.
---
 Xi/exevents.c| 26 +-
 dix/getevents.c  |  5 -
 hw/xwayland/xwayland-input.c |  8 ++--
 3 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/Xi/exevents.c b/Xi/exevents.c
index fc5298e..6360326 100644
--- a/Xi/exevents.c
+++ b/Xi/exevents.c
@@ -1763,10 +1763,6 @@ ProcessDeviceEvent(InternalEvent *ev, DeviceIntPtr 
device)
 
 switch (event->type) {
 case ET_KeyPress:
-/* Don't deliver focus events (e.g. from KeymapNotify when running
- * nested) to clients. */
-if (event->source_type == EVENT_SOURCE_FOCUS)
-return;
 if (!grab && CheckDeviceGrabs(device, event, 0))
 return;
 break;
@@ -1798,15 +1794,19 @@ ProcessDeviceEvent(InternalEvent *ev, DeviceIntPtr 
device)
 break;
 }
 
-if (grab)
-DeliverGrabbedEvent((InternalEvent *) event, device,
-deactivateDeviceGrab);
-else if (device->focus && !IsPointerEvent(ev))
-DeliverFocusedEvent(device, (InternalEvent *) event,
-GetSpriteWindow(device));
-else
-DeliverDeviceEvents(GetSpriteWindow(device), (InternalEvent *) event,
-NullGrab, NullWindow, device);
+/* Don't deliver focus events (e.g. from KeymapNotify when running
+ * nested) to clients. */
+if (event->source_type != EVENT_SOURCE_FOCUS) {
+if (grab)
+DeliverGrabbedEvent((InternalEvent *) event, device,
+deactivateDeviceGrab);
+else if (device->focus && !IsPointerEvent(ev))
+DeliverFocusedEvent(device, (InternalEvent *) event,
+GetSpriteWindow(device));
+else
+DeliverDeviceEvents(GetSpriteWindow(device), (InternalEvent *) 
event,
+NullGrab, NullWindow, device);
+}
 
 if (deactivateDeviceGrab == TRUE) {
 (*device->deviceGrab.DeactivateGrab) (device);
diff --git a/dix/getevents.c b/dix/getevents.c
index 4d06818..0d87453 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -1101,9 +1101,12 @@ GetKeyboardEvents(InternalEvent *events, DeviceIntPtr 
pDev, int type,
 }
 #endif
 
-if (type == KeymapNotify) {
+if (type == EnterNotify) {
 source_type = EVENT_SOURCE_FOCUS;
 type = KeyPress;
+} else if (type == LeaveNotify) {
+source_type = EVENT_SOURCE_FOCUS;
+type = KeyRelease;
 }
 
 /* refuse events from disabled devices */
diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index d6eadad..5671b50 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -655,7 +655,7 @@ keyboard_handle_enter(void *data, struct wl_keyboard 
*keyboard,
 
 wl_array_copy(_seat->keys, keys);
 wl_array_for_each(k, _seat->keys)
-QueueKeyboardEvents(xwl_seat->keyboard, KeymapNotify, *k + 8);
+QueueKeyboardEvents(xwl_seat->keyboard, EnterNotify, *k + 8);
 }
 
 static void
@@ -667,12 +667,8 @@ keyboard_handle_leave(void *data, struct wl_keyboard 
*keyboard,
 
 xwl_seat->xwl_screen->serial = serial;
 
-/* Unlike keymap_handle_enter above, this time we _do_ want to trigger
- * full release, as we don't know how long we'll be out of focus for.
- * Notify clients that the keys have been released, disable autorepeat,
- * etc. */
 wl_array_for_each(k, _seat->keys)
-QueueKeyboardEvents(xwl_seat->keyboard, KeyRelease, *k + 8);
+QueueKeyboardEvents(xwl_seat->keyboard, LeaveNotify, *k + 8);
 
 xwl_seat->keyboard_focus = NULL;
 }
-- 
2.9.3

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

Re: [PATCH wayland] doc: start documenting Xwayland

2016-11-22 Thread Pekka Paalanen 
On Tue, 22 Nov 2016 09:20:48 +
Daniel Stone  wrote:

> Hi,
> 

Hi Daniel,

nice comments, I'll revise the patch later. Some replies below.

> On 21 November 2016 at 15:06, Pekka Paalanen
>  wrote:
> > On Mon, 21 Nov 2016 14:31:43 +0200
> > Pekka Paalanen  wrote:  
> >> +
> >> +  X11 and Wayland are different enough that there is no "simple" way 
> >> to
> >> +  translate between them. Most of X11 is uninteresting to a Wayland
> >> +  compositor. That combined with the gigantic implementation effort 
> >> needed
> >> +  to support X11 makes it untractable to just write X11 support 
> >> directly in  
> 
> Nit: intractable.
> 
> >> +
> >> +  Therefore Wayland compositors should use Xwayland, the X11 server 
> >> that
> >> +  lives in the Xorg server source code repository and shares most of 
> >> the
> >> +  implementation with the Xorg server. Xwayland is a complete X11 
> >> server,
> >> +  just like Xorg is, but instead of talking to hardware and device 
> >> drivers,
> >> +  it acts as a Wayland client. The rest of this chapter talks about 
> >> how
> >> +  Xwayland works.
> >> +  
> 
> Hm, Xwayland still talks to hardware when running Glamor; it just
> doesn't drive KMS / display controllers directly.
> 
> >> +
> >> +  The X11 window manager (XWM) is an integral part of the Wayland
> >> +  compositor. XWM uses the usual X11 window management protocol to 
> >> manage
> >> +  all X11 windows in Xwayland. Most importantly, XWM acts as a bridge
> >> +  between Xwayland window state and the Wayland compositor's window 
> >> manager
> >> +  (WWM). This way WWM can manage all windows, both native Wayland and 
> >> X11
> >> +  (Xwayland) windows. This is very important for a coherent user
> >> +  experience.
> >> +  
> 
> Probably worth pointing out explicitly that XWM is, like other
> windows, a real genuine X11 client. And that this creates a dependency
> loop which requires careful handling: Xwayland is a Wayland client of
> the compositor, which is an X11 client of Xwayland.
> 
> >> +
> >> +  Xwayland uses Wayland core protocol and some extensions for input 
> >> and
> >> +  output. The used protocol is all generic and public, there are no
> >> +  Xwayland-specific or private Wayland extensions being used.  
> 
> This is true, strictly speaking, but maybe misleading by omission as
> the WL_SURFACE_ID X11 property is essentially private protocol between
> Xwayland and XWM / the compositor. Even without that, I'm not sure we
> want to paint ourselves into a corner by disallowing the use of
> private protocol in the future.
> 
> >> +  Xwayland is
> >> +  just a regular Wayland client, except it is specially handled by 
> >> the WWM.  
> 
> WWM?

Introduced in the previous paragraph: Wayland window manager; by that I
mean the proper window manager in a Wayland compositor, to
differentiate from the component that acts as a X11 WM, even if you
count XWM as a part of WWM.

Does any better terminology come to mind?

Or is the split between XWM and WWM just a Weston thing?

> >>