Update the required wayland version to 1.3

Change-Id: Id1c9d14061d513f6c37a59ed8161732366ab3526
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>

src/3rdparty/wayland/protocols/wayland.xml

@@ -38,7 +38,7 @@
 	The sync request asks the server to emit the 'done' event
 	on the returned wl_callback object.  Since requests are
 	handled in-order and events are delivered in-order, this can
-	used as a barrier to ensure all previous requests and the
+	be used as a barrier to ensure all previous requests and the
 	resulting events have been handled.
 
 	The object returned by this request will be destroyed by the
@@ -173,7 +173,7 @@
     </event>
   </interface>
 
-  <interface name="wl_compositor" version="2">
+  <interface name="wl_compositor" version="3">
     <description summary="the compositor singleton">
       A compositor.  This object is a singleton global.  The
       compositor is in charge of combining the contents of multiple
@@ -274,10 +274,73 @@
 
     <enum name="format">
       <description summary="pixel formats">
-	This describes the memory layout of an individual pixel.
+       This describes the memory layout of an individual pixel.
+
+       All renderers should support argb8888 and xrgb8888 but any other
+       formats are optional and may not be supported by the particular
+       renderer in use.
       </description>
       <entry name="argb8888" value="0" summary="32-bit ARGB format"/>
       <entry name="xrgb8888" value="1" summary="32-bit RGB format"/>
+      <!-- The drm format codes match the #defines in drm_fourcc.h.
+           The formats actually supported by the compositor will be
+           reported by the format event. -->
+      <entry name="c8" value="0x20203843"/>
+      <entry name="rgb332" value="0x38424752"/>
+      <entry name="bgr233" value="0x38524742"/>
+      <entry name="xrgb4444" value="0x32315258"/>
+      <entry name="xbgr4444" value="0x32314258"/>
+      <entry name="rgbx4444" value="0x32315852"/>
+      <entry name="bgrx4444" value="0x32315842"/>
+      <entry name="argb4444" value="0x32315241"/>
+      <entry name="abgr4444" value="0x32314241"/>
+      <entry name="rgba4444" value="0x32314152"/>
+      <entry name="bgra4444" value="0x32314142"/>
+      <entry name="xrgb1555" value="0x35315258"/>
+      <entry name="xbgr1555" value="0x35314258"/>
+      <entry name="rgbx5551" value="0x35315852"/>
+      <entry name="bgrx5551" value="0x35315842"/>
+      <entry name="argb1555" value="0x35315241"/>
+      <entry name="abgr1555" value="0x35314241"/>
+      <entry name="rgba5551" value="0x35314152"/>
+      <entry name="bgra5551" value="0x35314142"/>
+      <entry name="rgb565" value="0x36314752"/>
+      <entry name="bgr565" value="0x36314742"/>
+      <entry name="rgb888" value="0x34324752"/>
+      <entry name="bgr888" value="0x34324742"/>
+      <entry name="xbgr8888" value="0x34324258"/>
+      <entry name="rgbx8888" value="0x34325852"/>
+      <entry name="bgrx8888" value="0x34325842"/>
+      <entry name="abgr8888" value="0x34324241"/>
+      <entry name="rgba8888" value="0x34324152"/>
+      <entry name="bgra8888" value="0x34324142"/>
+      <entry name="xrgb2101010" value="0x30335258"/>
+      <entry name="xbgr2101010" value="0x30334258"/>
+      <entry name="rgbx1010102" value="0x30335852"/>
+      <entry name="bgrx1010102" value="0x30335842"/>
+      <entry name="argb2101010" value="0x30335241"/>
+      <entry name="abgr2101010" value="0x30334241"/>
+      <entry name="rgba1010102" value="0x30334152"/>
+      <entry name="bgra1010102" value="0x30334142"/>
+      <entry name="yuyv" value="0x56595559"/>
+      <entry name="yvyu" value="0x55595659"/>
+      <entry name="uyvy" value="0x59565955"/>
+      <entry name="vyuy" value="0x59555956"/>
+      <entry name="ayuv" value="0x56555941"/>
+      <entry name="nv12" value="0x3231564e"/>
+      <entry name="nv21" value="0x3132564e"/>
+      <entry name="nv16" value="0x3631564e"/>
+      <entry name="nv61" value="0x3136564e"/>
+      <entry name="yuv410" value="0x39565559"/>
+      <entry name="yvu410" value="0x39555659"/>
+      <entry name="yuv411" value="0x31315559"/>
+      <entry name="yvu411" value="0x31315659"/>
+      <entry name="yuv420" value="0x32315559"/>
+      <entry name="yvu420" value="0x32315659"/>
+      <entry name="yuv422" value="0x36315559"/>
+      <entry name="yvu422" value="0x36315659"/>
+      <entry name="yuv444" value="0x34325559"/>
+      <entry name="yvu444" value="0x34325659"/>
     </enum>
 
     <request name="create_pool">
@@ -521,7 +584,7 @@
       <description summary="initiate drag-and-drop session">
 	This event is sent when an active drag-and-drop pointer enters
 	a surface owned by the client.  The position of the pointer at
-	enter time is provided by the x an y arguments, in surface
+	enter time is provided by the x and y arguments, in surface
 	local coordinates.
       </description>
 
@@ -544,7 +607,7 @@
       <description summary="drag-and-drop session motion">
 	This event is sent when the drag-and-drop pointer moves within
 	the currently focused surface. The new position of the pointer
-	is provided by the x an y arguments, in surface local
+	is provided by the x and y arguments, in surface local
 	coordinates.
       </description>
       <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
@@ -577,7 +640,7 @@
 
   <interface name="wl_data_device_manager" version="1">
     <description summary="data transfer interface">
-      The wl_data_device_manager is a a singleton global object that
+      The wl_data_device_manager is a singleton global object that
       provides access to inter-client data transfer mechanisms such as
       copy-and-paste and drag-and-drop.  These mechanisms are tied to
       a wl_seat and this interface lets a client get a wl_data_device
@@ -709,7 +772,7 @@
 
 	The x and y arguments specify the locations of the upper left
 	corner of the surface relative to the upper left corner of the
-	parent surface.
+	parent surface, in surface local coordinates.
 
 	The flags argument controls details of the transient behaviour.
       </description>
@@ -729,7 +792,7 @@
       <entry name="default" value="0" summary="no preference, apply default policy"/>
       <entry name="scale" value="1" summary="scale, preserve the surface's aspect ratio and center on output"/>
       <entry name="driver" value="2" summary="switch output mode to the smallest mode that can fit the surface, add black borders to compensate size mismatch"/>
-      <entry name="fill" value="3" summary="no scaling, center on output and add black borders to compensate size mismatch"/>
+      <entry name="fill" value="3" summary="no upscaling, center on output and add black borders to compensate size mismatch"/>
     </enum>
 
     <request name="set_fullscreen">
@@ -751,6 +814,19 @@
 	indicates that the app does not care about framerate.  The
 	framerate is specified in mHz, that is framerate of 60000 is 60Hz.
 
+	A method of "scale" or "driver" implies a scaling operation of
+	the surface, either via a direct scaling operation or a change of
+	the output mode. This will override any kind of output scaling, so
+	that mapping a surface with a buffer size equal to the mode can
+	fill the screen independent of buffer_scale.
+
+	A method of "fill" means we don't scale up the buffer, however
+	any output scale is applied. This means that you may run into
+	an edge case where the application maps a buffer with the same
+	size of the output mode but buffer_scale 1 (thus making a
+	surface larger than the output). In this case it is allowed to
+	downscale the results to fit the screen.
+
 	The compositor must reply to this request with a configure event
 	with the dimensions for the output on which the surface will
 	be made fullscreen.
@@ -777,6 +853,10 @@
 	in any of the clients surfaces is reported as normal, however,
 	clicks in other clients surfaces will be discarded and trigger
 	the callback.
