[protocol PATCH v5 1/2] add parameters to set_fullscreen

[juan.j.zhao at linux.intel.com]

From: Juan Zhao <juan.j.zhao at linux.intel.com>

Map the surface as a fullscreen surface. Four types are supported.
"default" means the client has no preference on fullscreen
          behavior, policies are determined by compositor.
          The compositor will send a configure event to the
          client.
"scale"   means the client prefers scaling by the compositor.
          Scaling would always preserve surface's aspect ratio.
          And the surface is centered.
"driver"  means the client wants to switch video mode to the
          smallest mode that can fit the client buffer. If the
          sizes do not match, black borders are added.
"fill"    means the client wants to add blackborders to the
          surface. This would be preferring 1:1 pixel mapping
          in the monitor native video mode. The surface is
          centered.

Signed-off-by: Juan Zhao <juan.j.zhao at linux.intel.com>
Signed-off-by: Zhiwen Wu <zhiwen.wu at linux.intel.com>
---
 protocol/wayland.xml |   40 +++++++++++++++++++++++++++++++---------
 1 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index cdbbfd0..e48afa9 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -336,15 +336,37 @@
       <arg name="flags" type="uint"/>
     </request>
 
-    <!-- Map the surface as a fullscreen surface.  There are a number
-         of options here: on which output? if the surface size doesn't
-         match the output size, do we scale, change resolution, or add
-         black borders? is that something the client controls?  what
-         about transient surfaces, do they float on top of the
-         fullscreen? what if there's already a fullscreen surface on
-         the output, maybe you can only go fullscreen if you're
-         active?  -->
-    <request name="set_fullscreen"/>
+    <!-- Map the surface as a fullscreen surface. On the output the
+         surface is assigned to. The client can use different fulllscreen
+         method to fix the size mismatch issue: default, scale, driver
+         and fill. And the framerate parameter is used for "driver" method,
+         to indicate the preferred framerate. framerate=0 means that the
+         app does not care about framerate -->
+    <request name="set_fullscreen">
+      <arg name="method" type="uint"/>
+      <arg name="framerate" type="uint"/>
+    </request>
+
+    <!-- Hints to indicate compositor how to deal with this fullscreen
+         surface.
+         "default" means the client has no preference on fullscreen
+                   behavior, policies are determined by compositor.
+         "scale"   means the client prefers scaling by the compositor.
+                   Scaling would always preserve surface's aspect ratio.
+                   And the surface is centered.
+         "driver"  means the client wants to switch video mode to the
+                   smallest mode that can fit the client buffer. If the
+                   sizes do not match, black borders are added.
+         "fill"    means the client wants to add blackborders to the
+                   surface. This would be preferring 1:1 pixel mapping
+                   in the monitor native video mode. The surface is
+                   centered.-->
+    <enum name="fullscreen_method">
+      <entry name="default" value="0"/>
+      <entry name="scale" value="1"/>
+      <entry name="driver" value="2"/>
+      <entry name="fill" value="3"/>
+    </enum>
 
     <!-- Popup surfaces.  Will switch an implicit grab into
          owner-events mode, and grab will continue after the implicit
-- 
1.7.2.2