Table of Contents
The open-source reference implementation of Wayland protocol is split in two C libraries, libwayland-client and libwayland-server. Their main responsibility is to handle the Inter-process communication (IPC) with each other, therefore guaranteeing the protocol objects marshaling and messages synchronization.
A client uses libwayland-client to communicate with one or more wayland servers. A wl_display object is created and manages each open connection to a server. At least one wl_event_queue object is created for each wl_display, this holds events as they are received from the server until they can be processed. Multi-threading is supported by creating an additional wl_event_queue for each additional thread, each object can have it's events placed in a particular queue, so potentially a different thread could be made to handle the events for each object created.
Though some convenience functions are provided, libwayland-client is designed to allow the calling code to wait for events, so that different polling mechanisms can be used. A file descriptor is provided, when it becomes ready for reading the calling code can ask libwayland-client to read the available events from it into the wl_event_queue objects.
The library only provides low-level access to the wayland objects. Each object created by the client is represented by a wl_proxy object that this library creates. This includes the id that is actually communicated over the socket to the server, a void* data pointer that is intended to point at a client's representation of the object, and a pointer to a static wl_interface object, which is generated from the xml and identifies the object's class and can be used for introspection into the messages and events.
Messages are sent by calling wl_proxy_marshal. This will write a message to the socket, by using the message id and the wl_interface to identify the types of each argument and convert them into stream format. Most software will call type-safe wrappers generated from the xml description of the Wayland protocols. For instance the C header file generated from the xml defines the following inline function to transmit the wl_surface::attach message:
static inline void
wl_surface_attach(struct wl_surface *wl_surface, struct wl_buffer *buffer, int32_t x, int32_t y)
{
wl_proxy_marshal((struct wl_proxy *) wl_surface, WL_SURFACE_ATTACH, buffer, x, y);
}Events (messages from the server) are handled by calling a "dispatcher" callback the client stores in the wl_proxy for each event. A language binding for a string-based interpreter, such as CPython, might have a dispatcher that uses the event name from the wl_interface to identify the function to call. The default dispatcher uses the message id number to index an array of functions pointers, called a wl_listener, and the wl_interface to convert data from the stream into arguments to the function. The C header file generated from the xml defines a per-class structure that forces the function pointers to be of the correct type, for instance the wl_surface::enter event defines this pointer in the wl_surface_listener object:
struct wl_surface_listener {
void (*enter)(void *data, struct wl_surface *, struct wl_output *);
...
}
This union represents all of the argument types in the Wayland protocol wire format. The protocol implementation uses wl_argument within its marshalling machinery for dispatching messages between a client and a compositor.
See also: wl_message See also: wl_interface See also: Wire Format
A wl_array is a dynamic array that can only grow until released. It is intended for relatively small allocations whose size is variable or not known in advance. While construction of a wl_array does not require all elements to be of the same size, wl_array_for_each() does require all elements to have the same type and size.
size_t wl_array::size
size_t wl_array::alloc
void* wl_array::data
void wl_array_init(struct wl_array *array)
void wl_array_release(struct wl_array *array)
Note: Leaves the array in an invalid state.
void * wl_array_add(struct wl_array *array, size_t size)
int wl_array_copy(struct wl_array *array, struct wl_array *source)
This macro expresses a for-each iterator for wl_array. It assigns each element in the array to pos, which can then be referenced in a trailing code block. pos must be a pointer to the array element type, and all array elements must be of the same type and size.
See also: wl_list_for_each()
A wl_display object represents a client connection to a Wayland compositor. It is created with either wl_display_connect() or wl_display_connect_to_fd(). A connection is terminated using wl_display_disconnect().
A wl_display is also used as the wl_proxy for the wl_display singleton object on the compositor side.
A wl_display object handles all the data sent from and to the compositor. When a wl_proxy marshals a request, it will write its wire representation to the display's write buffer. The data is sent to the compositor when the client calls wl_display_flush().
Incoming data is handled in two steps: queueing and dispatching. In the queue step, the data coming from the display fd is interpreted and added to a queue. On the dispatch step, the handler for the incoming event set by the client on the corresponding wl_proxy is called.
A wl_display has at least one event queue, called the default queue. Clients can create additional event queues with wl_display_create_queue() and assign wl_proxy's to it. Events occurring in a particular proxy are always queued in its assigned queue. A client can ensure that a certain assumption, such as holding a lock or running from a given thread, is true when a proxy event handler is called by assigning that proxy to an event queue and making sure that this queue is only dispatched when the assumption holds.
The default queue is dispatched by calling wl_display_dispatch(). This will dispatch any events queued on the default queue and attempt to read from the display fd if it's empty. Events read are then queued on the appropriate queues according to the proxy assignment.
A user created queue is dispatched with wl_display_dispatch_queue(). This function behaves exactly the same as wl_display_dispatch() but it dispatches given queue instead of the default queue.
A real world example of event queue usage is Mesa's implementation of eglSwapBuffers() for the Wayland platform. This function might need to block until a frame callback is received, but dispatching the default queue could cause an event handler on the client to start drawing again. This problem is solved using another event queue, so that only the events handled by the EGL code are dispatched during the block.
This creates a problem where a thread dispatches a non-default queue, reading all the data from the display fd. If the application would call poll(2) after that it would block, even though there might be events queued on the default queue. Those events should be dispatched with wl_display_dispatch_pending() or wl_display_dispatch_queue_pending() before flushing and blocking.
struct wl_event_queue * wl_display_create_queue(struct wl_display *display)
struct wl_display * wl_display_connect_to_fd(int fd)
The wl_display takes ownership of the fd and will close it when the display is destroyed. The fd will also be closed in case of failure.
struct wl_display * wl_display_connect(const char *name)
Connect to the Wayland display named name. If name is NULL, its value will be replaced with the WAYLAND_DISPLAY environment variable if it is set, otherwise display "wayland-0" will be used.
If name is an absolute path, then that path is used as-is for the location of the socket at which the Wayland server is listening; no qualification inside XDG_RUNTIME_DIR is attempted.
If name is NULL and the WAYLAND_DISPLAY environment variable is set to an absolute pathname, then that pathname is used as-is for the socket in the same manner as if name held an absolute path. Support for absolute paths in name and WAYLAND_DISPLAY is present since Wayland version 1.15.
void wl_display_disconnect(struct wl_display *display)
Close the connection to display and free all resources associated with it.
int wl_display_get_fd(struct wl_display *display)
Return the file descriptor associated with a display so it can be integrated into the client's main loop.
int wl_display_roundtrip_queue(struct wl_display *display, struct wl_event_queue *queue)
This function blocks until the server has processed all currently issued requests by sending a request to the display server and waiting for a reply before returning.
This function uses wl_display_dispatch_queue() internally. It is not allowed to call this function while the thread is being prepared for reading events, and doing so will cause a dead lock.
Note: This function may dispatch other events being received on the given queue. See also: wl_display_roundtrip()
int wl_display_roundtrip(struct wl_display *display)
This function blocks until the server has processed all currently issued requests by sending a request to the display server and waiting for a reply before returning.
This function uses wl_display_dispatch_queue() internally. It is not allowed to call this function while the thread is being prepared for reading events, and doing so will cause a dead lock.
Note: This function may dispatch other events being received on the default queue.
int wl_display_read_events(struct wl_display *display)
Calling this function will result in data available on the display file descriptor being read and read events will be queued on their corresponding event queues.
Before calling this function, depending on what thread it is to be called from, wl_display_prepare_read_queue() or wl_display_prepare_read() needs to be called. See wl_display_prepare_read_queue() for more details.
When being called at a point where other threads have been prepared to read (using wl_display_prepare_read_queue() or wl_display_prepare_read()) this function will sleep until all other prepared threads have either been cancelled (using wl_display_cancel_read()) or them self entered this function. The last thread that calls this function will then read and queue events on their corresponding event queues, and finally wake up all other wl_display_read_events() calls causing them to return.
If a thread cancels a read preparation when all other threads that have prepared to read has either called wl_display_cancel_read() or wl_display_read_events(), all reader threads will return without having read any data.
To dispatch events that may have been queued, call wl_display_dispatch_pending() or wl_display_dispatch_queue_pending().
See also: wl_display_prepare_read(), wl_display_cancel_read(), wl_display_dispatch_pending(), wl_display_dispatch()
int wl_display_prepare_read_queue(struct wl_display *display, struct wl_event_queue *queue)
This function (or wl_display_prepare_read()) must be called before reading from the file descriptor using wl_display_read_events(). Calling wl_display_prepare_read_queue() announces the calling thread's intention to read and ensures that until the thread is ready to read and calls wl_display_read_events(), no other thread will read from the file descriptor. This only succeeds if the event queue is empty, and if not -1 is returned and errno set to EAGAIN.
If a thread successfully calls wl_display_prepare_read_queue(), it must either call wl_display_read_events() when it's ready or cancel the read intention by calling wl_display_cancel_read().
Use this function before polling on the display fd or integrate the fd into a toolkit event loop in a race-free way. A correct usage would be (with most error checking left out):
while (wl_display_prepare_read_queue(display, queue) != 0)
wl_display_dispatch_queue_pending(display, queue);
wl_display_flush(display);
ret = poll(fds, nfds, -1);
if (has_error(ret))
wl_display_cancel_read(display);
else
wl_display_read_events(display);
wl_display_dispatch_queue_pending(display, queue);
Here we call wl_display_prepare_read_queue(), which ensures that between returning from that call and eventually calling wl_display_read_events(), no other thread will read from the fd and queue events in our queue. If the call to wl_display_prepare_read_queue() fails, we dispatch the pending events and try again until we're successful.
The wl_display_prepare_read_queue() function doesn't acquire exclusive access to the display's fd. It only registers that the thread calling this function has intention to read from fd. When all registered readers call wl_display_read_events(), only one (at random) eventually reads and queues the events and the others are sleeping meanwhile. This way we avoid races and still can read from more threads.
See also: wl_display_cancel_read(), wl_display_read_events(), wl_display_prepare_read()
int wl_display_prepare_read(struct wl_display *display)
This function does the same thing as wl_display_prepare_read_queue() with the default queue passed as the queue.
See also: wl_display_prepare_read_queue
void wl_display_cancel_read(struct wl_display *display)
After a thread successfully called wl_display_prepare_read() it must either call wl_display_read_events() or wl_display_cancel_read(). If the threads do not follow this rule it will lead to deadlock.
See also: wl_display_prepare_read(), wl_display_read_events()
int wl_display_dispatch_queue(struct wl_display *display, struct wl_event_queue *queue)
Dispatch events on the given event queue.
If the given event queue is empty, this function blocks until there are events to be read from the display fd. Events are read and queued on the appropriate event queues. Finally, events on given event queue are dispatched. On failure -1 is returned and errno set appropriately.
In a multi threaded environment, do not manually wait using poll() (or equivalent) before calling this function, as doing so might cause a dead lock. If external reliance on poll() (or equivalent) is required, see wl_display_prepare_read_queue() of how to do so.
This function is thread safe as long as it dispatches the right queue on the right thread. It is also compatible with the multi thread event reading preparation API (see wl_display_prepare_read_queue()), and uses the equivalent functionality internally. It is not allowed to call this function while the thread is being prepared for reading events, and doing so will cause a dead lock.
It can be used as a helper function to ease the procedure of reading and dispatching events.
Note: Since Wayland 1.5 the display has an extra queue for its own events (i. e. delete_id). This queue is dispatched always, no matter what queue we passed as an argument to this function. That means that this function can return non-0 value even when it haven't dispatched any event for the given queue. See also: wl_display_dispatch(), wl_display_dispatch_pending(), wl_display_dispatch_queue_pending(), wl_display_prepare_read_queue()
int wl_display_dispatch_queue_pending(struct wl_display *display, struct wl_event_queue *queue)
Dispatch all incoming events for objects assigned to the given event queue. On failure -1 is returned and errno set appropriately. If there are no events queued, this function returns immediately.
Since: 1.0.2
int wl_display_dispatch(struct wl_display *display)
Dispatch events on the default event queue.
If the default event queue is empty, this function blocks until there are events to be read from the display fd. Events are read and queued on the appropriate event queues. Finally, events on the default event queue are dispatched. On failure -1 is returned and errno set appropriately.
In a multi threaded environment, do not manually wait using poll() (or equivalent) before calling this function, as doing so might cause a dead lock. If external reliance on poll() (or equivalent) is required, see wl_display_prepare_read_queue() of how to do so.
This function is thread safe as long as it dispatches the right queue on the right thread. It is also compatible with the multi thread event reading preparation API (see wl_display_prepare_read_queue()), and uses the equivalent functionality internally. It is not allowed to call this function while the thread is being prepared for reading events, and doing so will cause a dead lock.
Note: It is not possible to check if there are events on the queue or not. For dispatching default queue events without blocking, see wl_display_dispatch_pending(). See also: wl_display_dispatch_pending(), wl_display_dispatch_queue(), wl_display_read_events()
int wl_display_dispatch_pending(struct wl_display *display)
This function dispatches events on the main event queue. It does not attempt to read the display fd and simply returns zero if the main queue is empty, i.e., it doesn't block.
See also: wl_display_dispatch(), wl_display_dispatch_queue(), wl_display_flush()
int wl_display_get_error(struct wl_display *display)
Return the last error that occurred on the display. This may be an error sent by the server or caused by the local client.
Note: Errors are fatal. If this function returns non-zero the display can no longer be used.
uint32_t wl_display_get_protocol_error(struct wl_display *display, const struct wl_interface **interface, uint32_t *id)
int err = wl_display_get_error(display);
if (err == EPROTO) {
code = wl_display_get_protocol_error(display, &interface, &id);
handle_error(code, interface, id);
}
...
int wl_display_flush(struct wl_display *display)
Send all buffered data on the client side to the server. Clients should always call this function before blocking on input from the display fd. On success, the number of bytes sent to the server is returned. On failure, this function returns -1 and errno is set appropriately.
wl_display_flush() never blocks. It will write as much data as possible, but if all data could not be written, errno will be set to EAGAIN and -1 returned. In that case, use poll on the display file descriptor to wait for it to become writable again.
Event queues allows the events on a display to be handled in a thread-safe manner. See wl_display for details.
void wl_event_queue_destroy(struct wl_event_queue *queue)
Destroy the given event queue. Any pending event on that queue is discarded.
The wl_display object used to create the queue should not be destroyed until all event queues created with it are destroyed with this function.
A wl_interface describes the API of a protocol object defined in the Wayland protocol specification. The protocol implementation uses a wl_interface within its marshalling machinery for encoding client requests.
The name of a wl_interface is the name of the corresponding protocol interface, and version represents the version of the interface. The members method_count and event_count represent the number of methods (requests) and events in the respective wl_message members.
For example, consider a protocol interface foo, marked as version 1, with two requests and one event.
<interface name="foo" version="1"> <request name="a"></request> <request name="b"></request> <event name="c"></event> </interface>
Given two wl_message arrays foo_requests and foo_events, a wl_interface for foo might be:
struct wl_interface foo_interface = {
"foo", 1,
2, foo_requests,
1, foo_events
};
Note: The server side of the protocol may define interface implementation types that incorporate the term interface in their name. Take care to not confuse these server-side structs with a wl_interface variable whose name also ends in interface. For example, while the server may define a type struct wl_foo_interface, the client may define a struct wl_interface wl_foo_interface. See also: wl_message See also: wl_proxy See also: Interfaces See also: Versioning
On its own, an instance of struct wl_list represents the sentinel head of a doubly-linked list, and must be initialized using wl_list_init(). When empty, the list head's next and prev members point to the list head itself, otherwise next references the first element in the list, and prev refers to the last element in the list.
Use the struct wl_list type to represent both the list head and the links between elements within the list. Use wl_list_empty() to determine if the list is empty in O(1).
All elements in the list must be of the same type. The element type must have a struct wl_list member, often named link by convention. Prior to insertion, there is no need to initialize an element's link - invoking wl_list_init() on an individual list element's struct wl_list member is unnecessary if the very next operation is wl_list_insert(). However, a common idiom is to initialize an element's link prior to removal - ensure safety by invoking wl_list_init() before wl_list_remove().
Consider a list reference struct wl_list foo_list, an element type as struct element, and an element's link member as struct wl_list link.
The following code initializes a list and adds three elements to it.
struct wl_list foo_list;
struct element {
int foo;
struct wl_list link;
};
struct element e1, e2, e3;
wl_list_init(&foo_list);
wl_list_insert(&foo_list, &e1.link); // e1 is the first element
wl_list_insert(&foo_list, &e2.link); // e2 is now the first element
wl_list_insert(&e2.link, &e3.link); // insert e3 after e2
The list now looks like [e2, e3, e1].
The wl_list API provides some iterator macros. For example, to iterate a list in ascending order:
struct element *e;
wl_list_for_each(e, foo_list, link) {
do_something_with_element(e);
}
See the documentation of each iterator for details. See also: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/list.h
struct wl_list* wl_list::prev
struct wl_list* wl_list::next
void wl_list_init(struct wl_list *list)
void wl_list_insert(struct wl_list *list, struct wl_list *elm)
When list is a reference to the list itself (the head), set the containing struct of elm as the first element in the list.
Note: If elm is already part of a list, inserting it again will lead to list corruption.
void wl_list_remove(struct wl_list *elm)
Note: This operation leaves elm in an invalid state.
int wl_list_length(const struct wl_list *list)
Note: This is an O(n) operation.
int wl_list_empty(const struct wl_list *list)
void wl_list_insert_list(struct wl_list *list, struct wl_list *other)
Note: This leaves other in an invalid state.
This macro expresses a for-each iterator for wl_list. Given a list and wl_list link member name (often named link by convention), this macro assigns each element in the list to pos, which can then be referenced in a trailing code block. For example, given a wl_list of struct message elements:
struct message {
char *contents;
wl_list link;
};
struct wl_list *message_list;
// Assume message_list now "contains" many messages
struct message *m;
wl_list_for_each(m, message_list, link) {
do_something_with_message(m);
}
Note: Only removal of the current element, pos, is safe. Removing any other element during traversal may lead to a loop malfunction. See also: wl_list_for_each()
See also: wl_list_for_each()
Note: Only removal of the current element, pos, is safe. Removing any other element during traversal may lead to a loop malfunction. See also: wl_list_for_each()
A wl_message describes the signature of an actual protocol message, such as a request or event, that adheres to the Wayland protocol wire format. The protocol implementation uses a wl_message within its demarshal machinery for decoding messages between a compositor and its clients. In a sense, a wl_message is to a protocol message like a class is to an object.
The name of a wl_message is the name of the corresponding protocol message.
The signature is an ordered list of symbols representing the data types of message arguments and, optionally, a protocol version and indicators for nullability. A leading integer in the signature indicates the since version of the protocol message. A ? preceding a data type symbol indicates that the following argument type is nullable. While it is a protocol violation to send messages with non-nullable arguments set to NULL, event handlers in clients might still get called with non-nullable object arguments set to NULL. This can happen when the client destroyed the object being used as argument on its side and an event referencing that object was sent before the server knew about its destruction. As this race cannot be prevented, clients should - as a general rule - program their event handlers such that they can handle object arguments declared non-nullable being NULL gracefully.
When no arguments accompany a message, signature is an empty string.
Symbols:
While demarshaling primitive arguments is straightforward, when demarshaling messages containing object or new_id arguments, the protocol implementation often must determine the type of the object. The types of a wl_message is an array of wl_interface references that correspond to o and n arguments in signature, with NULL placeholders for arguments with non-object types.
Consider the protocol event wl_display delete_id that has a single uint argument. The wl_message is:
{ "delete_id", "u", [NULL] }
Here, the message name is "delete_id", the signature is "u", and the argument types is [NULL], indicating that the uint argument has no corresponding wl_interface since it is a primitive argument.
In contrast, consider a wl_foo interface supporting protocol request bar that has existed since version 2, and has two arguments: a uint and an object of type wl_baz_interface that may be NULL. Such a wl_message might be:
{ "bar", "2u?o", [NULL, &wl_baz_interface] }
Here, the message name is "bar", and the signature is "2u?o". Notice how the 2 indicates the protocol version, the u indicates the first argument type is uint, and the ?o indicates that the second argument is an object that may be NULL. Lastly, the argument types array indicates that no wl_interface corresponds to the first argument, while the type wl_baz_interface corresponds to the second argument.
See also: wl_argument See also: wl_interface See also: Wire Format
A wl_proxy acts as a client side proxy to an object existing in the compositor. The proxy is responsible for converting requests made by the clients with wl_proxy_marshal() into Wayland's wire format. Events coming from the compositor are also handled by the proxy, which will in turn call the handler set with wl_proxy_add_listener().
Note: With the exception of function wl_proxy_set_queue(), functions accessing a wl_proxy are not normally used by client code. Clients should normally use the higher level interface generated by the scanner to interact with compositor objects.
struct wl_proxy * wl_proxy_create(struct wl_proxy *factory, const struct wl_interface *interface)
This function creates a new proxy object with the supplied interface. The proxy object will have an id assigned from the client id space. The id should be created on the compositor side by sending an appropriate request with wl_proxy_marshal().
The proxy will inherit the display and event queue of the factory object.
Note: This should not normally be used by non-generated code. See also: wl_display, wl_event_queue, wl_proxy_marshal()
void wl_proxy_destroy(struct wl_proxy *proxy)
proxy must not be a proxy wrapper.
int wl_proxy_add_listener(struct wl_proxy *proxy, void(**implementation)(void), void *data)
Set proxy's listener to implementation and its user data to data. If a listener has already been set, this function fails and nothing is changed.
implementation is a vector of function pointers. For an opcode n, implementation[n] should point to the handler of n for the given object.
proxy must not be a proxy wrapper.
const void * wl_proxy_get_listener(struct wl_proxy *proxy)
Gets the address to the proxy's listener; which is the listener set with wl_proxy_add_listener.
This function is useful in clients with multiple listeners on the same interface to allow the identification of which code to execute.
int wl_proxy_add_dispatcher(struct wl_proxy *proxy, wl_dispatcher_func_t dispatcher, const void *implementation, void *data)
Set proxy's listener to use dispatcher_func as its dispatcher and dispatcher_data as its dispatcher-specific implementation and its user data to data. If a listener has already been set, this function fails and nothing is changed.
The exact details of dispatcher_data depend on the dispatcher used. This function is intended to be used by language bindings, not user code.
proxy must not be a proxy wrapper.
struct wl_proxy * wl_proxy_marshal_array_constructor(struct wl_proxy *proxy, uint32_t opcode, union wl_argument *args, const struct wl_interface *interface)
This function translates a request given an opcode, an interface and a wl_argument array to the wire format and writes it to the connection buffer.
For new-id arguments, this function will allocate a new wl_proxy and send the ID to the server. The new wl_proxy will be returned on success or NULL on error with errno set accordingly. The newly created proxy will inherit their version from their parent.
Note: This is intended to be used by language bindings and not in non-generated code. See also: wl_proxy_marshal()
struct wl_proxy * wl_proxy_marshal_array_constructor_versioned(struct wl_proxy *proxy, uint32_t opcode, union wl_argument *args, const struct wl_interface *interface, uint32_t version)
Translates the request given by opcode and the extra arguments into the wire format and write it to the connection buffer. This version takes an array of the union type wl_argument.
For new-id arguments, this function will allocate a new wl_proxy and send the ID to the server. The new wl_proxy will be returned on success or NULL on error with errno set accordingly. The newly created proxy will have the version specified.
Note: This is intended to be used by language bindings and not in non-generated code. See also: wl_proxy_marshal()
void wl_proxy_marshal(struct wl_proxy *proxy, uint32_t opcode,...)
This function is similar to wl_proxy_marshal_constructor(), except it doesn't create proxies for new-id arguments.
Note: This should not normally be used by non-generated code. See also: wl_proxy_create()
struct wl_proxy * wl_proxy_marshal_constructor(struct wl_proxy *proxy, uint32_t opcode, const struct wl_interface *interface,...)
This function translates a request given an opcode, an interface and extra arguments to the wire format and writes it to the connection buffer. The types of the extra arguments must correspond to the argument types of the method associated with the opcode in the interface.
For new-id arguments, this function will allocate a new wl_proxy and send the ID to the server. The new wl_proxy will be returned on success or NULL on error with errno set accordingly. The newly created proxy will inherit their version from their parent.
Note: This should not normally be used by non-generated code.
struct wl_proxy * wl_proxy_marshal_constructor_versioned(struct wl_proxy *proxy, uint32_t opcode, const struct wl_interface *interface, uint32_t version,...)
Translates the request given by opcode and the extra arguments into the wire format and write it to the connection buffer.
For new-id arguments, this function will allocate a new wl_proxy and send the ID to the server. The new wl_proxy will be returned on success or NULL on error with errno set accordingly. The newly created proxy will have the version specified.
Note: This should not normally be used by non-generated code.
void wl_proxy_marshal_array(struct wl_proxy *proxy, uint32_t opcode, union wl_argument *args)
This function is similar to wl_proxy_marshal_array_constructor(), except it doesn't create proxies for new-id arguments.
Note: This is intended to be used by language bindings and not in non-generated code. See also: wl_proxy_marshal()
void wl_proxy_set_user_data(struct wl_proxy *proxy, void *user_data)
Set the user data associated with proxy. When events for this proxy are received, user_data will be supplied to its listener.
void * wl_proxy_get_user_data(struct wl_proxy *proxy)
uint32_t wl_proxy_get_version(struct wl_proxy *proxy)
Gets the protocol object version of a proxy object, or 0 if the proxy was created with unversioned API.
A returned value of 0 means that no version information is available, so the caller must make safe assumptions about the object's real version.
wl_display's version will always return 0.
uint32_t wl_proxy_get_id(struct wl_proxy *proxy)
const char * wl_proxy_get_class(struct wl_proxy *proxy)
void wl_proxy_set_queue(struct wl_proxy *proxy, struct wl_event_queue *queue)
Assign proxy to event queue. Events coming from proxy will be queued in queue from now. If queue is NULL, then the display's default queue is set to the proxy.
Note: By default, the queue set in proxy is the one inherited from parent. See also: wl_display_dispatch_queue()
void * wl_proxy_create_wrapper(void *proxy)
A proxy wrapper is type of 'struct wl_proxy' instance that can be used when sending requests instead of using the original proxy. A proxy wrapper does not have an implementation or dispatcher, and events received on the object is still emitted on the original proxy. Trying to set an implementation or dispatcher will have no effect but result in a warning being logged.
Setting the proxy queue of the proxy wrapper will make new objects created using the proxy wrapper use the set proxy queue. Even though there is no implementation nor dispatcher, the proxy queue can be changed. This will affect the default queue of new objects created by requests sent via the proxy wrapper.
A proxy wrapper can only be destroyed using wl_proxy_wrapper_destroy().
A proxy wrapper must be destroyed before the proxy it was created from.
If a user reads and dispatches events on more than one thread, it is necessary to use a proxy wrapper when sending requests on objects when the intention is that a newly created proxy is to use a proxy queue different from the proxy the request was sent on, as creating the new proxy and then setting the queue is not thread safe.
For example, a module that runs using its own proxy queue that needs to do display roundtrip must wrap the wl_display proxy object before sending the wl_display.sync request. For example:
struct wl_event_queue *queue = ...; struct wl_display *wrapped_display; struct wl_callback *callback; wrapped_display = wl_proxy_create_wrapper(display); wl_proxy_set_queue((struct wl_proxy *) wrapped_display, queue); callback = wl_display_sync(wrapped_display); wl_proxy_wrapper_destroy(wrapped_display); wl_callback_add_listener(callback, ...);
void wl_proxy_wrapper_destroy(void *proxy_wrapper)
void wl_event_queue_destroy(struct wl_event_queue *queue)
void wl_proxy_marshal(struct wl_proxy *p, uint32_t opcode,...)
void wl_proxy_marshal_array(struct wl_proxy *p, uint32_t opcode, union wl_argument *args)
struct wl_proxy* wl_proxy_create(struct wl_proxy *factory, const struct wl_interface *interface)
void* wl_proxy_create_wrapper(void *proxy)
void wl_proxy_wrapper_destroy(void *proxy_wrapper)
struct wl_proxy* wl_proxy_marshal_constructor(struct wl_proxy *proxy, uint32_t opcode, const struct wl_interface *interface,...)
struct wl_proxy* wl_proxy_marshal_constructor_versioned(struct wl_proxy *proxy, uint32_t opcode, const struct wl_interface *interface, uint32_t version,...)
struct wl_proxy* wl_proxy_marshal_array_constructor(struct wl_proxy *proxy, uint32_t opcode, union wl_argument *args, const struct wl_interface *interface)
struct wl_proxy* wl_proxy_marshal_array_constructor_versioned(struct wl_proxy *proxy, uint32_t opcode, union wl_argument *args, const struct wl_interface *interface, uint32_t version)
void wl_proxy_destroy(struct wl_proxy *proxy)
int wl_proxy_add_listener(struct wl_proxy *proxy, void(**implementation)(void), void *data)
const void* wl_proxy_get_listener(struct wl_proxy *proxy)
int wl_proxy_add_dispatcher(struct wl_proxy *proxy, wl_dispatcher_func_t dispatcher_func, const void *dispatcher_data, void *data)
void wl_proxy_set_user_data(struct wl_proxy *proxy, void *user_data)
void* wl_proxy_get_user_data(struct wl_proxy *proxy)
uint32_t wl_proxy_get_version(struct wl_proxy *proxy)
uint32_t wl_proxy_get_id(struct wl_proxy *proxy)
const char* wl_proxy_get_class(struct wl_proxy *proxy)
void wl_proxy_set_queue(struct wl_proxy *proxy, struct wl_event_queue *queue)
struct wl_display* wl_display_connect(const char *name)
struct wl_display* wl_display_connect_to_fd(int fd)
void wl_display_disconnect(struct wl_display *display)
int wl_display_get_fd(struct wl_display *display)
int wl_display_dispatch(struct wl_display *display)
int wl_display_dispatch_queue(struct wl_display *display, struct wl_event_queue *queue)
int wl_display_dispatch_queue_pending(struct wl_display *display, struct wl_event_queue *queue)
int wl_display_dispatch_pending(struct wl_display *display)
int wl_display_get_error(struct wl_display *display)
uint32_t wl_display_get_protocol_error(struct wl_display *display, const struct wl_interface **interface, uint32_t *id)
int wl_display_flush(struct wl_display *display)
int wl_display_roundtrip_queue(struct wl_display *display, struct wl_event_queue *queue)
int wl_display_roundtrip(struct wl_display *display)
struct wl_event_queue* wl_display_create_queue(struct wl_display *display)
int wl_display_prepare_read_queue(struct wl_display *display, struct wl_event_queue *queue)
int wl_display_prepare_read(struct wl_display *display)
void wl_display_cancel_read(struct wl_display *display)
int wl_display_read_events(struct wl_display *display)
void wl_log_set_handler_client(wl_log_func_t handler)
void wl_log_set_handler_client(wl_log_func_t handler)
See also: https://gcc.gnu.org/onlinedocs/gcc-3.2.1/gcc/Function-Attributes.html
This macro allows "conversion" from a pointer to a member to its containing struct. This is useful if you have a contained item like a wl_list, wl_listener, or wl_signal, provided via a callback or other means, and would like to retrieve the struct that contains it.
To demonstrate, the following example retrieves a pointer to example_container given only its destroy_listener member:
struct example_container {
struct wl_listener destroy_listener;
// other members...
};
void example_container_destroy(struct wl_listener *listener, void *data)
{
struct example_container *ctr;
ctr = wl_container_of(listener, ctr, destroy_listener);
// destroy ctr...
}
Note: sample need not be a valid pointer. A null or uninitialised pointer is sufficient.
See also: wl_client_for_each_resource_iterator_func_t See also: wl_client_for_each_resource
typedef int32_t wl_fixed_t
A wl_fixed_t is a 24.8 signed fixed-point number with a sign bit, 23 bits of integer precision and 8 bits of decimal precision. Consider wl_fixed_t as an opaque struct with methods that facilitate conversion to and from double and int types.
typedef int(* wl_dispatcher_func_t) (const void *, void *, uint32_t, const struct wl_message *, union wl_argument *))(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
A dispatcher is a function that handles the emitting of callbacks in client code. For programs directly using the C library, this is done by using libffi to call function pointers. When binding to languages other than C, dispatchers provide a way to abstract the function calling process to be friendlier to other function calling systems.
A dispatcher takes five arguments: The first is the dispatcher-specific implementation associated with the target object. The second is the object upon which the callback is being invoked (either wl_proxy or wl_resource). The third and fourth arguments are the opcode and the wl_message corresponding to the callback. The final argument is an array of arguments received from the other process via the wire protocol.
typedef void(* wl_log_func_t) (const char *, va_list))(const char *, va_list)
The C implementation of the Wayland protocol abstracts the details of logging. Users may customize the logging behavior, with a function conforming to the wl_log_func_t type, via wl_log_set_handler_client and wl_log_set_handler_server.
A wl_log_func_t must conform to the expectations of vprintf, and expects two arguments: a string to write and a corresponding variable argument list. While the string to write may contain format specifiers and use values in the variable argument list, the behavior of any wl_log_func_t depends on the implementation.
Note: Take care to not confuse this with wl_protocol_logger_func_t, which is a specific server-side logger for requests and events.
See also: wl_log_set_handler_client See also: wl_log_set_handler_server