about weston

Alberich de megres alberich2k5 at gmail.com
Tue Apr 3 07:22:09 PDT 2012

Thanks for the clarifying :)

On Mon, Apr 2, 2012 at 12:57 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Sun, 1 Apr 2012 21:37:10 +0200
> Alberich de megres <alberich2k5 at gmail.com> wrote:
>> Hi Guys,
>> I was trying to understand how weston rpc works, and more specifically
>> how it asks for painting.
>> Checking the source i saw more or less this call stack for sending a
>> window_sync:
>> wl_display_sync
>> |->wl_proxy_marshal
>>    |->wl_closure_send
>>        |->wl_connection_write
>> on the server side, the object demarshaling is done by vmarshal
>> function, which some calls later invokes ffi_call
>> But I could not understand, the object is sended entirely? or just the
>> function-parameters pointers to be invoked remotelly?
> A protocol object has two parts in the code: some C struct containing a
> struct wl_resource at minimum on the server side, and a proxy struct on
> the client side.
> A RPC only contains the protocol object id, opcode (request or event
> id) and the arguments. The marshalling code you saw deals with all
> the data types the wire can carry.
>> if is this last case, how weston access the client memory space?
> It doesn't. A client allocates its graphics buffers in a way, that you
> can get a handle to it, pass the handle via the Wayland protocol, and
> using the handle get access to the same graphics buffer in the server.
> Unix shm is one supported buffer type, and the handle there is a file
> descriptor.
> http://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayland.xml#n154
> Thanks,
> pq

More information about the wayland-devel mailing list