view release on metacpan or  search on metacpan

protocol/wayland.xml  view on Meta::CPAN

	etc.) is double-buffered. Protocol requests modify the pending
	state, as opposed to current state in use by the compositor. Commit
	request atomically applies all pending state, replacing the current
	state. After commit, the new pending state is as documented for each
	related request.

	On commit, a pending wl_buffer is applied first, all other state
	second. This means that all coordinates in double-buffered state are
	relative to the new wl_buffer coming into use, except for
	wl_surface.attach itself. If there is no pending wl_buffer, the
	coordinates are relative to the current surface contents.

	All requests that need a commit to become effective are documented
	to affect double-buffered state.

	Other interfaces may add further double-buffered surface state.
      </description>
    </request>

    <event name="enter">
      <description summary="surface enters an output">
	This is emitted whenever a surface's creation, movement, or resizing
	results in some part of it being within the scanout region of an
	output.

	Note that a surface may be overlapping with zero or more outputs.
      </description>
      <arg name="output" type="object" interface="wl_output"/>
    </event>

    <event name="leave">
      <description summary="surface leaves an output">
	This is emitted whenever a surface's creation, movement, or resizing
	results in it no longer having any part of it within the scanout region
	of an output.
      </description>
      <arg name="output" type="object" interface="wl_output"/>
    </event>

    <!-- Version 2 additions -->

    <request name="set_buffer_transform" since="2">
      <description summary="sets the buffer transformation">
	This request sets an optional transformation on how the compositor
	interprets the contents of the buffer attached to the surface. The
	accepted values for the transform parameter are the values for
	wl_output.transform.

	Buffer transform is double-buffered state, see wl_surface.commit.

	A newly created surface has its buffer transformation set to normal.

	wl_surface.set_buffer_transform changes the pending buffer
	transformation. wl_surface.commit copies the pending buffer
	transformation to the current one. Otherwise, the pending and current
	values are never changed.

	The purpose of this request is to allow clients to render content
	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 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.

	Note that if the transform value includes 90 or 270 degree rotation,
	the width of the buffer will become the surface height and the height
	of the buffer will become the surface width.
      </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.

	wl_surface.set_buffer_scale changes the pending buffer scale.
	wl_surface.commit copies the pending buffer scale to the current one.
	Otherwise, the pending and current values are never changed.

	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="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
      device is hot plugged.  A seat typically has a pointer and
      maintains a keyboard focus and a pointer focus.
    </description>

    <enum name="capability">
      <description summary="seat capability bitmask">
        This is a bitmask of capabilities this seat has; if a member is
        set, then it is present on the seat.
      </description>
      <entry name="pointer" value="1" summary="The seat has pointer devices"/>
      <entry name="keyboard" value="2" summary="The seat has one or more keyboards"/>
      <entry name="touch" value="4" summary="The seat has touch devices"/>
    </enum>

    <event name="capabilities">
      <description summary="seat capabilities changed">

protocol/wayland.xml  view on Meta::CPAN

  </interface>

  <interface name="wl_region" version="1">
    <description summary="region interface">
      A region object describes an area.

      Region objects are used to describe the opaque and input
      regions of a surface.
    </description>

    <request name="destroy" type="destructor">
      <description summary="destroy region">
	Destroy the region.  This will invalidate the object ID.
      </description>
    </request>

    <request name="add">
      <description summary="add rectangle to region">
	Add the specified rectangle to the region.
      </description>

      <arg name="x" type="int"/>
      <arg name="y" type="int"/>
      <arg name="width" type="int"/>
      <arg name="height" type="int"/>
    </request>

    <request name="subtract">
      <description summary="subtract rectangle from region">
	Subtract the specified rectangle from the region.
      </description>

      <arg name="x" type="int"/>
      <arg name="y" type="int"/>
      <arg name="width" type="int"/>
      <arg name="height" type="int"/>
    </request>

  </interface>

  <interface name="wl_subcompositor" version="1">
    <description summary="sub-surface compositing">
      The global interface exposing sub-surface compositing capabilities.
      A wl_surface, that has sub-surfaces associated, is called the
      parent surface. Sub-surfaces can be arbitrarily nested and create
      a tree of sub-surfaces.

      The root surface in a tree of sub-surfaces is the main
      surface. The main surface cannot be a sub-surface, because
      sub-surfaces must always have a parent.

      A main surface with its sub-surfaces forms a (compound) window.
      For window management purposes, this set of wl_surface objects is
      to be considered as a single window, and it should also behave as
      such.

      The aim of sub-surfaces is to offload some of the compositing work
      within a window from clients to the compositor. A prime example is
      a video player with decorations and video in separate wl_surface
      objects. This should allow the compositor to pass YUV video buffer
      processing to dedicated overlay hardware when possible.
    </description>

    <request name="destroy" type="destructor">
      <description summary="unbind from the subcompositor interface">
	Informs the server that the client will not be using this
	protocol object anymore. This does not affect any other
	objects, wl_subsurface objects included.
      </description>
    </request>

    <enum name="error">
      <entry name="bad_surface" value="0"
             summary="the to-be sub-surface is invalid"/>
    </enum>

    <request name="get_subsurface">
      <description summary="give a surface the role sub-surface">
	Create a sub-surface interface for the given surface, and
	associate it with the given parent surface. This turns a
	plain wl_surface into a sub-surface.

	The to-be sub-surface must not already have a dedicated
	purpose, like any shell surface type, cursor image, drag icon,
	or sub-surface. Otherwise a protocol error is raised.
      </description>

      <arg name="id" type="new_id" interface="wl_subsurface"
           summary="the new subsurface object id"/>
      <arg name="surface" type="object" interface="wl_surface"
           summary="the surface to be turned into a sub-surface"/>
      <arg name="parent" type="object" interface="wl_surface"
           summary="the parent surface"/>
    </request>
  </interface>

  <interface name="wl_subsurface" version="1">
    <description summary="sub-surface interface to a wl_surface">
      An additional interface to a wl_surface object, which has been
      made a sub-surface. A sub-surface has one parent surface. A
      sub-surface's size and position are not limited to that of the parent.
      Particularly, a sub-surface is not automatically clipped to its
      parent's area.

      A sub-surface becomes mapped, when a non-NULL wl_buffer is applied
      and the parent surface is mapped. The order of which one happens
      first is irrelevant. A sub-surface is hidden if the parent becomes
      hidden, or if a NULL wl_buffer is applied. These rules apply
      recursively through the tree of surfaces.

      The behaviour of wl_surface.commit request on a sub-surface
      depends on the sub-surface's mode. The possible modes are
      synchronized and desynchronized, see methods
      wl_subsurface.set_sync and wl_subsurface.set_desync. Synchronized
      mode caches the wl_surface state to be applied when the parent's
      state gets applied, and desynchronized mode applies the pending
      wl_surface state directly. A sub-surface is initially in the
      synchronized mode.

      Sub-surfaces have also other kind of state, which is managed by
      wl_subsurface requests, as opposed to wl_surface requests. This