max_line_length = 80
[*.xml]
-indent_style = space
+indent_style = tab
indent_size = 2
tab_width = 8
<imagedata fileref="images/wayland.png" format="PNG" />
</imageobject>
<textobject>
- <phrase>
- Wayland logo
- </phrase>
+ <phrase>
+ Wayland logo
+ </phrase>
</textobject>
</inlinemediaobject>
</corpauthor>
<para>
Possible examples for session compositors include
<itemizedlist>
- <listitem>
- <para>
+ <listitem>
+ <para>
gnome-shell
</para>
</listitem>
<literallayout>
Yours,
- the Wayland open-source community
- November 2012
+ the Wayland open-source community
+ November 2012
</literallayout>
</preface>
<imagedata fileref="images/x-architecture.png" format="PNG" />
</imageobject>
<textobject>
- <phrase>
- X architecture diagram
- </phrase>
+ <phrase>
+ X architecture diagram
+ </phrase>
</textobject>
</mediaobject>
<para>
<imagedata fileref="images/wayland-architecture.png" format="PNG" />
</imageobject>
<textobject>
- <phrase>
- Wayland architecture diagram
- </phrase>
+ <phrase>
+ Wayland architecture diagram
+ </phrase>
</textobject>
</mediaobject>
<para>
<literallayout>
Best,
- Kristian Høgsberg
+ Kristian Høgsberg
</literallayout>
</preface>
<figure>
<title>Xwayland architecture diagram</title>
<mediaobjectco>
- <imageobjectco>
- <imageobject>
- <imagedata fileref="images/xwayland-architecture.png" format="PNG" />
- </imageobject>
- </imageobjectco>
+ <imageobjectco>
+ <imageobject>
+ <imagedata fileref="images/xwayland-architecture.png" format="PNG" />
+ </imageobject>
+ </imageobjectco>
</mediaobjectco>
</figure>
<para>
<section id="sect-X11-Application-Support-xwm-window-identification">
<title>Window identification</title>
<para>
- In Xwayland, an X11 window may have a corresponding wl_surface object
- in Wayland. The wl_surface object is used for input and output: it is
- referenced by input events and used to provide the X11 window content
- to the Wayland compositor. The X11 window and the wl_surface live in
- different protocol streams, and they need to be matched for XWM to do
- its job.
+ In Xwayland, an X11 window may have a corresponding wl_surface object
+ in Wayland. The wl_surface object is used for input and output: it is
+ referenced by input events and used to provide the X11 window content
+ to the Wayland compositor. The X11 window and the wl_surface live in
+ different protocol streams, and they need to be matched for XWM to do
+ its job.
</para>
<para>
- When Xwayland creates a wl_surface on Wayland, it will also send an X11
- ClientMessage of type atom "WL_SURFACE_ID" to the X11 window carrying
- the wl_surface Wayland object ID as the first 32-bit data element. This
- is how XWM can associate a wl_surface with an X11 window. Note that
- the request to create a wl_surface and the ID message may arrive in any
- order in the Wayland compositor.
+ When Xwayland creates a wl_surface on Wayland, it will also send an X11
+ ClientMessage of type atom "WL_SURFACE_ID" to the X11 window carrying
+ the wl_surface Wayland object ID as the first 32-bit data element. This
+ is how XWM can associate a wl_surface with an X11 window. Note that
+ the request to create a wl_surface and the ID message may arrive in any
+ order in the Wayland compositor.
</para>
</section>
</section>
<!-- Version 2 additions -->
<request name="conjoin" since="2">
<description summary="register another fd passer with this one">
- Tells this fd passer object about another one to send events
- to for more complicated fd leak tests.
+ Tells this fd passer object about another one to send events
+ to for more complicated fd leak tests.
</description>
<arg name="passer" type="object" interface="fd_passer"/>
</request>
will be reported by the format event.
</description>
<!-- Note to protocol writers: don't update this list manually, instead
- run the automated script that keeps it in sync with drm_fourcc.h. -->
+ run the automated script that keeps it in sync with drm_fourcc.h. -->
<entry name="argb8888" value="0" summary="32-bit ARGB format, [31:0] A:R:G:B 8:8:8:8 little endian"/>
<entry name="xrgb8888" value="1" summary="32-bit RGB format, [31:0] x:R:G:B 8:8:8:8 little endian"/>
<entry name="c8" value="0x20203843" summary="8-bit color index format, [7:0] C"/>
will be raised otherwise.
</description>
<arg name="dnd_actions" type="uint" summary="actions supported by the destination client"
- enum="wl_data_device_manager.dnd_action"/>
+ enum="wl_data_device_manager.dnd_action"/>
<arg name="preferred_action" type="uint" summary="action preferred by the destination client"
- enum="wl_data_device_manager.dnd_action"/>
+ enum="wl_data_device_manager.dnd_action"/>
</request>
<event name="source_actions" since="3">
side changes its offered actions through wl_data_source.set_actions.
</description>
<arg name="source_actions" type="uint" summary="actions offered by the data source"
- enum="wl_data_device_manager.dnd_action"/>
+ enum="wl_data_device_manager.dnd_action"/>
</event>
<event name="action" since="3">
must happen before the call to wl_data_offer.finish.
</description>
<arg name="dnd_action" type="uint" summary="action selected by the compositor"
- enum="wl_data_device_manager.dnd_action"/>
+ enum="wl_data_device_manager.dnd_action"/>
</event>
</interface>
for drag-and-drop will raise a protocol error.
</description>
<arg name="dnd_actions" type="uint" summary="actions supported by the data source"
- enum="wl_data_device_manager.dnd_action"/>
+ enum="wl_data_device_manager.dnd_action"/>
</request>
<event name="dnd_drop_performed" since="3">
they reflect the current action.
</description>
<arg name="dnd_action" type="uint" summary="action selected by the compositor"
- enum="wl_data_device_manager.dnd_action"/>
+ enum="wl_data_device_manager.dnd_action"/>
</event>
</interface>
<event name="hey"/>
<enum name="foo">
- <entry name="first" value="0" summary="this is the first"/>
- <entry name="second" value="1" summary="this is the second"/>
- <entry name="third" value="2" since="2" summary="this is the third"/>
+ <entry name="first" value="0" summary="this is the first"/>
+ <entry name="second" value="1" summary="this is the second"/>
+ <entry name="third" value="2" since="2" summary="this is the third"/>
</enum>
</interface>
</protocol>