mirror of
https://gitlab.freedesktop.org/wayland/wayland.git
synced 2025-11-24 06:59:50 -05:00
Describe the wire protocol
This commit is contained in:
parent
0c007aea35
commit
ebe3327003
1 changed files with 50 additions and 7 deletions
|
|
@ -59,12 +59,6 @@ an object id that uniquely identifies an object on the server. Each
|
|||
object implements an interface and the requests include an opcode that
|
||||
identifies which method in the interface to invoke.
|
||||
|
||||
The wire protocol is determined from the C prototypes of the requests
|
||||
and events. There is a straight forward mapping from the C types to
|
||||
packing the bytes in the request written to the socket. It is
|
||||
possible to map the events and requests to function calls in other
|
||||
languages, but that hasn't been done at this point.
|
||||
|
||||
The server sends back events to the client, each event is emitted from
|
||||
an object. Events can be error conditions. The event includes the
|
||||
object id and the event opcode, from which the client can determine
|
||||
|
|
@ -78,7 +72,56 @@ spontanously when the server state changes.
|
|||
no need (or mechanism) to query server state.
|
||||
|
||||
\item server will broadcast presence of a number of global objects,
|
||||
which in turn will broadcast their current state
|
||||
which in turn will broadcast their current state.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Code generation}
|
||||
|
||||
The interfaces, requests and events are defined in protocol/wayland.xml.
|
||||
This xml is used to generate the function prototypes that can be used by
|
||||
clients and compositors.
|
||||
|
||||
The protocol entry points are generated as inline functions which just
|
||||
wraps the \verb:wl_proxy_*: functions. The inline functions aren't
|
||||
part of the library ABI and languange bindings should generate their
|
||||
own stubs for the protocl entry points from the xml.
|
||||
|
||||
\subsection{Wire format}
|
||||
|
||||
The protocol is sent over a UNIX domain stream socket. Currently, the
|
||||
endpoint is named \texttt{\textbackslash0wayland}, but it is subject
|
||||
to change. The protocol is message-based. A message sent by a client
|
||||
to the server is called \texttt{request}. A message from the server
|
||||
to a client is called \texttt{event}. Every message is structured as
|
||||
32-bit words, values are represented in the host's byte-order.
|
||||
|
||||
The message header has 2 words in it:
|
||||
\begin{itemize}
|
||||
\item The first word is the sender's object id (32-bit).
|
||||
\item The second has 2 parts of 16-bit. The upper 16-bits are the message
|
||||
size in bytes, starting at the header (i.e. it has a minimum value of 8).
|
||||
The lower is the request/event opcode.
|
||||
\end{itemize}
|
||||
|
||||
The payload describes the request/event arguments. Every argument is always
|
||||
aligned to 32-bit. There is no prefix that describes the type, but it is
|
||||
inferred implicitly from the xml specification.
|
||||
|
||||
The representation of argument types are as follows:
|
||||
\begin{itemize}
|
||||
\item "int" or "uint": The value is the 32-bit value of the signed/unsigned
|
||||
int.
|
||||
\item "string": Starts with an unsigned 32-bit length, followed by the
|
||||
string contents, including terminating NUL byte, then padding to a
|
||||
32-bit boundary.
|
||||
\item "object": A 32-bit object ID.
|
||||
\item "new\_id": the 32-bit object ID. On requests, the client
|
||||
decides the ID. The only event with "new\_id" is advertisements of
|
||||
globals, and the server will use IDs below 0x10000.
|
||||
\item "array": Starts with 32-bit array size in bytes, followed by the array
|
||||
contents verbatim, and finally padding to a 32-bit boundary.
|
||||
\item "fd": the file descriptor is not stored in the message buffer, but in
|
||||
the ancillary data of the UNIX domain socket message (msg\_control).
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Connect Time}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue