wayland: Changes to 'upstream-experimental'
protocol/wayland.xml | 480 +++++++++++++++++++++++++++---------------
spec/main.tex | 147 ++++++++++--
spec/wayland-architecture.png |binary
spec/x-architecture.png |binary
src/Makefile.am | 5
src/data-device.c | 464 ++++++++++++++++++++++++++++++++++++++++
src/event-loop.c | 6
src/scanner.c | 145 ++++++++++++
src/wayland-hash.c | 306 --------------------------
src/wayland-private.h | 2
src/wayland-server.c | 150 ++++++++-----
src/wayland-server.h | 65 ++++-
src/wayland-shm.c | 11
src/wayland-util.h | 11
14 files changed, 1207 insertions(+), 585 deletions(-)
New commits:
commit 10eefa49470d97948719f58dfb62a97fb4701aed
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Wed Jan 18 10:06:02 2012 -0800
spec: list core interfaces with short descriptions
Plus fix up misc. grammar.
diff --git a/spec/main.tex b/spec/main.tex
index 741c4e0..756bf38 100644
--- a/spec/main.tex
+++ b/spec/main.tex
@@ -162,7 +162,7 @@ The message header has 2 words in it:
\end{itemize}
The payload describes the request/event arguments. Every argument is always
-aligned to 32-bit. There is no prefix that describes the type, but it is
+aligned to 32-bits. There is no prefix that describes the type, but it is
inferred implicitly from the xml specification.
The representation of argument types are as follows:
@@ -174,7 +174,7 @@ The representation of argument types are as follows:
32-bit boundary.
\item "object": A 32-bit object ID.
\item "new\_id": the 32-bit object ID. On requests, the client
- decides the ID. The only event with "new\_id" is advertisements of
+ decides the ID. The only events with "new\_id" are advertisements of
globals, and the server will use IDs below 0x10000.
\item "array": Starts with 32-bit array size in bytes, followed by the array
contents verbatim, and finally padding to a 32-bit boundary.
@@ -182,6 +182,33 @@ The representation of argument types are as follows:
the ancillary data of the UNIX domain socket message (msg\_control).
\end{itemize}
+\subsection{Interfaces}
+
+The protocol includes several interfaces which are used for
+interacting with the server. Each interface provides requests,
+events, and errors (which are really just special events) as described
+above. Specific compositor implementations may have their own
+interfaces provided as extensions, but there are several which are
+always expected to be present.
+
+Core interfaces:
+\begin{itemize}
+\item wl_display: provides global functionality like objecting binding and fatal error events
+\item wl_callback: callback interface for dnoe events
+\item wl_compositor: core compositor interface, allows surface creation
+\item wl_shm: buffer management interface with buffer creation and format handling
+\item wl_buffer: buffer handling interface for indicating damage and object destruction, also provides buffer release events from the server
+\item wl_data_offer: for accepting and receiving specific mime types
+\item wl_data_source: for offering specific mime types
+\item wl_data_Device: lets clients manage drag & drop, provides pointer enter/leave events and motion
+\item wl_data_device_manager: for managing data sources and devices
+\item wl_shell: shell surface handling
+\item wl_shell_surface: shell surface handling and desktop-like events (e.g. set a surface to fullscreen, display a popup, etc.)
+\item wl_surface: surface management (destruction, damage, buffer attach, frame handling)
+\item wl_input_device: cursor setting, motion, button, and key events, etc.
+\item wl_output: events describing an attached output (subpixel orientation, current mode & geometry, etc.)
+\end{itemize}
+
\subsection{Connect Time}
\begin{itemize}
@@ -228,7 +255,7 @@ The compositor is a global object, advertised at connect time.
\begin{itemize}
\item a global object
-\item broadcasts drm file name, or at least a string like drm:/dev/card0
+\item broadcasts drm file name, or at least a string like drm:/dev/dri/card0
\item commit/ack/frame protocol
\end{itemize}
commit fb84662f617d2d8ec3f5724d6962a4109e6fb0ea
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Wed Jan 18 09:33:34 2012 -0800
spec: update high level description, add diagrams
Add diagrams from the Wayland architecture page and add some more high
level text describing X limitations and Wayland architecture.
diff --git a/spec/main.tex b/spec/main.tex
index f32e999..741c4e0 100644
--- a/spec/main.tex
+++ b/spec/main.tex
@@ -1,11 +1,12 @@
\documentclass{article}
\usepackage{palatino}
+\usepackage{graphicx}
\author{Kristian Høgsberg\\
\texttt{krh@bitplanet.net}
}
-\title{The Wayland Display Server}
+\title{The Wayland Compositing System}
\begin{document}
@@ -14,40 +15,97 @@
\section{Wayland Overview}
\begin{itemize}
-\item wayland is a protocol for a new display server.
-\item wayland is an implementation
+\item wayland is a protocol for a new display server.
+\item weston is the open source project implementing a wayland based compositor
\end{itemize}
\subsection{Replacing X11}
-Over time, a lot of functionality have slowly moved out of the X
-server and into client-side libraries or kernel drivers. One of the
-first components to move out was font rendering, with freetype and
-fontconfig providing an alternative to the core X fonts. Direct
-rendering OpenGL as a graphics driver in a client side library. Then
-cairo came along and provided a modern 2D rendering library
-independent of X and compositing managers took over control of the
-rendering of the desktop. Recently with GEM and KMS in the Linux
-kernel, we can do modesetting outside X and schedule several direct
-rendering clients. The end result is a highly modular graphics stack.
+In Linux and other Unix-like systems, the X stack has grown to
+encompass funcationality arguably belonging in client libraries,
+helper libraries, or the host operating system kernel. Support for
+things like PCI resource management, display configuration management,
+direct rendering, and memory management has been integrated into the X
+stack, imposing limitations like limited support for standalone
+applications, duplication in other projects (e.g. the Linux fb layer
+or the DirectFB project), and high levels of complexity for systems
+combining multiple elements (for example radeon memory map handling
+between the fb driver and X driver, or VT switching).
+
+Moreover, X has grown to incorporate modern features like offscreen
+rendering and scene composition, but subject to the limitations of the
+X architecture. For example, the X implementation of composition adds
+additional context switches and makes things like input redirection
+difficult.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=70mm]{x-architecture.png}
+\caption{\small \sl X with a compositing manager.\label{fig:X architecture}}
+\end{center}
+\end{figure}
+
+The diagram above illustrates the central role of the X server and
+compositor in operations, and the steps required to get contents on to
+the screen.
+
+Over time, X developers came to understand the shortcomings of this
+approach and worked to split things up. Over the past several years,
+a lot of functionality has moved out of the X server and into
+client-side libraries or kernel drivers. One of the first components
+to move out was font rendering, with freetype and fontconfig providing
+an alternative to the core X fonts. Direct rendering OpenGL as a
+graphics driver in a client side library went through some iterations,
+ending up as DRI2, which abstracted most of the direct rendering
+buffer management from client code. Then cairo came along and provided
+a modern 2D rendering library independent of X, and compositing
+managers took over control of the rendering of the desktop as toolkits
+like GTK+ and Qt moved away from using X APIs for rendering. Recently,
+memory and display management have moved to the Linux kernel, further
+reducing the scope of X and its driver stack. The end result is a
+highly modular graphics stack.
\subsection{Make the compositing manager the display server}
-Wayland is a new display server building on top of all those
-components. We are trying to distill out the functionality in the X
-server that is still used by the modern Linux desktop. This turns out
-to be not a whole lot. Applications can allocate their own off-screen
-buffers and render their window contents by themselves. In the end,
-what’s needed is a way to present the resulting window surface to a
-compositor and a way to receive input. This is what Wayland provides,
-by piecing together the components already in the eco-system in a
-slightly different way.
+Wayland is a new display server and compositing protocol, and Weston
+is the implementation of this protocol which builds on top of all the
+components above. We are trying to distill out the functionality in
+the X server that is still used by the modern Linux desktop. This
+turns out to be not a whole lot. Applications can allocate their own
+off-screen buffers and render their window contents directly, using
+hardware accelerated libraries like libGL, or high quality software
+implementations like those found in Cairo. In the end, what’s needed
+is a way to present the resulting window surface for display, and a
+way to receive and arbitrate input among multiple clients. This is
+what Wayland provides, by piecing together the components already in
+the eco-system in a slightly different way.
X will always be relevant, in the same way Fortran compilers and VRML
browsers are, but it’s time that we think about moving it out of the
critical path and provide it as an optional component for legacy
applications.
+Overall, the philosophy of Wayland is to provide clients with a way to
+manage windows and how their contents is displayed. Rendering is left
+to clients, and system wide memory management interfaces are used to
+pass buffer handles between clients and the compositing manager.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=50mm]{wayland-architecture.png}
+\caption{\small \sl The Wayland system\label{fig:Wayland architecture}}
+\end{center}
+\end{figure}
+
+The figure above illustrates how Wayland clients interact with a
+Wayland server. Note that window management and composition are
+handled entirely in the server, significantly reducing complexity
+while marginally improving performance through reduced context
+switching. The resulting system is easier to build and extend than a
+similar X system, because often changes need only be made in one
+place. Or in the case of protocol extensions, two (rather than 3 or 4
+in the X case where window management and/or composition handling may
+also need to be updated).
\section{Wayland protocol}
@@ -62,16 +120,16 @@ identifies which method in the interface to invoke.
The server sends back events to the client, each event is emitted from
an object. Events can be error conditions. The event includes the
object id and the event opcode, from which the client can determine
-the type of event. Events are generated both in response to a request
+the type of event. Events are generated both in response to requests
(in which case the request and the event constitutes a round trip) or
spontaneously when the server state changes.
\begin{itemize}
-\item state is broadcast on connect, events sent out when state
- change. client must listen for these changes and cache the state.
- no need (or mechanism) to query server state.
+\item state is broadcast on connect, events are sent out when state
+ changes. clients must listen for these changes and cache the state.
+ there is no need (or mechanism) to query server state.
-\item server will broadcast presence of a number of global objects,
+\item the server will broadcast the presence of a number of global objects,
which in turn will broadcast their current state.
\end{itemize}
@@ -82,7 +140,7 @@ This xml is used to generate the function prototypes that can be used by
clients and compositors.
The protocol entry points are generated as inline functions which just
-wraps the \verb:wl_proxy_*: functions. The inline functions aren't
+wrap the \verb:wl_proxy_*: functions. The inline functions aren't
part of the library ABI and language bindings should generate their
own stubs for the protocol entry points from the xml.
diff --git a/spec/wayland-architecture.png b/spec/wayland-architecture.png
new file mode 100644
index 0000000..4f92e0f
Binary files /dev/null and b/spec/wayland-architecture.png differ
diff --git a/spec/x-architecture.png b/spec/x-architecture.png
new file mode 100644
index 0000000..098205b
Binary files /dev/null and b/spec/x-architecture.png differ
commit f66aa1d08f75c6d89b539e2942baa18b454f83bc
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Jan 19 14:13:36 2012 -0800
scanner: allow summary attributes in args and <description> in <protocol>
Add support for arg summaries for use by detailed structure element
descriptions.
diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 722da4e..cad2507 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -34,8 +34,10 @@
</description>
<request name="bind">
<description summary="bind an object to the display">
+ Binds a new, client created object to the server using @name as
+ the identifier.
</description>
- <arg name="name" type="uint"/>
+ <arg name="name" type="uint" summary="unique number id for object"/>
<arg name="interface" type="string"/>
<arg name="version" type="uint"/>
<arg name="id" type="new_id" interface="wl_object"/>
diff --git a/src/scanner.c b/src/scanner.c
index e3b4226..f88fb4d 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -38,6 +38,11 @@ usage(int ret)
#define XML_BUFFER_SIZE 4096
+struct description {
+ char *summary;
+ char *text;
+};
+
struct protocol {
char *name;
char *uppercase_name;
@@ -45,11 +50,7 @@ struct protocol {
int type_index;
int null_run_length;
char *copyright;
-};
-
-struct description {
- char *summary;
- char *text;
+ struct description *description;
};
struct interface {
@@ -90,6 +91,7 @@ struct arg {
enum arg_type type;
char *interface_name;
struct wl_list link;
+ char *summary;
};
struct enumeration {
@@ -134,18 +136,10 @@ uppercase_dup(const char *src)
return u;
}
-static char *
-desc_dup(char *src)
+static void
+desc_dump(char *src, int startcol)
{
- char *u;
- int i, j = 0, col = 0, line = 0, len;
-
- len = strlen(src) * 2;
- u = malloc(len); /* enough room for newlines & comments */
- if (!u)
- return NULL;
-
- memset(u, 0, len);
+ int i, j = 0, col = startcol, line = 0, len;
/* Strip leading space */
for (i = 0; isspace(src[i]); i++)
@@ -161,21 +155,20 @@ desc_dup(char *src)
if (col > 72 && isspace(src[i])) {
if (src[i+1]) {
- u[j++] = '\n';
- u[j++] = ' ';
- u[j++] = '*';
- u[j++] = ' ';
+ putchar('\n');
+ for (j = 0; j < startcol; j++)
+ putchar(' ');
+ putchar(' ');
+ putchar('*');
+ putchar(' ');
}
line++;
- col = 0;
+ col = startcol;
} else {
- u[j++] = src[i];
+ putchar(src[i]);
col++;
}
}
- u[j++] = '\0';
-
- return u;
}
static void
@@ -228,6 +221,7 @@ start_element(void *data, const char *element_name, const char **atts)
ctx->protocol->name = strdup(name);
ctx->protocol->uppercase_name = uppercase_dup(name);
+ ctx->protocol->description = NULL;
} else if (strcmp(element_name, "copyright") == 0) {
} else if (strcmp(element_name, "interface") == 0) {
@@ -258,6 +252,7 @@ start_element(void *data, const char *element_name, const char **atts)
message->uppercase_name = uppercase_dup(name);
wl_list_init(&message->arg_list);
message->arg_count = 0;
+ message->description = NULL;
if (strcmp(element_name, "request") == 0)
wl_list_insert(ctx->interface->request_list.prev,
@@ -310,6 +305,10 @@ start_element(void *data, const char *element_name, const char **atts)
break;
}
+ arg->summary = NULL;
+ if (summary)
+ arg->summary = strdup(summary);
+
wl_list_insert(ctx->message->arg_list.prev, &arg->link);
ctx->message->arg_count++;
} else if (strcmp(element_name, "enum") == 0) {
@@ -357,8 +356,7 @@ start_element(void *data, const char *element_name, const char **atts)
else if (ctx->interface)
ctx->interface->description = description;
else
- fprintf(stderr,
- "<description> found in unsupported element\n");
+ ctx->protocol->description = description;
ctx->description = description;
}
}
@@ -376,7 +374,7 @@ end_element(void *data, const XML_Char *name)
char *text = strndup(ctx->character_data,
ctx->character_data_length);
if (text)
- ctx->description->text = desc_dup(text);
+ ctx->description->text = strdup(text);
ctx->description = NULL;
} else if (strcmp(name, "request") == 0 ||
strcmp(name, "event") == 0) {
@@ -605,7 +603,8 @@ emit_enumerations(struct interface *interface)
}
if (desc->text) {
printf(" *\n"
- " * %s\n", desc->text);
+ " * ");
+ desc_dump(desc->text, 0);
}
printf(" */\n");
}
@@ -642,13 +641,28 @@ emit_structs(struct wl_list *message_list, struct interface *interface)
"(none)");
}
printf(" *\n"
- " * %s\n"
- " */\n", desc->text);
+ " * ");
+ desc_dump(desc->text, 0);
+ printf(" */\n");
}
printf("struct %s_%s {\n", interface->name,
is_interface ? "interface" : "listener");
wl_list_for_each(m, message_list, link) {
+ struct description *mdesc = m->description;
+
+ printf("\t/**\n");
+ printf("\t * %s - %s\n", m->name, mdesc ? mdesc->summary :
+ "(none)");
+ wl_list_for_each(a, &m->arg_list, link) {
+ printf("\t * @%s: %s\n", a->name, a->summary ?
+ a->summary : "(none)");
+ }
+ if (mdesc) {
+ printf("\t * ");
+ desc_dump(mdesc->text, 8);
+ }
+ printf("\n\t */\n");
printf("\tvoid (*%s)(", m->name);
n = strlen(m->name) + 17;
commit 032b957698e03a3e6bb19dc051ecad1792da0385
Author: Kristian Høgsberg <krh@bitplanet.net>
Date: Wed Jan 18 19:17:23 2012 -0500
protocol: Convert comments to new documentation tags
diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 8d91187..722da4e 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -27,12 +27,10 @@
THIS SOFTWARE.
</copyright>
- <!-- The core global object. This is a special singleton object.
- It is used for internal wayland protocol features. -->
<interface name="wl_display" version="1">
<description summary="core global object">
- The core global object. This is a special singleton object.
- It is used for internal wayland protocol features.
+ The core global object. This is a special singleton object. It
+ is used for internal wayland protocol features.
</description>
<request name="bind">
<description summary="bind an object to the display">
@@ -43,17 +41,21 @@
<arg name="id" type="new_id" interface="wl_object"/>
</request>
- <!-- sync is an just an echo, which will reply with a key event.
- Since requests are handled in-order, this can be used as a
- barrier to ensure all previous requests have been handled.
- The key argument can be used to correlate between multiple
- sync invocations. -->
<request name="sync">
+ <description summary="asynchronous roundtrip">
+ The sync request asks the server to invoke the 'done' request
+ on the provided wl_callback object. Since requests are
+ handled in-order, this can be used as a barrier to ensure all
+ previous requests have been handled.
+ </description>
<arg name="callback" type="new_id" interface="wl_callback"/>
</request>
- <!-- A fatal error has occurred. -->
<event name="error">
+ <description summary="fatal error event">
+ The error event is sent out when a fatal (non-recoverable)
+ error has occurred.
+ </description>
<arg name="object_id" type="object" interface="wl_object"/>
<arg name="code" type="uint"/>
<arg name="message" type="string"/>
@@ -72,25 +74,33 @@
summary="server is out of memory"/>
</enum>
- <!-- Notify the client of global objects. These are objects that
- are created by the server. Globals are published on the
- initial client connection sequence, upon device hotplugs,
- device disconnects, reconfiguration or other events. The
- server will always announce an object before the object sends
- out events. -->
<event name="global">
+ <description summary="announce global object">
+ Notify the client of global objects. These are objects that
+ are created by the server. Globals are published on the
+ initial client connection sequence, upon device hotplugs,
+ device disconnects, reconfiguration or other events. A client
+ can 'bind' to a global object by using the bind request. This
+ creates a client side handle that lets the object emit events
+ to the client and lets the client invoke requests on the
+ object.
+ </description>
<arg name="name" type="uint"/>
<arg name="interface" type="string"/>
<arg name="version" type="uint"/>
</event>
- <!-- Notify the client of removed global objects. -->
<event name="global_remove">
- <arg name="name" type="uint" />
+ <description summary="announce removal of global object">
+ Notify the client of removed global objects.
+ </description>
+ <arg name="name" type="uint"/>
</event>
- <!-- Server has deleted the id and client can now reuse it. -->
<event name="delete_id">
+ <description summary="acknowledge object id deletion">
+ Server has deleted the id and client can now reuse it.
+ </description>
<arg name="id" type="uint" />
</event>
</interface>
@@ -101,19 +111,26 @@
</event>
</interface>
- <!-- A compositor. This object is a global. The compositor is in
- charge of combining the contents of multiple surfaces into one
- displayable output. -->
<interface name="wl_compositor" version="1">
- <!-- Factory request for a surface objects. A surface is akin to a
- window. -->
+ <description summary="the compositor singleton">
+ A compositor. This object is a singleton global. The
+ compositor is in charge of combining the contents of multiple
+ surfaces into one displayable output.
+ </description>
+
<request name="create_surface">
+ <description summary="create new surface">
+ Ask the compositor to create a new surface.
+ </description>
<arg name="id" type="new_id" interface="wl_surface"/>
</request>
</interface>
- <!-- Shared memory support -->
<interface name="wl_shm" version="1">
+ <description summary="shared memory support">
+ Support for shared memory buffers.
+ </description>
+
<enum name="error">
<entry name="invalid_format" value="0"/>
<entry name="invalid_stride" value="1"/>
@@ -125,13 +142,16 @@
<entry name="xrgb8888" value="1"/>
</enum>
- <!-- Transfer a shm buffer to the server. The allocated buffer
- would include at least stride * height bytes starting at the
- beginning of fd. The file descriptor is transferred over the
- socket using AF_UNIX magical features. width, height, stride
- and format describe the respective properties of the pixel
- data contained in the buffer. -->
<request name="create_buffer">
+ <description summary="create a wl_buffer">
+ Transfer a shm buffer to the server. The allocated buffer
+ would include at least stride * height bytes starting at the
+ beginning of fd. The file descriptor is transferred over the
+ socket using AF_UNIX magical features. width, height, stride
+ and format describe the respective properties of the pixel
+ data contained in the buffer.
+ </description>
+
<arg name="id" type="new_id" interface="wl_buffer"/>
<arg name="fd" type="fd"/>
<arg name="width" type="int"/>
@@ -145,36 +165,50 @@
</event>
</interface>
-
- <!-- A pixel buffer. Created using the drm, shm or similar objects.
- It has a size, visual and contents, but not a location on the
- screen. -->
<interface name="wl_buffer" version="1">
- <!-- Notify the server that the specified area of the buffers
- contents have changed. To describe a more complicated area
- of damage, break down the region into rectangles and use this
- request several times.
- -->
+ <description summary="content for a wl_surface">
+ A buffer provides the content for a wl_surface. Buffers are
+ created through factory interfaces such as wl_drm, wl_shm or
+ similar. It has a width and a height and can be attached to a
+ wl_surface, but the mechnism by which a client provides and
+ updates the contents is defined by the buffer factory interface
+ </description>
+
<request name="damage">
+ <description summary="mark part of the buffer damaged">
+ Notify the server that the specified area of the buffers
+ contents have changed. To describe a more complicated area of
+ damage, break down the region into rectangles and use this
+ request several times.
+ </description>
+
<arg name="x" type="int"/>
<arg name="y" type="int"/>
<arg name="width" type="int"/>
<arg name="height" type="int"/>
</request>
- <!-- Destroy a buffer. This will invalidate the object id. -->
- <request name="destroy" type="destructor"/>
+ <request name="destroy" type="destructor">
+ <description summary="destroy a buffer">
+ Destroy a buffer. This will invalidate the object id.
+ </description>
+ </request>
- <!-- Sent when an attached buffer is no longer used by the compositor. -->
- <event name="release"/>
+ <event name="release">
+ <description summary="compositor releses buffer">
+ Sent when an attached buffer is no longer used by the compositor.
+ </description>
+ </event>
</interface>
<interface name="wl_data_offer" version="1">
- <!-- Indicate that the client can accept the given mime-type, or
- NULL for not accepted. Use for feedback during drag and
- drop. -->
<request name="accept">
+ <description summary="accept one of the offered mime-types">
+ Indicate that the client can accept the given mime-type, or
+ NULL for not accepted. Use for feedback during drag and drop.
+ </description>
+
<arg name="time" type="uint"/>
<arg name="type" type="string"/>
</request>
@@ -186,39 +220,57 @@
<request name="destroy" type="destructor"/>
- <!-- Sent immediately after creating the wl_data_offer object. One
- event per offered mime type. -->
<event name="offer">
+ <description summary="advertise offered mime-type">
+ Sent immediately after creating the wl_data_offer object. One
+ event per offered mime type.
+ </description>
+
<arg name="type" type="string"/>
</event>
</interface>
<interface name="wl_data_source" version="1">
- <!-- Add an offered mime type. Can be called several times to
- offer multiple types. -->
<request name="offer">
+ <description summary="add an offered mime type">
+ This request adds a mime-type to the set of mime-types
+ advertised to targets. Can be called several times to offer
+ multiple types.
+ </description>
<arg name="type" type="string"/>
</request>
- <!-- Destroy the selection. -->
- <request name="destroy" type="destructor"/>
+ <request name="destroy" type="destructor">
+ <description summary="destroy the data source">
+ Destroy the data source.
+ </description>
+ </request>
- <!-- Sent when a target accepts pointer_focus or motion events.
- If a target does not accept any of the offered types, type is
- NULL -->
<event name="target">
+ <description summary="a target accepts an offered mime-type">
+ Sent when a target accepts pointer_focus or motion events. If
+ a target does not accept any of the offered types, type is NULL.
+ </description>
+
<arg name="mime_type" type="string"/>
</event>
- <!-- Request for data from another client. Send the data in the
- specified mime-type over the passed fd, the close it. -->
<event name="send">
+ <description summary="send the data">
+ Request for data from another client. Send the data as the
+ specified mime-type over the passed fd, then close the fd.
+ </description>
+
<arg name="mime_type" type="string"/>
<arg name="fd" type="fd"/>
</event>
- <!-- Another selection became active. -->
- <event name="cancelled"/>
+ <event name="cancelled">
+ <description summary="selection was cancelled">
+ Another selection became active.
+ </description>
+ </event>
+
</interface>
<interface name="wl_data_device" version="1">
@@ -240,14 +292,17 @@
<arg name="time" type="uint"/>
</request>
- <!-- The data_offer event introduces a new wl_data_offer object,
- which will subsequently be used in either the
- data_device.enter event (for drag and drop) or the
- data_device.selection event (for selections). Immediately
- following the data_device_data_offer event, the new
- data_offer object will send out data_offer.offer events to
- describe the mime-types it offers. -->
<event name="data_offer">
+ <description summary="introduce a new wl_data_offer">
+ The data_offer event introduces a new wl_data_offer object,
+ which will subsequently be used in either the
+ data_device.enter event (for drag and drop) or the
+ data_device.selection event (for selections). Immediately
+ following the data_device_data_offer event, the new data_offer
+ object will send out data_offer.offer events to describe the
+ mime-types it offers.
+ </description>
+
<arg name="id" type="new_id" interface="wl_data_offer"/>
</event>
@@ -269,16 +324,18 @@
<event name="drop"/>
- <!-- The selection event is sent out to notify the client of a new
- wl_data_offer for the selection for this device. The
- data_device.data_offer and the data_offer.offer events are
- sent out immediately before this event to introduce the data
- offer object. The selection event is sent to a client
- immediately before receiving keyboard focus and when a new
- selection is set while the client has keyboard focus. The
- data_offer is valid until a new data_offer or NULL is
- received or until the client loses keyboard focus. -->
<event name="selection">
+ <description summary="advertise new selection">
+ The selection event is sent out to notify the client of a new
+ wl_data_offer for the selection for this device. The
+ data_device.data_offer and the data_offer.offer events are
+ sent out immediately before this event to introduce the data
+ offer object. The selection event is sent to a client
+ immediately before receiving keyboard focus and when a new
+ selection is set while the client has keyboard focus. The
+ data_offer is valid until a new data_offer or NULL is received
+ or until the client loses keyboard focus.
+ </description>
<arg name="id" type="object" interface="wl_data_offer"/>
</event>
</interface>
@@ -301,12 +358,15 @@
</request>
</interface>
- <!-- A wrapper interface for shell related actions on a wl_surface.
- On server side the object is automatically destroyed when the
- related wl_surface is destroyed.
- On client side, wl_shell_surface_destroy() must be called
- before destroying the wl_surface object. -->
<interface name="wl_shell_surface" version="1">
+
+ <description summary="desktop style meta data interface">
+ An interface implemented by a wl_surface. On server side the
+ object is automatically destroyed when the related wl_surface is
+ destroyed. On client side, wl_shell_surface_destroy() must be
+ called before destroying the wl_surface object.
+ </description>
+
<request name="move">
<arg name="input_device" type="object" interface="wl_input_device"/>
<arg name="time" type="uint"/>
@@ -327,51 +387,60 @@
<request name="resize">
<arg name="input_device" type="object" interface="wl_input_device"/>
<arg name="time" type="uint"/>
- <!-- edges is an enum, need to get the values in here -->
<arg name="edges" type="uint"/>
</request>
- <!-- Make the surface visible as a toplevel window. -->
- <request name="set_toplevel"/>
-
- <!-- Map the surface relative to an existing surface. 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. The flags argument controls overflow/clipping
- behaviour when the surface would intersect a screen edge,
- panel or such. And possibly whether the offset only
- determines the initial position or if the surface is locked
- to that relative position during moves. -->
+ <request name="set_toplevel">
+ <description summary="make the surface a top level surface">
+ Make the surface a toplevel window.
+ </description>
+ </request>
+
<request name="set_transient">
+ <description summary="make the surface a transient surface">
+ Map the surface relative to an existing surface. 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. The flags argument controls overflow/clipping
+ behaviour when the surface would intersect a screen edge,
+ panel or such. And possibly whether the offset only
+ determines the initial position or if the surface is locked to
+ that relative position during moves.
+ </description>
+
<arg name="parent" type="object" interface="wl_shell_surface"/>
<arg name="x" type="int"/>
<arg name="y" type="int"/>
<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"/>
-
- <!-- Popup surfaces. Will switch an implicit grab into
- owner-events mode, and grab will continue after the implicit
- grab ends (button released). Once the implicit grab is over,
- the popup grab continues until the window is destroyed or a
- mouse button is pressed in any other clients window. A click
- in any of the clients surfaces is reported as normal,
- however, clicks in other clients surfaces will be discarded
- and trigger the callback.
-
- TODO: Grab keyboard too, maybe just terminate on any click
- inside or outside the surface?
- -->
+ <request name="set_fullscreen">
+ <description summary="make the surface a fullscreen surface">
+ 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?
+ </description>
+ </request>
+
<request name="set_popup">
+ <description summary="make the surface a popup surface">
+ Popup surfaces. Will switch an implicit grab into
+ owner-events mode, and grab will continue after the implicit
+ grab ends (button released). Once the implicit grab is over,
+ the popup grab continues until the window is destroyed or a
+ mouse button is pressed in any other clients window. A click
+ in any of the clients surfaces is reported as normal, however,
+ clicks in other clients surfaces will be discarded and trigger
+ the callback.
+
+ TODO: Grab keyboard too, maybe just terminate on any click
+ inside or outside the surface?
+ </description>
+
<arg name="input_device" type="object" interface="wl_input_device"/>
<arg name="time" type="uint"/>
<arg name="parent" type="object" interface="wl_shell_surface"/>
@@ -380,83 +449,111 @@
<arg name="flags" type="uint"/>
</request>
- <!-- The configure event asks the client to resize its surface.
- The size is a hint, in the sense that the client is free to
- ignore it if it doesn't resize, pick a smaller size (to
- satisfy aspect ration or resize in steps of NxM pixels). The
- client is free to dismiss all but the last configure event it
- received. -->
<event name="configure">
+ <description summary="suggest resize">
+ The configure event asks the client to resize its surface.
+ The size is a hint, in the sense that the client is free to
+ ignore it if it doesn't resize, pick a smaller size (to
+ satisfy aspect ration or resize in steps of NxM pixels). The
+ client is free to dismiss all but the last configure event it
+ received.
+ </description>
+
<arg name="time" type="uint"/>
<arg name="edges" type="uint"/>
<arg name="width" type="int"/>
<arg name="height" type="int"/>
</event>
- <!-- 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
- to the client owning the popup surface. -->
- <event name="popup_done"/>
+ <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
+ to the client owning the popup surface.
+ </description>
+ </event>
</interface>
-
- <!-- A surface. This is an image that is displayed on the screen.
- It has a location, size and pixel contents. Similar to a window. -->
<interface name="wl_surface" version="1">
- <!-- Deletes the surface and invalidates its object id. -->
- <request name="destroy" type="destructor"/>
+ <description summary="an onscreen surface">
+ A surface. This is an image that is displayed on the screen.
+ It has a location, size and pixel contents.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="delete surface">
+ Deletes the surface and invalidates its object id.
+ </description>
+ </request>
- <!-- Copy the contents of a buffer into this surface. The x and y
- arguments specify the location of the new buffers upper left
- corner, relative to the old buffers upper left corner. -->
<request name="attach">
+ <description summary="set the surface contents">
+ Copy the contents of a buffer into this surface. The x and y
Reply to: