third_party: Update remote shell protocol to version 2

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

 <?xml version="1.0" encoding="UTF-8"?>
 <protocol name="remote_shell_unstable_v1">
 
   <copyright>
     Copyright 2016 The Chromium Authors.
 
     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,
@@ skipping 20 matching lines @@
     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.
   </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
       and made fullscreen by the user.
     </description>
 
     <enum name="container">
       <description summary="containers for remote surfaces">
         Determine how a remote surface should be stacked relative to other
         shell surfaces.
@@ skipping 109 matching lines @@
       <arg name="transform" type="int"/>
       <arg name="scale_factor" type="fixed"/>
       <arg name="work_area_inset_left" type="int"/>
       <arg name="work_area_inset_top" type="int"/>
       <arg name="work_area_inset_right" type="int"/>
       <arg name="work_area_inset_bottom" type="int"/>
       <arg name="layout_mode" type="uint"/>
     </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
       and allows for remotely managed windows.
 
       It provides requests to treat surfaces like windows, allowing to set
       properties like app id and geometry.
 
       The client must call wl_surface.commit on the corresponding wl_surface
       for the remote_surface state to take effect.
@@ skipping 332 matching lines @@
 
         This is only a request that the window should be pinned.
         The compositor may choose to ignore this request. The client should
         listen to set_pinned events to determine if the window was
         pinned or not. If trusted flag is non-zero, the app can prevent users
         from exiting the pinned mode.
       </description>
       <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 -->
 
   <interface name="zwp_notification_surface_v1" version="6">
     <description summary="A notification window">
       An interface that may be implemented by a wl_surface to host
       notification contents.
     </description>
 
     <request name="destroy" type="destructor">
       <description summary="Destroy the notification_surface">
         Unmap and destroy the notification surface.
       </description>
     </request>
   </interface>
 
 </protocol>