xwayland: Track new protocol for xwm client side selectionxwm-client

Selection callback was put back on action, but no real functional changes on X
side.

Tested-by: Scott Moreau <oreaus@gmail.com>
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>

2 files changed, 50 insertions, 3 deletions

diff --git a/hw/xfree86/xwayland/xserver.xml b/hw/xfree86/xwayland/xserver.xml
index a5dbebd2c..457daee3a 100644
--- a/hw/xfree86/xwayland/xserver.xml
+++ b/hw/xfree86/xwayland/xserver.xml
@@ -75,6 +75,16 @@
       <arg name="xid" type="uint"/>
     </request>
 
+    <request name="set_selection">
+      <description summary="send the selection data">
+	Request for data from another client.  Send the data as the specified
+	mime-type over the passed fd.
+      </description>
+
+      <arg name="mime_type" type="string"/>
+      <arg name="fd" type="fd"/>
+    </request>
+
     <event name="xserver">
       <description summary="send X fd to window manager">
 	This is the other tip of the socketpair used for connecting X and
@@ -98,6 +108,14 @@
 
       <arg name="state" type="uint"/>
     </event>
+
+    <event name="selection">
+      <description summary="notifies wm whether a text plain was selected">
+	The selection itself will happen via X then.
+      </description>
+
+      <arg name="has_text_plain" type="uint"/>
+    </event>
   </interface>
 
   <interface name="wm_xwin" version="1">
@@ -129,7 +147,37 @@
       <arg name="height" type="int"/>
       <arg name="flags" type="uint"/>
     </request>
- 
+
+    <request name="set_opaque_override">
+      <description summary="set opaque override region">
+	Textures coming from X windows usually have their X window as RGBx,
+	i.e. 32 bit with an undefined alpha channel for the content part while
+	the decorations are rendered with a well-defined alpha channel. On
+	this case set_opaque_override is needed for marking a rectangle in a
+	texture and force the alpha = 1.0.
+
+	This is different from the wl_surface.set_opaque_region, where that
+	one is meant only as a hint for optimization while this is a necessity
+	for painting XWayland windows right. Therefore X must never use
+	wl_surface.set_opaque_region either.
+
+	There is no way for the compositor tell beforehand whether a window
+	received already its surface from X (xserver.set_window_surface). The
+	client also does not know about it, so the region created on client
+	side is destroyed implicitly inside the compositor after used. Thus
+	the client must not call wl_region_destroy for this request.
+      </description>
+
+      <arg name="region" type="object" interface="wl_region"/>
+    </request>
+
+    <request name="set_input_region">
+      <description summary="set window input region">
+      </description>
+
+      <arg name="region" type="object" interface="wl_region" allow-null="true"/>
+    </request>
+
     <request name="move">
     </request>
 
diff --git a/hw/xfree86/xwayland/xwayland.c b/hw/xfree86/xwayland/xwayland.c
index a22ee58c8..54b92e8f9 100644
--- a/hw/xfree86/xwayland/xwayland.c
+++ b/hw/xfree86/xwayland/xwayland.c
@@ -318,12 +318,11 @@ xwl_screen_pre_init(ScrnInfoPtr scrninfo, struct xwl_screen *xwl_screen,
     noScreenSaverExtension = TRUE;
 
     xdnd_atom = MakeAtom("XdndSelection", 13, 1);
-#if 0
     if (!AddCallback(&SelectionCallback,
 		     xwayland_selection_callback, xwl_screen)) {
 	return FALSE;
     }
-#endif
+
     xorg_list_init(&xwl_screen->seat_list);
     xorg_list_init(&xwl_screen->damage_window_list);
     xorg_list_init(&xwl_screen->window_list);