third_party: Update remote shell protocol to version 2

third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml

Index: third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml
diff --git a/third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml b/third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml
index 083bd9b1d8b6e2e60f8a0b3cd903a1283b792caa..cd4cd263444bbc17cf9106bf813b9faa5e773057 100644
--- a/third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml
+++ b/third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml
@@ -38,7 +38,7 @@
     reset.
   </description>
 
-  <interface name="zwp_remote_shell_v1" version="11">
+  <interface name="zwp_remote_shell_v1" version="12">
     <description summary="remote_shell">
       The global interface that allows clients to turn a wl_surface into a
       "real window" which is remotely managed but can be stacked, activated
@@ -168,7 +168,7 @@
     </event>
   </interface>
 
-  <interface name="zwp_remote_surface_v1" version="11">
+  <interface name="zwp_remote_surface_v1" version="12">
     <description summary="A desktop window">
       An interface that may be implemented by a wl_surface, for
       implementations that provide a desktop-style user interface
@@ -521,6 +521,25 @@
       <arg name="trusted" type="int" summary="whether the app can enforce users
           to stay in the pinned mode."/>
     </request>
+
+    <!-- Version 12 additions -->
+
+    <request name="drag" since="12">

[reveman, 2016/09/02 14:59:25]

Please use similar language as the xdg spec. ie. "interactive, user-driven move
of the surface. " instead of "drag".

And to make the request names match other requests that toggle compositor side
state I think set_moving/unset_moving would be good. wdyt?

[Dominik Laskowski, 2016/09/15 20:07:26]

Done.

+      <description summary="start client-driven drag">
+	Notifies the compositor when a client-driven drag of the surface starts.
+	The compositor may assume that subsequent set_window_geometry requests
+	are position updates until it receives a "drop" request.
+      </description>
+    </request>
+
+    <request name="drop" since="12">
+      <description summary="stop client-driven drag">
+	Notifies the compositor when a client-driven drag of the surface stops,
+	and whether it was reverted. The compositor may choose to stop the drag
+	regardless of this request.
+      </description>
+      <arg name="revert" type="uint"/>

[reveman, 2016/09/02 14:59:25]

what is this argument supposed to be used for by the compositor?

[Dominik Laskowski, 2016/09/15 20:07:26]

If the drag is reverted after entering another display, there is no need for the
compositor to move the window to that display, because the next
set_window_geometry request will move it back.

However, all cases that require a revert are detected by the server before the
client, so this argument is unnecessary. The only such cases are display
configuration changes, e.g. unplugging a display while dragging. Previously, a
client-side ACTION_CANCEL input event would also revert the drag, but it only
seems to happen on window deactivation and Ash just drops the window in that
case [1]. The next patch in ag/1396283 will address this.

[1]
https://chromium.googlesource.com/chromium/src/+/master/ash/common/wm/wm_topl...

+    </request>

[oshima, 2016/09/02 14:37:21]

Chrome side may also have to abort drag (activation change changed during,
system modal might shown etc), so I think you need to add an event for that
case.

[Dominik Laskowski, 2016/09/15 20:07:26]

The client can detect all cases that require aborting the drag, i.e. window
deactivation and display configuration changes. The only other case is window
destruction, which is handled by the server.

   </interface>
 
   <!-- Version 6 additions -->