+
+	The x and y arguments specify the locations of the upper left
+	corner of the surface relative to the upper left corner of the
+	parent surface, in surface local coordinates.
       </description>
 
       <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat whose pointer is used"/>
@@ -829,9 +909,9 @@
 	Set a class for the surface.
 
 	The surface class identifies the general class of applications
-	to which the surface belongs. A common convention is to use
+	to which the surface belongs. A common convention is to use the
-	the file name (full path if non-standard location) of the
+	file name (or the full path if it is a non-standard location) of
-	applications .desktop file as the class.
+	the application's .desktop file as the class.
       </description>
       <arg name="class_" type="string"/>
     </request>
@@ -860,6 +940,9 @@
 
 	The client is free to dismiss all but the last configure
 	event it received.
+
+	The width and height arguments specify the size of the window
+	in surface local coordinates.
       </description>
 
       <arg name="edges" type="uint"/>
@@ -870,17 +953,22 @@
     <event name="popup_done">
       <description summary="popup interaction is done">
 	The popup_done event is sent out when a popup grab is broken,
-	that is, when the users clicks a surface that doesn't belong
+	that is, when the user clicks a surface that doesn't belong
 	to the client owning the popup surface.
       </description>
     </event>
   </interface>
 
-  <interface name="wl_surface" version="2">
+  <interface name="wl_surface" version="3">
     <description summary="an onscreen surface">
       A surface is a rectangular area that is displayed on the screen.
       It has a location, size and pixel contents.
 
+      The size of a surface (and relative positions on it) is described
+      in surface local coordinates, which may differ from the buffer
+      local coordinates of the pixel content, in case a buffer_transform
+      or a buffer_scale is used.
+
       Surfaces are also used for some special purposes, e.g. as
       cursor images for pointers, drag icons, etc.
     </description>
@@ -895,20 +983,25 @@
       <description summary="set the surface contents">
 	Set a buffer as the content of this surface.
 
+	The new size of the surface is calculated based on the buffer
+	size transformed by the inverse buffer_transform and the
+	inverse buffer_scale. This means that the supplied buffer
+	must be an integer multiple of the buffer_scale.
+
 	The x and y arguments specify the location of the new pending
-	buffer's upper left corner, relative to the current buffer's
+	buffer's upper left corner, relative to the current buffer's upper
-	upper left corner. In other words, the x and y, and the width
+	left corner, in surface local coordinates. In other words, the
-	and height of the wl_buffer together define in which directions
+	x and y, combined with the new surface size define in which
-	the surface's size changes.
+	directions the surface's size changes.
 
 	Surface contents are double-buffered state, see wl_surface.commit.
 
 	The initial surface contents are void; there is no content.
 	wl_surface.attach assigns the given wl_buffer as the pending
 	wl_buffer. wl_surface.commit makes the pending wl_buffer the new
-	surface contents, and the size of the surface becomes the size of
+	surface contents, and the size of the surface becomes the size
-	the wl_buffer, as described above. After commit, there is no
+	calculated from the wl_buffer, as described above. After commit,
-	pending buffer until the next attach.
+	there is no pending buffer until the next attach.
 
 	Committing a pending wl_buffer allows the compositor to read the
 	pixels in the wl_buffer. The compositor may access the pixels at
@@ -922,10 +1015,10 @@
 
 	Destroying the wl_buffer after wl_buffer.release does not change
 	the surface contents. However, if the client destroys the
-	wl_buffer before receiving wl_buffer.release, the surface
+	wl_buffer before receiving the wl_buffer.release event, the surface
 	contents become undefined immediately.
 
-	Only if wl_surface.attach is sent with a NULL wl_buffer, the
+	If wl_surface.attach is sent with a NULL wl_buffer, the
 	following wl_surface.commit will remove the surface content.
       </description>
 
@@ -945,6 +1038,8 @@
 
 	Damage is double-buffered state, see wl_surface.commit.
 
