about weston

[Alberich de megres]

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