2010-11-30 03:05:26 +08:00
|
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
2010-09-15 03:52:43 +08:00
|
|
|
<protocol name="wayland">
|
2010-08-03 21:26:44 +08:00
|
|
|
|
2011-07-26 09:14:20 +08:00
|
|
|
<copyright>
|
|
|
|
|
Copyright © 2008-2011 Kristian Høgsberg
|
|
|
|
|
Copyright © 2010-2011 Intel Corporation
|
|
|
|
|
|
|
|
|
|
Permission to use, copy, modify, distribute, and sell this
|
|
|
|
|
software and its documentation for any purpose is hereby granted
|
2012-01-24 23:49:28 +08:00
|
|
|
without fee, provided that the above copyright notice appear in
|
2011-07-26 09:14:20 +08:00
|
|
|
all copies and that both that copyright notice and this permission
|
|
|
|
|
notice appear in supporting documentation, and that the name of
|
|
|
|
|
the copyright holders not be used in advertising or publicity
|
|
|
|
|
pertaining to distribution of the software without specific,
|
|
|
|
|
written prior permission. The copyright holders make no
|
|
|
|
|
representations about the suitability of this software for any
|
|
|
|
|
purpose. It is provided "as is" without express or implied
|
|
|
|
|
warranty.
|
|
|
|
|
|
|
|
|
|
THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
|
|
|
|
|
SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
|
|
|
|
|
FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
|
|
|
|
|
SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
|
|
|
|
|
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
|
|
|
|
|
AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
|
|
|
|
|
ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
|
|
|
|
|
THIS SOFTWARE.
|
|
|
|
|
</copyright>
|
|
|
|
|
|
2011-04-18 22:24:11 +08:00
|
|
|
<interface name="wl_display" version="1">
|
scanner: Support documentation elements
On Wed, 18 Jan 2012 12:29:37 -0800
"Kristensen, Kristian H" <kristian.h.kristensen@intel.com> wrote:
> Yeah, that looks good. I was thinking of a separate <description> tag
> to avoid stuffing too much into an attribute.
How does this look? It adds a summary attribute to atomic elements,
and a <description> tag with a summary for others. Spits out enum
documentation like this:
/**
* wl_display_error - global error values
* @WL_DISPLAY_ERROR_INVALID_OBJECT: server couldn't find object
* @WL_DISPLAY_ERROR_INVALID_METHOD: method doesn't exist on the specified interface
* @WL_DISPLAY_ERROR_NO_MEMORY: server is out of memory
*
* These errors are global and can be emitted in response to any server request.
*/
enum wl_display_error {
WL_DISPLAY_ERROR_INVALID_OBJECT = 0,
WL_DISPLAY_ERROR_INVALID_METHOD = 1,
WL_DISPLAY_ERROR_NO_MEMORY = 2,
};
and structure documentation like this:
/**
* wl_display - core global object
* @bind: bind an object to the display
* @sync: (none)
*
* The core global object. This is a special singleton object. It is used for
* internal wayland protocol features.
*/
struct wl_display_interface {
void (*bind)(struct wl_client *client,
struct wl_resource *resource,
uint32_t name,
const char *interface,
uint32_t version,
uint32_t id);
void (*sync)(struct wl_client *client,
struct wl_resource *resource,
uint32_t callback);
};
2012-01-19 06:09:47 +08:00
|
|
|
<description summary="core global object">
|
2012-01-19 08:17:23 +08:00
|
|
|
The core global object. This is a special singleton object. It
|
|
|
|
|
is used for internal wayland protocol features.
|
scanner: Support documentation elements
On Wed, 18 Jan 2012 12:29:37 -0800
"Kristensen, Kristian H" <kristian.h.kristensen@intel.com> wrote:
> Yeah, that looks good. I was thinking of a separate <description> tag
> to avoid stuffing too much into an attribute.
How does this look? It adds a summary attribute to atomic elements,
and a <description> tag with a summary for others. Spits out enum
documentation like this:
/**
* wl_display_error - global error values
* @WL_DISPLAY_ERROR_INVALID_OBJECT: server couldn't find object
* @WL_DISPLAY_ERROR_INVALID_METHOD: method doesn't exist on the specified interface
* @WL_DISPLAY_ERROR_NO_MEMORY: server is out of memory
*
* These errors are global and can be emitted in response to any server request.
*/
enum wl_display_error {
WL_DISPLAY_ERROR_INVALID_OBJECT = 0,
WL_DISPLAY_ERROR_INVALID_METHOD = 1,
WL_DISPLAY_ERROR_NO_MEMORY = 2,
};
and structure documentation like this:
/**
* wl_display - core global object
* @bind: bind an object to the display
* @sync: (none)
*
* The core global object. This is a special singleton object. It is used for
* internal wayland protocol features.
*/
struct wl_display_interface {
void (*bind)(struct wl_client *client,
struct wl_resource *resource,
uint32_t name,
const char *interface,
uint32_t version,
uint32_t id);
void (*sync)(struct wl_client *client,
struct wl_resource *resource,
uint32_t callback);
};
2012-01-19 06:09:47 +08:00
|
|
|
</description>
|
2011-04-14 22:38:44 +08:00
|
|
|
<request name="bind">
|
scanner: Support documentation elements
On Wed, 18 Jan 2012 12:29:37 -0800
"Kristensen, Kristian H" <kristian.h.kristensen@intel.com> wrote:
> Yeah, that looks good. I was thinking of a separate <description> tag
> to avoid stuffing too much into an attribute.
How does this look? It adds a summary attribute to atomic elements,
and a <description> tag with a summary for others. Spits out enum
documentation like this:
/**
* wl_display_error - global error values
* @WL_DISPLAY_ERROR_INVALID_OBJECT: server couldn't find object
* @WL_DISPLAY_ERROR_INVALID_METHOD: method doesn't exist on the specified interface
* @WL_DISPLAY_ERROR_NO_MEMORY: server is out of memory
*
* These errors are global and can be emitted in response to any server request.
*/
enum wl_display_error {
WL_DISPLAY_ERROR_INVALID_OBJECT = 0,
WL_DISPLAY_ERROR_INVALID_METHOD = 1,
WL_DISPLAY_ERROR_NO_MEMORY = 2,
};
and structure documentation like this:
/**
* wl_display - core global object
* @bind: bind an object to the display
* @sync: (none)
*
* The core global object. This is a special singleton object. It is used for
* internal wayland protocol features.
*/
struct wl_display_interface {
void (*bind)(struct wl_client *client,
struct wl_resource *resource,
uint32_t name,
const char *interface,
uint32_t version,
uint32_t id);
void (*sync)(struct wl_client *client,
struct wl_resource *resource,
uint32_t callback);
};
2012-01-19 06:09:47 +08:00
|
|
|
<description summary="bind an object to the display">
|
2012-02-23 13:55:41 +08:00
|
|
|
Binds a new, client-created object to the server using @name as
|
2012-01-20 06:13:36 +08:00
|
|
|
the identifier.
|
scanner: Support documentation elements
On Wed, 18 Jan 2012 12:29:37 -0800
"Kristensen, Kristian H" <kristian.h.kristensen@intel.com> wrote:
> Yeah, that looks good. I was thinking of a separate <description> tag
> to avoid stuffing too much into an attribute.
How does this look? It adds a summary attribute to atomic elements,
and a <description> tag with a summary for others. Spits out enum
documentation like this:
/**
* wl_display_error - global error values
* @WL_DISPLAY_ERROR_INVALID_OBJECT: server couldn't find object
* @WL_DISPLAY_ERROR_INVALID_METHOD: method doesn't exist on the specified interface
* @WL_DISPLAY_ERROR_NO_MEMORY: server is out of memory
*
* These errors are global and can be emitted in response to any server request.
*/
enum wl_display_error {
WL_DISPLAY_ERROR_INVALID_OBJECT = 0,
WL_DISPLAY_ERROR_INVALID_METHOD = 1,
WL_DISPLAY_ERROR_NO_MEMORY = 2,
};
and structure documentation like this:
/**
* wl_display - core global object
* @bind: bind an object to the display
* @sync: (none)
*
* The core global object. This is a special singleton object. It is used for
* internal wayland protocol features.
*/
struct wl_display_interface {
void (*bind)(struct wl_client *client,
struct wl_resource *resource,
uint32_t name,
const char *interface,
uint32_t version,
uint32_t id);
void (*sync)(struct wl_client *client,
struct wl_resource *resource,
uint32_t callback);
};
2012-01-19 06:09:47 +08:00
|
|
|
</description>
|
2012-01-20 06:13:36 +08:00
|
|
|
<arg name="name" type="uint" summary="unique number id for object"/>
|
2011-04-14 22:38:44 +08:00
|
|
|
<arg name="interface" type="string"/>
|
|
|
|
|
<arg name="version" type="uint"/>
|
2011-08-20 01:44:01 +08:00
|
|
|
<arg name="id" type="new_id" interface="wl_object"/>
|
2011-04-14 22:38:44 +08:00
|
|
|
</request>
|
|
|
|
|
|
2010-09-04 02:46:38 +08:00
|
|
|
<request name="sync">
|
2012-01-19 08:17:23 +08:00
|
|
|
<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>
|
2011-07-30 10:51:22 +08:00
|
|
|
<arg name="callback" type="new_id" interface="wl_callback"/>
|
2010-09-04 02:46:38 +08:00
|
|
|
</request>
|
|
|
|
|
|
2011-05-11 22:57:06 +08:00
|
|
|
<event name="error">
|
2012-01-19 08:17:23 +08:00
|
|
|
<description summary="fatal error event">
|
|
|
|
|
The error event is sent out when a fatal (non-recoverable)
|
|
|
|
|
error has occurred.
|
|
|
|
|
</description>
|
2011-05-11 22:57:06 +08:00
|
|
|
<arg name="object_id" type="object" interface="wl_object"/>
|
|
|
|
|
<arg name="code" type="uint"/>
|
|
|
|
|
<arg name="message" type="string"/>
|
2010-08-03 21:26:44 +08:00
|
|
|
</event>
|
|
|
|
|
|
2011-05-11 22:57:06 +08:00
|
|
|
<enum name="error">
|
scanner: Support documentation elements
On Wed, 18 Jan 2012 12:29:37 -0800
"Kristensen, Kristian H" <kristian.h.kristensen@intel.com> wrote:
> Yeah, that looks good. I was thinking of a separate <description> tag
> to avoid stuffing too much into an attribute.
How does this look? It adds a summary attribute to atomic elements,
and a <description> tag with a summary for others. Spits out enum
documentation like this:
/**
* wl_display_error - global error values
* @WL_DISPLAY_ERROR_INVALID_OBJECT: server couldn't find object
* @WL_DISPLAY_ERROR_INVALID_METHOD: method doesn't exist on the specified interface
* @WL_DISPLAY_ERROR_NO_MEMORY: server is out of memory
*
* These errors are global and can be emitted in response to any server request.
*/
enum wl_display_error {
WL_DISPLAY_ERROR_INVALID_OBJECT = 0,
WL_DISPLAY_ERROR_INVALID_METHOD = 1,
WL_DISPLAY_ERROR_NO_MEMORY = 2,
};
and structure documentation like this:
/**
* wl_display - core global object
* @bind: bind an object to the display
* @sync: (none)
*
* The core global object. This is a special singleton object. It is used for
* internal wayland protocol features.
*/
struct wl_display_interface {
void (*bind)(struct wl_client *client,
struct wl_resource *resource,
uint32_t name,
const char *interface,
uint32_t version,
uint32_t id);
void (*sync)(struct wl_client *client,
struct wl_resource *resource,
uint32_t callback);
};
2012-01-19 06:09:47 +08:00
|
|
|
<description summary="global error values">
|
|
|
|
|
These errors are global and can be emitted in response to any
|
|
|
|
|
server request.
|
|
|
|
|
</description>
|
|
|
|
|
<entry name="invalid_object" value="0"
|
|
|
|
|
summary="server couldn't find object"/>
|
|
|
|
|
<entry name="invalid_method" value="1"
|
|
|
|
|
summary="method doesn't exist on the specified interface"/>
|
|
|
|
|
<entry name="no_memory" value="2"
|
|
|
|
|
summary="server is out of memory"/>
|
2011-05-11 22:57:06 +08:00
|
|
|
</enum>
|
2010-08-03 21:26:44 +08:00
|
|
|
|
|
|
|
|
<event name="global">
|
2012-01-19 08:17:23 +08:00
|
|
|
<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>
|
2011-10-25 04:04:09 +08:00
|
|
|
<arg name="name" type="uint"/>
|
2011-08-20 04:57:48 +08:00
|
|
|
<arg name="interface" type="string"/>
|
2010-08-03 21:26:44 +08:00
|
|
|
<arg name="version" type="uint"/>
|
|
|
|
|
</event>
|
|
|
|
|
|
2011-06-14 16:35:46 +08:00
|
|
|
<event name="global_remove">
|
2012-01-19 08:17:23 +08:00
|
|
|
<description summary="announce removal of global object">
|
|
|
|
|
Notify the client of removed global objects.
|
|
|
|
|
</description>
|
|
|
|
|
<arg name="name" type="uint"/>
|
2011-06-14 16:35:46 +08:00
|
|
|
</event>
|
|
|
|
|
|
2011-11-16 11:20:28 +08:00
|
|
|
<event name="delete_id">
|
2012-01-19 08:17:23 +08:00
|
|
|
<description summary="acknowledge object id deletion">
|
|
|
|
|
Server has deleted the id and client can now reuse it.
|
|
|
|
|
</description>
|
2011-11-16 11:20:28 +08:00
|
|
|
<arg name="id" type="uint" />
|
|
|
|
|
</event>
|
2011-07-30 10:51:22 +08:00
|
|
|
</interface>
|
2010-08-03 21:26:44 +08:00
|
|
|
|
2011-07-30 10:51:22 +08:00
|
|
|
<interface name="wl_callback" version="1">
|
|
|
|
|
<event name="done">
|
Switch protocol to using serial numbers for ordering events and requests
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
2012-04-12 10:25:51 +08:00
|
|
|
<arg name="serial" type="uint"/>
|
2010-08-03 21:26:44 +08:00
|
|
|
</event>
|
|
|
|
|
</interface>
|
|
|
|
|
|
2011-04-18 22:24:11 +08:00
|
|
|
<interface name="wl_compositor" version="1">
|
2012-01-19 08:17:23 +08:00
|
|
|
<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>
|
|
|
|
|
|
2010-09-04 02:46:38 +08:00
|
|
|
<request name="create_surface">
|
2012-01-19 08:17:23 +08:00
|
|
|
<description summary="create new surface">
|
|
|
|
|
Ask the compositor to create a new surface.
|
|
|
|
|
</description>
|
2011-04-18 22:24:11 +08:00
|
|
|
<arg name="id" type="new_id" interface="wl_surface"/>
|
2010-09-04 02:46:38 +08:00
|
|
|
</request>
|
2012-02-24 03:50:06 +08:00
|
|
|
|
|
|
|
|
<request name="create_region">
|
|
|
|
|
<description summary="create new region">
|
|
|
|
|
Ask the compositor to create a new region.
|
|
|
|
|
</description>
|
|
|
|
|
<arg name="id" type="new_id" interface="wl_region"/>
|
|
|
|
|
</request>
|
2010-09-04 02:46:38 +08:00
|
|
|
</interface>
|
|
|
|
|
|
2012-04-04 00:08:50 +08:00
|
|
|
<interface name="wl_shm_pool" version="1">
|
|
|
|
|
<description summary="a shared memory pool">
|
|
|
|
|
The wl_shm_pool object encapsulates a piece of memory shared
|
|
|
|
|
between the compsitor and client. Through the wl_shm_pool
|
|
|
|
|
object, the client can allocate shared memory wl_buffer objects.
|
|
|
|
|
The objects will share the same underlying mapped memory.
|
|
|
|
|
Reusing the mapped memory avoids the setup/teardown overhead and
|
|
|
|
|
is useful when interactively resizing a surface or for many
|
|
|
|
|
small buffers.
|
|
|
|
|
</description>
|
|
|
|
|
|
|
|
|
|
<request name="create_buffer">
|
|
|
|
|
<description summary="create wl_buffer from pool">
|
|
|
|
|
Create a wl_buffer from the pool. The buffer is created a
|
|
|
|
|
offset bytes into the pool and has width and height as
|
|
|
|
|
specified. The stride arguments specifies the number of bytes
|
|
|
|
|
from beginning of one row to the beginning of the next. The
|
|
|
|
|
format is the pixel format of the buffer and must be one of
|
|
|
|
|
those advertised through the wl_shm.format event.
|
|
|
|
|
|
|
|
|
|
A buffer will keep a reference to the pool it was created from
|
|
|
|
|
so it is valid to destroy the pool immediatedly after creating
|
|
|
|
|
a buffer from it.
|
|
|
|
|
</description>
|
|
|
|
|
|
|
|
|
|
<arg name="id" type="new_id" interface="wl_buffer"/>
|
|
|
|
|
<arg name="offset" type="int"/>
|
|
|
|
|
<arg name="width" type="int"/>
|
|
|
|
|
<arg name="height" type="int"/>
|
|
|
|
|
<arg name="stride" type="int"/>
|
|
|
|
|
<arg name="format" type="uint"/>
|
|
|
|
|
</request>
|
|
|
|
|
|
|
|
|
|
<request name="destroy" type="destructor">
|
|
|
|
|
<description summary="destroy the pool">
|
|
|
|
|
Destroy the pool.
|
|
|
|
|
</description>
|
|
|
|
|
</request>
|
2012-05-22 20:39:40 +08:00
|
|
|
|
|
|
|
|
<request name="resize">
|
|
|
|
|
<description summary="change the size of the pool mapping">
|
|
|
|
|
This request will cause the server to remap the backing memory
|
|
|
|
|
for the pool from the fd passed when the pool was creating but
|
|
|
|
|
using the new size.
|
|
|
|
|
</description>
|
|
|
|
|
|
|
|
|
|
<arg name="size" type="int"/>
|
|
|
|
|
</request>
|
2012-04-04 00:08:50 +08:00
|
|
|
</interface>
|
|
|
|
|
|
2011-04-18 22:24:11 +08:00
|
|
|
<interface name="wl_shm" version="1">
|
2012-01-19 08:17:23 +08:00
|
|
|
<description summary="shared memory support">
|
|
|
|
|
Support for shared memory buffers.
|
|
|
|
|
</description>
|
|
|
|
|
|
2011-05-11 23:00:40 +08:00
|
|
|
<enum name="error">
|
2011-08-31 09:26:19 +08:00
|
|
|
<entry name="invalid_format" value="0"/>
|
2011-05-11 23:00:40 +08:00
|
|
|
<entry name="invalid_stride" value="1"/>
|
|
|
|
|
<entry name="invalid_fd" value="2"/>
|
|
|
|
|
</enum>
|
|
|
|
|
|
2011-08-31 09:26:19 +08:00
|
|
|
<enum name="format">
|
2012-01-12 03:19:50 +08:00
|
|
|
<entry name="argb8888" value="0"/>
|
|
|
|
|
<entry name="xrgb8888" value="1"/>
|
2011-08-31 09:26:19 +08:00
|
|
|
</enum>
|
|
|
|
|
|
2012-04-04 00:08:50 +08:00
|
|
|
<request name="create_pool">
|
|
|
|
|
<description summary="create a shm pool">
|
|
|
|
|
This creates wl_shm_pool object, which can be used to create
|
|
|
|
|
shared memory based wl_buffer objects. The server will mmap
|
|
|
|
|
size bytes of the passed fd, to use as backing memory for then
|
|
|
|
|
pool.
|
2012-01-19 08:17:23 +08:00
|
|
|
</description>
|
|
|
|
|
|
2012-04-04 00:08:50 +08:00
|
|
|
<arg name="id" type="new_id" interface="wl_shm_pool"/>
|
2010-10-07 09:17:40 +08:00
|
|
|
<arg name="fd" type="fd"/>
|
2012-04-04 00:08:50 +08:00
|
|
|
<arg name="size" type="int"/>
|
2010-10-07 09:17:40 +08:00
|
|
|
</request>
|
2011-08-31 09:26:19 +08:00
|
|
|
|
|
|
|
|
<event name="format">
|
|
|
|
|
<arg name="format" type="uint"/>
|
|
|
|
|
</event>
|
2010-10-07 09:17:40 +08:00
|
|
|
</interface>
|
|
|
|
|
|
2011-04-18 22:24:11 +08:00
|
|
|
<interface name="wl_buffer" version="1">
|
2012-01-19 08:17:23 +08:00
|
|
|
<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
|
2012-01-24 23:49:28 +08:00
|
|
|
wl_surface, but the mechanism by which a client provides and
|
2012-01-19 08:17:23 +08:00
|
|
|
updates the contents is defined by the buffer factory interface
|
|
|
|
|
</description>
|
|
|
|
|
|
|
|
|
|
<request name="destroy" type="destructor">
|
|
|
|
|
<description summary="destroy a buffer">
|
|
|
|
|
Destroy a buffer. This will invalidate the object id.
|
|
|
|
|
</description>
|
|
|
|
|
</request>
|
2011-05-09 23:35:58 +08:00
|
|
|
|
2012-01-19 08:17:23 +08:00
|
|
|
<event name="release">
|
2012-01-24 23:49:28 +08:00
|
|
|
<description summary="compositor releases buffer">
|
2012-01-19 08:17:23 +08:00
|
|
|
Sent when an attached buffer is no longer used by the compositor.
|
|
|
|
|
</description>
|
|
|
|
|
</event>
|
2010-08-10 02:43:33 +08:00
|
|
|
</interface>
|
|
|
|
|
|
2011-11-15 21:58:34 +08:00
|
|
|
|
|
|
|
|
<interface name="wl_data_offer" version="1">
|
|
|
|
|
<request name="accept">
|
2012-01-19 08:17:23 +08:00
|
|
|
<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>
|
|
|
|
|
|
Switch protocol to using serial numbers for ordering events and requests
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
2012-04-12 10:25:51 +08:00
|
|
|
<arg name="serial" type="uint"/>
|
2012-07-02 18:03:31 +08:00
|
|
|
<arg name="type" type="string" allow-null="true"/>
|
2011-11-15 21:58:34 +08:00
|
|
|
</request>
|
|
|
|
|
|
|
|
|
|
<request name="receive">
|
|
|
|
|
<arg name="mime_type" type="string"/>
|
|
|
|
|
<arg name="fd" type="fd"/>
|
|
|
|
|
</request>
|
|
|
|
|
|
|
|
|
|
<request name="destroy" type="destructor"/>
|
|
|
|
|
|
|
|
|
|
<event name="offer">
|
2012-01-19 08:17:23 +08:00
|
|
|
<description summary="advertise offered mime-type">
|
|
|
|
|
Sent immediately after creating the wl_data_offer object. One
|
|
|
|
|
event per offered mime type.
|
|
|
|
|
</description>
|
|
|
|
|
|
2011-11-15 21:58:34 +08:00
|
|
|
<arg name="type" type="string"/>
|
|
|
|
|
</event>
|
|
|
|
|
</interface>
|
|
|
|
|
|
|
|
|
|
<interface name="wl_data_source" version="1">
|
|
|
|
|
<request name="offer">
|
2012-01-19 08:17:23 +08:00
|
|
|
<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>
|
2011-11-15 21:58:34 +08:00
|
|
|
<arg name="type" type="string"/>
|
|
|
|
|
</request>
|
|
|
|
|
|
2012-01-19 08:17:23 +08:00
|
|
|
<request name="destroy" type="destructor">
|
|
|
|
|
<description summary="destroy the data source">
|
|
|
|
|
Destroy the data source.
|
|
|
|
|
</description>
|
|
|
|
|
</request>
|
2011-11-15 21:58:34 +08:00
|
|
|
|
|
|
|
|
<event name="target">
|
2012-01-19 08:17:23 +08:00
|
|
|
<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>
|
|
|
|
|
|
2012-07-02 18:03:31 +08:00
|
|
|
<arg name="mime_type" type="string" allow-null="true"/>
|
2011-11-15 21:58:34 +08:00
|
|
|
</event>
|
|
|
|
|
|
|
|
|
|
<event name="send">
|
2012-01-19 08:17:23 +08:00
|
|
|
<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>
|
|
|
|
|
|
2011-11-15 21:58:34 +08:00
|
|
|
<arg name="mime_type" type="string"/>
|
|
|
|
|
<arg name="fd" type="fd"/>
|
|
|
|
|
</event>
|
|
|
|
|
|
2012-01-19 08:17:23 +08:00
|
|
|
<event name="cancelled">
|
|
|
|
|
<description summary="selection was cancelled">
|
|
|
|
|
Another selection became active.
|
|
|
|
|
</description>
|
|
|
|
|
</event>
|
|
|
|
|
|
2011-11-15 21:58:34 +08:00
|
|
|
</interface>
|
|
|
|
|
|
|
|
|
|
<interface name="wl_data_device" version="1">
|
|
|
|
|
<request name="start_drag">
|
2012-02-15 23:02:52 +08:00
|
|
|
<description summary="start drag and drop operation">
|
|
|
|
|
This request asks the compositor to start a drag and drop
|
2012-05-29 15:58:26 +08:00
|
|
|
operation on behalf of the client.
|
|
|
|
|
|
|
|
|
|
The source argument is the data source that provides the data
|
|
|
|
|
for the eventual data transfer. If source is NULL, enter, leave
|
|
|
|
|
and motion events are sent only to the client that initiated the
|
|
|
|
|
drag and the client is expected to handle the data passing
|
|
|
|
|
internally.
|
|
|
|
|
|
|
|
|
|
The origin surface is the surface where the drag originates and
|
|
|
|
|
the client must have an active implicit grab that matches the
|
|
|
|
|
serial.
|
|
|
|
|
|
|
|
|
|
The icon surface is an optional (can be nil) surface that
|
|
|
|
|
provides an icon to be moved around with the cursor. Initially,
|
|
|
|
|
the top-left corner of the icon surface is placed at the cursor
|
|
|
|
|
hotspot, but subsequent surface.attach request can move the
|
|
|
|
|
relative position.
|
2012-02-15 23:02:52 +08:00
|
|
|
</description>
|
2012-07-02 18:03:31 +08:00
|
|
|
<arg name="source" type="object" interface="wl_data_source" allow-null="true"/>
|
2012-02-15 23:02:52 +08:00
|
|
|
<arg name="origin" type="object" interface="wl_surface"/>
|
2012-07-02 18:03:31 +08:00
|
|
|
<arg name="icon" type="object" interface="wl_surface" allow-null="true"/>
|
Switch protocol to using serial numbers for ordering events and requests
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
2012-04-12 10:25:51 +08:00
|
|
|
<arg name="serial" type="uint"/>
|
2011-11-15 21:58:34 +08:00
|
|
|
</request>
|
|
|
|
|
|
|
|
|
|
<request name="set_selection">
|
2012-07-03 02:34:48 +08:00
|
|
|
<arg name="source" type="object" interface="wl_data_source" allow-null="true"/>
|
Switch protocol to using serial numbers for ordering events and requests
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
2012-04-12 10:25:51 +08:00
|
|
|
<arg name="serial" type="uint"/>
|
2011-11-15 21:58:34 +08:00
|
|
|
</request>
|
|
|
|
|
|
|
|
|
|
<event name="data_offer">
|
2012-01-19 08:17:23 +08:00
|
|
|
<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>
|
|
|
|
|
|
2011-11-15 21:58:34 +08:00
|
|
|
<arg name="id" type="new_id" interface="wl_data_offer"/>
|
|
|
|
|
</event>
|
|
|
|
|
|
|
|
|
|
<event name="enter">
|
Switch protocol to using serial numbers for ordering events and requests
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
2012-04-12 10:25:51 +08:00
|
|
|
<arg name="serial" type="uint"/>
|
2011-11-15 21:58:34 +08:00
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
2012-05-09 00:17:26 +08:00
|
|
|
<arg name="x" type="fixed"/>
|
|
|
|
|
<arg name="y" type="fixed"/>
|
2012-07-09 18:15:20 +08:00
|
|
|
<arg name="id" type="object" interface="wl_data_offer" allow-null="true"/>
|
2011-11-15 21:58:34 +08:00
|
|
|
</event>
|
|
|
|
|
|
|
|
|
|
<event name="leave"/>
|
|
|
|
|
|
|
|
|
|
<event name="motion">
|
|
|
|
|
<arg name="time" type="uint"/>
|
2012-05-09 00:17:26 +08:00
|
|
|
<arg name="x" type="fixed"/>
|
|
|
|
|
<arg name="y" type="fixed"/>
|
2011-11-15 21:58:34 +08:00
|
|
|
</event>
|
|
|
|
|
|
|
|
|
|
<event name="drop"/>
|
|
|
|
|
|
|
|
|
|
<event name="selection">
|
2012-01-19 08:17:23 +08:00
|
|
|
<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>
|
2012-07-02 18:03:31 +08:00
|
|
|
<arg name="id" type="object" interface="wl_data_offer" allow-null="true"/>
|
2011-11-15 21:58:34 +08:00
|
|
|
</event>
|
|
|
|
|
</interface>
|
|
|
|
|
|
|
|
|
|
<interface name="wl_data_device_manager" version="1">
|
|
|
|
|
<request name="create_data_source">
|
|
|
|
|
<arg name="id" type="new_id" interface="wl_data_source"/>
|
|
|
|
|
</request>
|
|
|
|
|
|
|
|
|
|
<request name="get_data_device">
|
|
|
|
|
<arg name="id" type="new_id" interface="wl_data_device"/>
|
2012-05-17 01:44:40 +08:00
|
|
|
<arg name="seat" type="object" interface="wl_seat"/>
|
2011-11-15 21:58:34 +08:00
|
|
|
</request>
|
|
|
|
|
</interface>
|
|
|
|
|
|
2011-04-18 22:24:11 +08:00
|
|
|
<interface name="wl_shell" version="1">
|
2011-11-24 22:19:03 +08:00
|
|
|
<request name="get_shell_surface">
|
|
|
|
|
<arg name="id" type="new_id" interface="wl_shell_surface"/>
|
2011-04-18 22:24:11 +08:00
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
2011-11-24 22:19:03 +08:00
|
|
|
</request>
|
|
|
|
|
</interface>
|
|
|
|
|
|
|
|
|
|
<interface name="wl_shell_surface" version="1">
|
2012-01-19 08:17:23 +08:00
|
|
|
|
|
|
|
|
<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>
|
|
|
|
|
|
2012-04-17 01:25:39 +08:00
|
|
|
<request name="pong">
|
|
|
|
|
<description summary="respond to a ping event">
|
|
|
|
|
A client must respond to a ping event with a pong request or
|
|
|
|
|
the client may be deemed unresponsive.
|
|
|
|
|
</description>
|
|
|
|
|
<arg name="serial" type="uint"/>
|
|
|
|
|
</request>
|
|
|
|
|
|
2011-11-24 22:19:03 +08:00
|
|
|
<request name="move">
|
2012-05-17 01:44:40 +08:00
|
|
|
<arg name="seat" type="object" interface="wl_seat"/>
|
Switch protocol to using serial numbers for ordering events and requests
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
2012-04-12 10:25:51 +08:00
|
|
|
<arg name="serial" type="uint"/>
|
2010-08-03 21:26:44 +08:00
|
|
|
</request>
|
|
|
|
|
|
2011-01-22 10:57:55 +08:00
|
|
|
<enum name="resize">
|
|
|
|
|
<entry name="none" value="0"/>
|
|
|
|
|
<entry name="top" value="1"/>
|
|
|
|
|
<entry name="bottom" value="2"/>
|
|
|
|
|
<entry name="left" value="4"/>
|
|
|
|
|
<entry name="top_left" value="5"/>
|
|
|
|
|
<entry name="bottom_left" value="6"/>
|
|
|
|
|
<entry name="right" value="8"/>
|
|
|
|
|
<entry name="top_right" value="9"/>
|
|
|
|
|
<entry name="bottom_right" value="10"/>
|
|
|
|
|
</enum>
|
|
|
|
|
|
2010-08-03 21:26:44 +08:00
|
|
|
<request name="resize">
|
2012-05-17 01:44:40 +08:00
|
|
|
<arg name="seat" type="object" interface="wl_seat"/>
|
Switch protocol to using serial numbers for ordering events and requests
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
2012-04-12 10:25:51 +08:00
|
|
|
<arg name="serial" type="uint"/>
|
2010-08-03 21:26:44 +08:00
|
|
|
<arg name="edges" type="uint"/>
|
|
|
|
|
</request>
|
|
|
|
|
|
2012-01-19 08:17:23 +08:00
|
|
|
<request name="set_toplevel">
|
|
|
|
|
<description summary="make the surface a top level surface">
|
|
|
|
|
Make the surface a toplevel window.
|
|
|
|
|
</description>
|
|
|
|
|
</request>
|
|
|
|
|
|
2012-05-21 21:47:44 +08:00
|
|
|
<enum name="transient">
|
|
|
|
|
<entry name="inactive" value="0x1" summary="do not set keyboard focus"/>
|
|
|
|
|
</enum>
|
|
|
|
|
|
2011-06-18 20:17:40 +08:00
|
|
|
<request name="set_transient">
|
2012-01-19 08:17:23 +08:00
|
|
|
<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>
|
|
|
|
|
|
2012-06-27 22:30:08 +08:00
|
|
|
<arg name="parent" type="object" interface="wl_surface"/>
|
2011-06-18 20:17:40 +08:00
|
|
|
<arg name="x" type="int"/>
|
|
|
|
|
<arg name="y" type="int"/>
|
|
|
|
|
<arg name="flags" type="uint"/>
|
|
|
|
|
</request>
|
|
|
|
|
|
2012-01-19 08:17:23 +08:00
|
|
|
<request name="set_fullscreen">
|
|
|
|
|
<description summary="make the surface a fullscreen surface">
|
2012-02-29 00:48:26 +08:00
|
|
|
Map the surface as a fullscreen surface. If an output parameter is
|
|
|
|
|
given then the surface will be made fullscreen on that output. If the
|
|
|
|
|
client does not specify the output then the compositor will apply its
|
|
|
|
|
policy - usually choosing the output on which the surface has the
|
|
|
|
|
biggest surface area.
|
|
|
|
|
|
|
|
|
|
The client may specify a method to resolve a size conflict between the
|
|
|
|
|
output size and the surface size - this is provided through the
|
|
|
|
|
fullscreen_method parameter.
|
|
|
|
|
|
|
|
|
|
The framerate parameter is used only when the fullscreen_method is set
|
|
|
|
|
to "driver", to indicate the preferred framerate. framerate=0 indicates
|
2012-05-11 02:13:05 +08:00
|
|
|
that the app does not care about framerate. The framerate is
|
|
|
|
|
specified in mHz, that is framerate of 60000 is 60Hz.
|
2012-02-29 00:48:26 +08:00
|
|
|
|
|
|
|
|
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.
|
2012-01-19 08:17:23 +08:00
|
|
|
</description>
|
2012-02-07 13:39:36 +08:00
|
|
|
<arg name="method" type="uint"/>
|
|
|
|
|
<arg name="framerate" type="uint"/>
|
2012-07-02 18:03:31 +08:00
|
|
|
<arg name="output" type="object" interface="wl_output" allow-null="true"/>
|
2012-01-19 08:17:23 +08:00
|
|
|
</request>
|
|
|
|
|
|
2012-02-07 13:39:36 +08:00
|
|
|
<enum name="fullscreen_method">
|
|
|
|
|
<description summary="different method to set the surface fullscreen">
|
2012-02-29 00:48:26 +08:00
|
|
|
Hints to indicate compositor how to deal with a conflict between the
|
|
|
|
|
dimensions for the surface and the dimensions of the output. As a hint
|
|
|
|
|
the compositor is free to ignore this parameter.
|
|
|
|
|
|
|
|
|
|
"default" The client has no preference on fullscreen behavior,
|
|
|
|
|
policies are determined by compositor.
|
|
|
|
|
|
|
|
|
|
"scale" The client prefers scaling by the compositor. Scaling would
|
|
|
|
|
always preserve surface's aspect ratio with surface centered on the
|
|
|
|
|
output
|
|
|
|
|
|
|
|
|
|
"driver" The client wants to switch video mode to the smallest mode
|
|
|
|
|
that can fit the client buffer. If the sizes do not match the
|
|
|
|
|
compositor must add black borders.
|
|
|
|
|
|
|
|
|
|
"fill" The surface is centered on the output on the screen with no
|
|
|
|
|
scaling. If the surface is of insufficient size the compositor must
|
|
|
|
|
add black borders.
|
2012-02-07 13:39:36 +08:00
|
|
|
</description>
|
|
|
|
|
<entry name="default" value="0"/>
|
|
|
|
|
<entry name="scale" value="1"/>
|
|
|
|
|
<entry name="driver" value="2"/>
|
|
|
|
|
<entry name="fill" value="3"/>
|
|
|
|
|
</enum>
|
|
|
|
|
|
2012-01-05 21:50:25 +08:00
|
|
|
<request name="set_popup">
|
2012-01-19 08:17:23 +08:00
|
|
|
<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>
|
|
|
|
|
|
2012-05-17 01:44:40 +08:00
|
|
|
<arg name="seat" type="object" interface="wl_seat"/>
|
Switch protocol to using serial numbers for ordering events and requests
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
2012-04-12 10:25:51 +08:00
|
|
|
<arg name="serial" type="uint"/>
|
2012-06-27 22:30:08 +08:00
|
|
|
<arg name="parent" type="object" interface="wl_surface"/>
|
2012-01-05 21:50:25 +08:00
|
|
|
<arg name="x" type="int"/>
|
|
|
|
|
<arg name="y" type="int"/>
|
|
|
|
|
<arg name="flags" type="uint"/>
|
|
|
|
|
</request>
|
|
|
|
|
|
2012-02-07 09:38:10 +08:00
|
|
|
<request name="set_maximized">
|
|
|
|
|
<description summary="make the surface a maximized surface">
|
|
|
|
|
A request from the client to notify the compositor the maximized
|
|
|
|
|
operation. The compositor will reply with a configure event telling
|
|
|
|
|
the expected new surface size. The operation is completed on the
|
|
|
|
|
next buffer attach to this surface.
|
|
|
|
|
A maximized client will fill the fullscreen of the output it is bound
|
|
|
|
|
to, except the panel area. This is the main difference between
|
|
|
|
|
a maximized shell surface and a fullscreen shell surface.
|
|
|
|
|
</description>
|
2012-07-02 18:03:31 +08:00
|
|
|
<arg name="output" type="object" interface="wl_output" allow-null="true"/>
|
2012-02-07 09:38:10 +08:00
|
|
|
</request>
|
|
|
|
|
|
2012-05-02 21:39:17 +08:00
|
|
|
<request name="set_title">
|
|
|
|
|
<description summary="set surface title">
|
|
|
|
|
</description>
|
|
|
|
|
<arg name="title" type="string"/>
|
|
|
|
|
</request>
|
|
|
|
|
|
|
|
|
|
<request name="set_class">
|
|
|
|
|
<description summary="set surface class">
|
|
|
|
|
The surface class identifies the general class of applications
|
|
|
|
|
to which the surface belongs. The class is the file name of
|
|
|
|
|
the applications .desktop file (absolute path if non-standard
|
|
|
|
|
location).
|
|
|
|
|
</description>
|
2012-05-04 03:41:50 +08:00
|
|
|
<arg name="class_" type="string"/>
|
2012-05-02 21:39:17 +08:00
|
|
|
</request>
|
|
|
|
|
|
2012-05-02 01:50:23 +08:00
|
|
|
<event name="ping">
|
|
|
|
|
<description summary="ping client">
|
|
|
|
|
Ping a client to check if it is receiving events and sending
|
|
|
|
|
requests. A client is expected to reply with a pong request.
|
|
|
|
|
</description>
|
|
|
|
|
<arg name="serial" type="uint"/>
|
|
|
|
|
</event>
|
|
|
|
|
|
2010-08-03 21:26:44 +08:00
|
|
|
<event name="configure">
|
2012-01-19 08:17:23 +08:00
|
|
|
<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>
|
|
|
|
|
|
2010-12-17 22:53:12 +08:00
|
|
|
<arg name="edges" type="uint"/>
|
2010-08-03 21:26:44 +08:00
|
|
|
<arg name="width" type="int"/>
|
|
|
|
|
<arg name="height" type="int"/>
|
|
|
|
|
</event>
|
2012-01-05 21:50:25 +08:00
|
|
|
|
2012-01-19 08:17:23 +08:00
|
|
|
<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>
|
2010-08-03 21:26:44 +08:00
|
|
|
</interface>
|
2010-08-18 09:23:10 +08:00
|
|
|
|
2011-04-18 22:24:11 +08:00
|
|
|
<interface name="wl_surface" version="1">
|
2012-01-19 08:17:23 +08:00
|
|
|
<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>
|
2010-08-03 21:26:44 +08:00
|
|
|
|
|
|
|
|
<request name="attach">
|
2012-01-19 08:17:23 +08:00
|
|
|
<description summary="set the surface contents">
|
|
|
|
|
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.
|
|
|
|
|
</description>
|
|
|
|
|
|
2012-07-03 02:34:48 +08:00
|
|
|
<arg name="buffer" type="object" interface="wl_buffer" allow-null="true"/>
|
2010-08-03 21:26:44 +08:00
|
|
|
<arg name="x" type="int"/>
|
|
|
|
|
<arg name="y" type="int"/>
|
|
|
|
|
</request>
|
|
|
|
|
|
|
|
|
|
<request name="damage">
|
2012-01-19 08:17:23 +08:00
|
|
|
<description summary="mark part of the surface damaged">
|
|
|
|
|
After attaching a new buffer, this request is used to describe
|
|
|
|
|
the regions where the new buffer is different from the
|
|
|
|
|
previous buffer and needs to be repainted. Coordinates are
|
|
|
|
|
relative to the new buffer.
|
|
|
|
|
</description>
|
|
|
|
|
|
2010-08-03 21:26:44 +08:00
|
|
|
<arg name="x" type="int"/>
|
|
|
|
|
<arg name="y" type="int"/>
|
|
|
|
|
<arg name="width" type="int"/>
|
|
|
|
|
<arg name="height" type="int"/>
|
|
|
|
|
</request>
|
2011-07-30 10:51:22 +08:00
|
|
|
|
|
|
|
|
<request name="frame">
|
2012-01-19 08:17:23 +08:00
|
|
|
<description summary="request repaint feedback">
|
|
|
|
|
Request notification when the next frame is displayed. Useful
|
|
|
|
|
for throttling redrawing operations, and driving animations.
|
|
|
|
|
The notification will only be posted for one frame unless
|
|
|
|
|
requested again.
|
|
|
|
|
</description>
|
|
|
|
|
|
2011-07-30 10:51:22 +08:00
|
|
|
<arg name="callback" type="new_id" interface="wl_callback"/>
|
|
|
|
|
</request>
|
|
|
|
|
|
2012-02-24 03:50:06 +08:00
|
|
|
<request name="set_opaque_region">
|
|
|
|
|
<description summary="set opaque region">
|
|
|
|
|
This requests sets the region of the surface that contain
|
|
|
|
|
opaque content. The opaque region is an optimization hint for
|
|
|
|
|
the compositor that lets it optimize out redrawing of content
|
|
|
|
|
behind opaque regions. Setting an opaque region is not
|
|
|
|
|
required for correct behaviour, but marking transparent
|
|
|
|
|
content as opaque will result in repaint artifacts.
|
|
|
|
|
|
|
|
|
|
The region will be clipped to the extents of the current
|
|
|
|
|
surface size. Setting the region has copy semantics, and the
|
|
|
|
|
region object can be destroyed immediately after setting the
|
|
|
|
|
opaque region. If a buffer of a different size is attached or
|
|
|
|
|
if a nil region is set, the opaque region will revert back to
|
|
|
|
|
default. The default opaque region is empty.
|
|
|
|
|
</description>
|
|
|
|
|
|
|
|
|
|
<arg name="region" type="object" interface="wl_region"/>
|
|
|
|
|
</request>
|
|
|
|
|
|
|
|
|
|
<request name="set_input_region">
|
|
|
|
|
<description summary="set input region">
|
|
|
|
|
This requests sets the region of the surface that can receive
|
|
|
|
|
pointer and touch events. The region will be clipped to the
|
|
|
|
|
extents of the current surface size. Setting the region has
|
|
|
|
|
copy semantics, and the region object can be destroyed
|
|
|
|
|
immediately after setting the input region. If a buffer of a
|
|
|
|
|
different size is attached or if a nil region is passed, the
|
|
|
|
|
input region will revert back to default. The default input
|
|
|
|
|
region is the entire surface.
|
|
|
|
|
</description>
|
|
|
|
|
|
2012-07-02 18:03:31 +08:00
|
|
|
<arg name="region" type="object" interface="wl_region" allow-null="true"/>
|
2012-02-24 03:50:06 +08:00
|
|
|
</request>
|
2012-04-18 05:22:45 +08:00
|
|
|
|
|
|
|
|
<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.
|
|
|
|
|
</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>
|
2010-08-03 21:26:44 +08:00
|
|
|
</interface>
|
|
|
|
|
|
2012-05-17 01:44:40 +08:00
|
|
|
<interface name="wl_seat" version="1">
|
|
|
|
|
<description summary="seat">
|
|
|
|
|
A group of keyboards, pointer (mice, for example) 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.
|
2012-01-19 08:17:23 +08:00
|
|
|
</description>
|
|
|
|
|
|
2012-05-17 01:44:40 +08:00
|
|
|
<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="wl_pointer"/>
|
|
|
|
|
<entry name="keyboard" value="2" summary="wl_keyboard"/>
|
|
|
|
|
<entry name="touch" value="4" summary="wl_touch"/>
|
|
|
|
|
</enum>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<event name="capabilities">
|
|
|
|
|
<description summary="seat capabilities changed">
|
|
|
|
|
This is emitted whenever a seat gains or loses the pointer,
|
|
|
|
|
keyboard or touch capabilities. The argument is a wl_seat_caps_mask
|
|
|
|
|
enum containing the complete set of capabilities this seat has.
|
|
|
|
|
</description>
|
|
|
|
|
<arg name="capabilities" type="uint"/>
|
|
|
|
|
</event>
|
|
|
|
|
|
|
|
|
|
<request name="get_pointer">
|
|
|
|
|
<description summary="return pointer object">
|
|
|
|
|
The ID provided will be initialized to the wl_pointer interface
|
|
|
|
|
for this seat.
|
|
|
|
|
</description>
|
|
|
|
|
<arg name="id" type="new_id" interface="wl_pointer"/>
|
|
|
|
|
</request>
|
|
|
|
|
|
|
|
|
|
<request name="get_keyboard">
|
|
|
|
|
<description summary="return pointer object">
|
|
|
|
|
The ID provided will be initialized to the wl_keyboard interface
|
|
|
|
|
for this seat.
|
|
|
|
|
</description>
|
|
|
|
|
<arg name="id" type="new_id" interface="wl_keyboard"/>
|
|
|
|
|
</request>
|
|
|
|
|
|
|
|
|
|
<request name="get_touch">
|
|
|
|
|
<description summary="return pointer object">
|
|
|
|
|
The ID provided will be initialized to the wl_touch interface
|
|
|
|
|
for this seat.
|
|
|
|
|
</description>
|
|
|
|
|
<arg name="id" type="new_id" interface="wl_touch"/>
|
|
|
|
|
</request>
|
|
|
|
|
</interface>
|
|
|
|
|
|
|
|
|
|
<interface name="wl_pointer" version="1">
|
2012-06-15 22:27:32 +08:00
|
|
|
<request name="set_cursor">
|
|
|
|
|
<description summary="set the pointer surface">
|
|
|
|
|
Set the pointer surface, i.e., the surface that contains the
|
|
|
|
|
pointer image. This request only takes effect if the pointer
|
2012-06-28 23:08:03 +08:00
|
|
|
focus for this device is one of the requesting client surfaces
|
|
|
|
|
or the surface parameter is the current pointer surface. If
|
|
|
|
|
there was a previous surface set with this request it is
|
2012-06-15 22:27:32 +08:00
|
|
|
replaced. If surface is NULL, the pointer image is hidden.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
On surface.attach requests to the pointer surface, hotspot_x
|
|
|
|
|
and hotspot_y are decremented by the x and y parameters
|
|
|
|
|
passed to the request.
|
|
|
|
|
|
|
|
|
|
The hotspot can also be updated by passing the current set
|
|
|
|
|
pointer surface to this request with new values for hotspot_x
|
|
|
|
|
and/or hotspot_y.
|
2012-01-19 08:17:23 +08:00
|
|
|
</description>
|
|
|
|
|
|
Switch protocol to using serial numbers for ordering events and requests
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
2012-04-12 10:25:51 +08:00
|
|
|
<arg name="serial" type="uint"/>
|
2012-07-02 18:03:31 +08:00
|
|
|
<arg name="surface" type="object" interface="wl_surface" allow-null="true"/>
|
2010-08-16 22:38:29 +08:00
|
|
|
<arg name="hotspot_x" type="int"/>
|
|
|
|
|
<arg name="hotspot_y" type="int"/>
|
|
|
|
|
</request>
|
|
|
|
|
|
2012-05-17 01:44:40 +08:00
|
|
|
<event name="enter">
|
|
|
|
|
<description summary="enter event">
|
|
|
|
|
Notification that this seat's pointer is focused on a certain
|
|
|
|
|
surface. When an seat's focus enters a surface, the pointer image
|
|
|
|
|
is undefined and a client should respond to this event by setting
|
|
|
|
|
an appropriate pointer image.
|
|
|
|
|
</description>
|
|
|
|
|
|
|
|
|
|
<arg name="serial" type="uint"/>
|
|
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
|
|
|
|
<arg name="surface_x" type="fixed"/>
|
|
|
|
|
<arg name="surface_y" type="fixed"/>
|
|
|
|
|
</event>
|
|
|
|
|
|
|
|
|
|
<event name="leave">
|
|
|
|
|
<description summary="leave event">
|
|
|
|
|
</description>
|
|
|
|
|
<arg name="serial" type="uint"/>
|
|
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
|
|
|
|
</event>
|
|
|
|
|
|
2010-08-03 21:26:44 +08:00
|
|
|
<event name="motion">
|
2012-01-19 08:17:23 +08:00
|
|
|
<description summary="pointer motion event">
|
2012-02-14 17:00:12 +08:00
|
|
|
Notification of pointer location change. The arguments surface_[xy]
|
|
|
|
|
are the location relative to the focused surface.
|
2012-01-19 08:17:23 +08:00
|
|
|
</description>
|
|
|
|
|
|
2010-08-03 21:26:44 +08:00
|
|
|
<arg name="time" type="uint"/>
|
2012-05-09 00:17:26 +08:00
|
|
|
<arg name="surface_x" type="fixed"/>
|
|
|
|
|
<arg name="surface_y" type="fixed"/>
|
2010-08-03 21:26:44 +08:00
|
|
|
</event>
|
|
|
|
|
|
2012-05-30 23:31:48 +08:00
|
|
|
<enum name="button_state">
|
|
|
|
|
<description summary="physical button state">
|
|
|
|
|
Describes the physical state of a button which provoked the button
|
|
|
|
|
event.
|
|
|
|
|
</description>
|
|
|
|
|
<entry name="released" value="0" summary="button is not pressed"/>
|
|
|
|
|
<entry name="pressed" value="1" summary="button is pressed"/>
|
|
|
|
|
</enum>
|
|
|
|
|
|
2010-08-03 21:26:44 +08:00
|
|
|
<event name="button">
|
2012-01-19 08:17:23 +08:00
|
|
|
<description summary="pointer button event">
|
|
|
|
|
Mouse button click and release notifications. The location
|
|
|
|
|
of the click is given by the last motion or pointer_focus event.
|
|
|
|
|
</description>
|
|
|
|
|
|
Switch protocol to using serial numbers for ordering events and requests
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
2012-04-12 10:25:51 +08:00
|
|
|
<arg name="serial" type="uint"/>
|
2010-08-03 21:26:44 +08:00
|
|
|
<arg name="time" type="uint"/>
|
|
|
|
|
<arg name="button" type="uint"/>
|
|
|
|
|
<arg name="state" type="uint"/>
|
|
|
|
|
</event>
|
|
|
|
|
|
2012-03-20 23:10:18 +08:00
|
|
|
<enum name="axis">
|
|
|
|
|
<description summary="axis types"/>
|
|
|
|
|
<entry name="vertical_scroll" value="0"/>
|
|
|
|
|
<entry name="horizontal_scroll" value="1"/>
|
|
|
|
|
</enum>
|
|
|
|
|
|
|
|
|
|
<event name="axis">
|
|
|
|
|
<description summary="axis event">
|
|
|
|
|
Scroll and other axis notifications.
|
|
|
|
|
</description>
|
|
|
|
|
|
|
|
|
|
<arg name="time" type="uint"/>
|
|
|
|
|
<arg name="axis" type="uint"/>
|
2012-05-30 23:31:49 +08:00
|
|
|
<arg name="value" type="fixed"/>
|
2012-03-20 23:10:18 +08:00
|
|
|
</event>
|
2012-05-17 01:44:40 +08:00
|
|
|
</interface>
|
2012-03-20 23:10:18 +08:00
|
|
|
|
2012-05-17 01:44:40 +08:00
|
|
|
<interface name="wl_keyboard" version="1">
|
|
|
|
|
<description summary="keyboard input device">
|
|
|
|
|
</description>
|
2012-01-19 08:17:23 +08:00
|
|
|
|
2012-06-01 19:13:37 +08:00
|
|
|
<enum name="keymap_format">
|
|
|
|
|
<description summary="keyboard mapping format">
|
|
|
|
|
This enum specifies the format of the keymap provided to the client
|
|
|
|
|
with the wl_keyboard::keymap event.
|
|
|
|
|
</description>
|
|
|
|
|
<entry name="xkb_v1" value="1" description="libxkbcommon compatible"/>
|
|
|
|
|
</enum>
|
|
|
|
|
|
|
|
|
|
<event name="keymap">
|
|
|
|
|
<description summary="keyboard mapping">
|
|
|
|
|
This event provides a file descriptor to the client which can be
|
|
|
|
|
memory-mapped to provide a keyboard mapping description.
|
|
|
|
|
</description>
|
|
|
|
|
<arg name="format" type="uint"/>
|
|
|
|
|
<arg name="fd" type="fd"/>
|
|
|
|
|
<arg name="size" type="uint"/>
|
|
|
|
|
</event>
|
|
|
|
|
|
2012-05-17 01:44:40 +08:00
|
|
|
<event name="enter">
|
Switch protocol to using serial numbers for ordering events and requests
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
2012-04-12 10:25:51 +08:00
|
|
|
<arg name="serial" type="uint"/>
|
2012-05-17 01:44:40 +08:00
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
|
|
|
|
<arg name="keys" type="array"/>
|
2010-08-03 21:26:44 +08:00
|
|
|
</event>
|
|
|
|
|
|
2012-05-17 01:44:40 +08:00
|
|
|
<event name="leave">
|
Switch protocol to using serial numbers for ordering events and requests
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
2012-04-12 10:25:51 +08:00
|
|
|
<arg name="serial" type="uint"/>
|
2011-04-18 22:24:11 +08:00
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
2010-08-03 21:26:44 +08:00
|
|
|
</event>
|
|
|
|
|
|
2012-05-30 23:31:48 +08:00
|
|
|
<enum name="key_state">
|
|
|
|
|
<description summary="physical key state">
|
|
|
|
|
Describes the physical state of a key which provoked the key event.
|
|
|
|
|
</description>
|
|
|
|
|
<entry name="released" value="0" summary="key is not pressed"/>
|
|
|
|
|
<entry name="pressed" value="1" summary="key is pressed"/>
|
|
|
|
|
</enum>
|
|
|
|
|
|
2012-05-17 01:44:40 +08:00
|
|
|
<event name="key">
|
|
|
|
|
<description summary="key event">
|
|
|
|
|
A key was pressed or released.
|
2012-02-18 14:25:44 +08:00
|
|
|
</description>
|
|
|
|
|
|
Switch protocol to using serial numbers for ordering events and requests
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
2012-04-12 10:25:51 +08:00
|
|
|
<arg name="serial" type="uint"/>
|
2012-05-17 01:44:40 +08:00
|
|
|
<arg name="time" type="uint"/>
|
|
|
|
|
<arg name="key" type="uint"/>
|
|
|
|
|
<arg name="state" type="uint"/>
|
2010-08-03 21:26:44 +08:00
|
|
|
</event>
|
2012-05-30 23:31:47 +08:00
|
|
|
|
|
|
|
|
<event name="modifiers">
|
|
|
|
|
<description summary="modifier and group state">
|
|
|
|
|
Notifies clients that the modifier and/or group state has
|
|
|
|
|
changed, and it should update its local state.
|
|
|
|
|
</description>
|
|
|
|
|
|
|
|
|
|
<arg name="serial" type="uint"/>
|
|
|
|
|
<arg name="mods_depressed" type="uint"/>
|
|
|
|
|
<arg name="mods_latched" type="uint"/>
|
|
|
|
|
<arg name="mods_locked" type="uint"/>
|
|
|
|
|
<arg name="group" type="uint"/>
|
|
|
|
|
</event>
|
2012-05-17 01:44:40 +08:00
|
|
|
</interface>
|
2011-06-29 22:54:11 +08:00
|
|
|
|
2012-05-17 01:44:40 +08:00
|
|
|
<interface name="wl_touch" version="1">
|
|
|
|
|
<description summary="touch screen input device">
|
|
|
|
|
</description>
|
2012-02-18 14:25:44 +08:00
|
|
|
|
2012-05-17 01:44:40 +08:00
|
|
|
<event name="down">
|
Switch protocol to using serial numbers for ordering events and requests
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
2012-04-12 10:25:51 +08:00
|
|
|
<arg name="serial" type="uint"/>
|
2011-06-29 22:54:11 +08:00
|
|
|
<arg name="time" type="uint"/>
|
2011-12-22 01:34:08 +08:00
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
2011-06-29 22:54:11 +08:00
|
|
|
<arg name="id" type="int" />
|
2012-05-09 00:17:26 +08:00
|
|
|
<arg name="x" type="fixed" />
|
|
|
|
|
<arg name="y" type="fixed" />
|
2011-06-29 22:54:11 +08:00
|
|
|
</event>
|
|
|
|
|
|
2012-05-17 01:44:40 +08:00
|
|
|
<event name="up">
|
Switch protocol to using serial numbers for ordering events and requests
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
2012-04-12 10:25:51 +08:00
|
|
|
<arg name="serial" type="uint"/>
|
2011-06-29 22:54:11 +08:00
|
|
|
<arg name="time" type="uint"/>
|
|
|
|
|
<arg name="id" type="int" />
|
|
|
|
|
</event>
|
|
|
|
|
|
2012-05-17 01:44:40 +08:00
|
|
|
<event name="motion">
|
2011-06-29 22:54:11 +08:00
|
|
|
<arg name="time" type="uint"/>
|
|
|
|
|
<arg name="id" type="int" />
|
2012-05-09 00:17:26 +08:00
|
|
|
<arg name="x" type="fixed" />
|
|
|
|
|
<arg name="y" type="fixed" />
|
2011-06-29 22:54:11 +08:00
|
|
|
</event>
|
|
|
|
|
|
2012-05-17 01:44:40 +08:00
|
|
|
<event name="frame">
|
2012-01-19 08:17:23 +08:00
|
|
|
<description summary="end of touch frame event">
|
|
|
|
|
Indicates the end of a contact point list.
|
|
|
|
|
</description>
|
|
|
|
|
</event>
|
2011-06-29 22:54:11 +08:00
|
|
|
|
2012-05-17 01:44:40 +08:00
|
|
|
<event name="cancel">
|
2012-01-19 08:17:23 +08:00
|
|
|
<description summary="touch session cancelled">
|
|
|
|
|
Sent if the compositor decides the touch stream is a global
|
|
|
|
|
gesture. No further events are sent to the clients from that
|
|
|
|
|
particular gesture.
|
|
|
|
|
</description>
|
|
|
|
|
</event>
|
2010-08-03 21:26:44 +08:00
|
|
|
</interface>
|
|
|
|
|
|
2010-11-30 03:05:26 +08:00
|
|
|
|
2011-04-18 22:24:11 +08:00
|
|
|
<interface name="wl_output" version="1">
|
2012-01-24 23:49:28 +08:00
|
|
|
<description summary="compositor output region">
|
2012-01-19 08:17:23 +08:00
|
|
|
An output describes part of the compositor geometry. The
|
|
|
|
|
compositor work in the 'compositor coordinate system' and an
|
|
|
|
|
output corresponds to rectangular area in that space that is
|
|
|
|
|
actually visible. This typically corresponds to a monitor that
|
|
|
|
|
displays part of the compositor space. This object is published
|
|
|
|
|
as global during start up, or when a screen is hot plugged.
|
|
|
|
|
</description>
|
2011-06-21 08:34:55 +08:00
|
|
|
|
|
|
|
|
<enum name="subpixel">
|
|
|
|
|
<entry name="unknown" value="0"/>
|
|
|
|
|
<entry name="none" value="1"/>
|
|
|
|
|
<entry name="horizontal_rgb" value="2"/>
|
|
|
|
|
<entry name="horizontal_bgr" value="3"/>
|
|
|
|
|
<entry name="vertical_rgb" value="4"/>
|
|
|
|
|
<entry name="vertical_bgr" value="5"/>
|
|
|
|
|
</enum>
|
|
|
|
|
|
2012-07-23 03:46:16 +08:00
|
|
|
<enum name="transform">
|
|
|
|
|
<description summary="transform from framebuffer to output">
|
|
|
|
|
This describes the transform that a compositor will apply to a
|
|
|
|
|
surface to compensate for the rotation or mirroring of an
|
|
|
|
|
output device.
|
|
|
|
|
|
|
|
|
|
The flipped values correspond to an initial flip around a
|
2012-08-16 14:04:27 +08:00
|
|
|
vertical axis followed by rotation.
|
2012-07-23 03:46:16 +08:00
|
|
|
|
|
|
|
|
The purpose is mainly to allow clients render accordingly and
|
|
|
|
|
tell the compositor, so that for fullscreen surfaces, the
|
|
|
|
|
compositor will still be able to scan out directly from client
|
|
|
|
|
surfaces.
|
|
|
|
|
</description>
|
|
|
|
|
|
|
|
|
|
<entry name="normal" value="0"/>
|
|
|
|
|
<entry name="90" value="1"/>
|
|
|
|
|
<entry name="180" value="2"/>
|
|
|
|
|
<entry name="270" value="3"/>
|
|
|
|
|
<entry name="flipped" value="4"/>
|
|
|
|
|
<entry name="flipped_90" value="5"/>
|
|
|
|
|
<entry name="flipped_180" value="6"/>
|
|
|
|
|
<entry name="flipped_270" value="7"/>
|
|
|
|
|
</enum>
|
|
|
|
|
|
2010-08-03 21:26:44 +08:00
|
|
|
<event name="geometry">
|
2012-05-10 23:56:39 +08:00
|
|
|
<description summary="properties of the output"/>
|
|
|
|
|
<arg name="x" type="int"
|
|
|
|
|
summary="x position within the global compositor space"/>
|
|
|
|
|
<arg name="y" type="int"
|
|
|
|
|
summary="y position within the global compositor space"/>
|
|
|
|
|
<arg name="physical_width" type="int"
|
2012-07-09 21:50:39 +08:00
|
|
|
summary="width in millimeters of the output"/>
|
2012-05-10 23:56:39 +08:00
|
|
|
<arg name="physical_height" type="int"
|
2012-07-09 21:50:39 +08:00
|
|
|
summary="height in millimeters of the output"/>
|
2012-05-10 23:56:39 +08:00
|
|
|
<arg name="subpixel" type="int"
|
|
|
|
|
summary="subpixel orientation of the output"/>
|
|
|
|
|
<arg name="make" type="string"
|
|
|
|
|
summary="textual description of the manufacturer"/>
|
|
|
|
|
<arg name="model" type="string"
|
|
|
|
|
summary="textual description of the model"/>
|
2012-07-23 03:46:16 +08:00
|
|
|
<arg name="transform" type="int"
|
|
|
|
|
summary="transform that maps framebuffer to output"/>
|
2011-06-21 08:34:55 +08:00
|
|
|
</event>
|
|
|
|
|
|
|
|
|
|
<enum name="mode">
|
2012-01-19 08:17:23 +08:00
|
|
|
<description summary="values for the flags bitfield in the mode event"/>
|
2012-05-10 23:56:39 +08:00
|
|
|
<entry name="current" value="0x1"
|
|
|
|
|
summary="indicates this is the current mode"/>
|
|
|
|
|
<entry name="preferred" value="0x2"
|
|
|
|
|
summary="indicates this is the preferred mode"/>
|
2011-06-21 08:34:55 +08:00
|
|
|
</enum>
|
|
|
|
|
|
|
|
|
|
<event name="mode">
|
2012-05-10 23:56:39 +08:00
|
|
|
<description summary="advertise available modes for the output">
|
|
|
|
|
The mode event describes an available mode for the output.
|
|
|
|
|
The event is sent when binding to the output object and there
|
|
|
|
|
will always be one mode, the current mode. The event is sent
|
|
|
|
|
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.
|
|
|
|
|
</description>
|
|
|
|
|
<arg name="flags" type="uint" summary="mask of wl_output_mode flags"/>
|
|
|
|
|
<arg name="width" type="int" summary="width of the mode in pixels"/>
|
|
|
|
|
<arg name="height" type="int" summary="height of the mode in pixels"/>
|
|
|
|
|
<arg name="refresh" type="int" summary="vertical refresh rate in mHz"/>
|
2010-08-03 21:26:44 +08:00
|
|
|
</event>
|
|
|
|
|
</interface>
|
|
|
|
|
|
2012-02-24 03:50:06 +08:00
|
|
|
<interface name="wl_region" version="1">
|
|
|
|
|
<description summary="region interface">
|
|
|
|
|
Region.
|
|
|
|
|
</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>
|
|
|
|
|
|
2010-11-30 03:05:26 +08:00
|
|
|
</protocol>
|