+	The damage rectangle is specified in surface local coordinates.
+
 	The initial value for pending damage is empty: no damage.
 	wl_surface.damage adds pending damage: the new pending damage
 	is the union of old pending damage and the given rectangle.
@@ -996,6 +1091,8 @@
 	behaviour, but marking transparent content as opaque will result
 	in repaint artifacts.
 
+	The opaque region is specified in surface local coordinates.
+
 	The compositor ignores the parts of the opaque region that fall
 	outside of the surface.
 
@@ -1023,6 +1120,8 @@
 	surface in the server surface stack. The compositor ignores the
 	parts of the input region that fall outside of the surface.
 
+	The input region is specified in surface local coordinates.
+
 	Input region is double-buffered state, see wl_surface.commit.
 
 	wl_surface.set_input_region changes the pending input region.
@@ -1100,7 +1199,7 @@
 	according to the output transform, thus permiting the compositor to
 	use certain optimizations even if the display is rotated. Using
 	hardware overlays and scanning out a client buffer for fullscreen
-	surfaces are examples of such optmizations. Those optimizations are
+	surfaces are examples of such optimizations. Those optimizations are
 	highly dependent on the compositor implementation, so the use of this
 	request should be considered on a case-by-case basis.
 
@@ -1110,9 +1209,33 @@
       </description>
       <arg name="transform" type="int"/>
     </request>
+
+    <!-- Version 3 additions -->
+
+    <request name="set_buffer_scale" since="3">
+      <description summary="sets the buffer scaling factor">
+	This request sets an optional scaling factor on how the compositor
+	interprets the contents of the buffer attached to the window.
+
+	Buffer scale is double-buffered state, see wl_surface.commit.
+
+	A newly created surface has its buffer scale set to 1.
+
+	The purpose of this request is to allow clients to supply higher
+	resolution buffer data for use on high resolution outputs. Its
+	intended that you pick the same	buffer scale as the scale of the
+	output that the surface is displayed on.This means the compositor
+	can avoid scaling when rendering the surface on that output.
+
+	Note that if the scale is larger than 1, then you have to attach
+	a buffer that is larger (by a factor of scale in each dimension)
+	than the desired surface size.
+      </description>
+      <arg name="scale" type="int"/>
+    </request>
    </interface>
 
-  <interface name="wl_seat" version="1">
+  <interface name="wl_seat" version="3">
     <description summary="group of input devices">
       A seat is a group of keyboards, pointer and touch devices. This
       object is published as a global during start up, or when such a
@@ -1171,9 +1294,21 @@
       </description>
       <arg name="id" type="new_id" interface="wl_touch"/>
     </request>
+
+    <!-- Version 2 of additions -->
+
+    <event name="name" since="2">
+      <description summary="unique identifier for this seat">
+	In a multiseat configuration this can be used by the client to help
+	identify which physical devices the seat represents. Based on
+	the seat configuration used by the compositor.
+      </description>
+      <arg name="name" type="string"/>
+    </event>
+
   </interface>
 
-  <interface name="wl_pointer" version="1">
+  <interface name="wl_pointer" version="3">
     <description summary="pointer input device">
       The wl_pointer interface represents one or more input devices,
       such as mice, which control the pointer location and pointer_focus
@@ -1197,7 +1332,8 @@
 	The parameters hotspot_x and hotspot_y define the position of
 	the pointer surface relative to the pointer location. Its
 	top-left corner is always at (x, y) - (hotspot_x, hotspot_y),
-	where (x, y) are the coordinates of the pointer location.
+	where (x, y) are the coordinates of the pointer location, in surface
+	local coordinates.
 
 	On surface.attach requests to the pointer surface, hotspot_x
 	and hotspot_y are decremented by the x and y parameters
@@ -1221,6 +1357,10 @@
       <arg name="hotspot_y" type="int" summary="y coordinate in surface-relative coordinates"/>
     </request>
 
+    <request name="release" type="destructor" since="3">
+      <description summary="release the pointer object"/>
+    </request>
+
     <event name="enter">
       <description summary="enter event">
 	Notification that this seat's pointer is focused on a certain
@@ -1320,17 +1460,23 @@
     </event>
   </interface>
 
-  <interface name="wl_keyboard" version="1">
+  <interface name="wl_keyboard" version="3">
     <description summary="keyboard input device">
       The wl_keyboard interface represents one or more keyboards
       associated with a seat.
     </description>
 
+    <request name="release" type="destructor" since="3">
+      <description summary="release the keyboard object"/>
+    </request>
+
     <enum name="keymap_format">
       <description summary="keyboard mapping format">
 	This specifies the format of the keymap provided to the
 	client with the wl_keyboard.keymap event.
       </description>
+      <entry name="no_keymap" value="0"
+	     summary="no keymap; client must understand how to interpret the raw keycode"/>
       <entry name="xkb_v1" value="1" summary="libxkbcommon compatible"/>
     </enum>
 
@@ -1401,7 +1547,7 @@
     </event>
   </interface>
 
-  <interface name="wl_touch" version="1">
+  <interface name="wl_touch" version="3">
     <description summary="touchscreen input device">
       The wl_touch interface represents a touchscreen
       associated with a seat.
@@ -1413,6 +1559,10 @@
       contact point can be identified by the ID of the sequence.
     </description>
 
+    <request name="release" type="destructor" since="3">
+      <description summary="release the touch object"/>
+    </request>
+
     <event name="down">
       <description summary="touch down event and beginning of a touch sequence">
 	A new touch point has appeared on the surface. This touch point is
@@ -1467,7 +1617,7 @@
     </event>
   </interface>
 
-  <interface name="wl_output" version="1">
+  <interface name="wl_output" version="2">
     <description summary="compositor output region">
       An output describes part of the compositor geometry.  The
       compositor works in the 'compositor coordinate system' and an
@@ -1559,12 +1709,52 @@
 	again if an output changes mode, for the mode that is now
 	current.  In other words, the current mode is always the last
 	mode that was received with the current flag set.
+
+	The size of a mode is given in physical hardware units of
+        the output device. This is not necessarily the same as
+        the output size in the global compositor space. For instance,
+        the output may be scaled, as described in wl_output.scale,
+        or transformed , as described in wl_output.transform.
       </description>
       <arg name="flags" type="uint" summary="bitfield of mode flags"/>
-      <arg name="width" type="int" summary="width of the mode in pixels"/>
+      <arg name="width" type="int" summary="width of the mode in hardware units"/>
-      <arg name="height" type="int" summary="height of the mode in pixels"/>
+      <arg name="height" type="int" summary="height of the mode in hardware units"/>
       <arg name="refresh" type="int" summary="vertical refresh rate in mHz"/>
     </event>
+
+    <event name="done" since="2">
+      <description summary="sent all information about output">
+        This event is sent after all other properties has been
+        sent after binding to the output object and after any
+        other property changes done after that. This allows
+        changes to the output properties to be seen as
+        atomic, even if they happen via multiple events.
+      </description>
+    </event>
+
+    <event name="scale" since="2">
+      <description summary="output scaling properties">
+	This event contains scaling geometry information
+        that is not in the geometry event. It may be sent after
+        binding the output object or if the output scale changes
+        later. If it is not sent, the client should assume a
+	scale of 1.
+
+	A scale larger than 1 means that the compositor will
+	automatically scale surface buffers by this amount
+	when rendering. This is used for very high resolution
+	displays where applications rendering at the native
+	resolution would be too small to be legible.
+
+	It is intended that scaling aware clients track the
+	current output of a surface, and if it is on a scaled
+	output it should use wl_surface.set_buffer_scale with
+	the scale of the output. That way the compositor can
+	avoid scaling the surface, and the client can supply
+	a higher detail image.
+      </description>
+      <arg name="factor" type="int" summary="scaling factor of output"/>
+    </event>
   </interface>
 
   <interface name="wl_region" version="1">