Skylane - implementation of Wayland in Rust

[Pekka Paalanen]

On Thu, 4 May 2017 17:59:03 +0200
Wojciech Kluczka <wojciech.kluczka at gmail.com> wrote:

> Hello,
> 
> This was supposed to be only a short announcement of Skylane -
> implementation of Wayland in Rust - but it was pointed to me that one can
> not use hardware acceleration without original libwayland so I have to also
> ask some questions.
> 
> On client side there's not much to worry about (as far as I could see) but

Hi,

sorry, you are also, if not even more, screwed on the client side.
Kristian gave you an example on how to avoid the server side libEGL
calling directly into libwayland-server.so, but also the client side
EGL/Wayland platform implementation will call directly in to
libwayland-client.so for sending requests and receiving events.

You can see it as you need to pass a struct wl_display * as
EGLNativeDisplayType and a struct wl_surface * into libwayland-egl.so
to get a struct wl_egl_window * for using as the EGLNativeWindowType.

> server has to use mesa extension which adds global object to display,
> relying on concrete implementation.
>  - I can guess but was the reason to make such dependence?

The dependency was not made by choice. It is inevitable and universal
with the usage pattern we happen to have with EGL, but it really
applies to any library.

Say you have a library libfoo, which under the hood uses libwayland.
Libwayland types also happen to be exposed in libfoo ABI, e.g. you need
to pass in a server or client side struct wl_display * in. Libfoo
cannot open its own Wayland connection, because then it could not
interoperate with its user, the application. This is because all
Wayland protocol object identities are specific and private to a
connection. You simply cannot refer to a protocol object created in
another connection.

So, all components of an application need to share the same Wayland
connection, and that is usually done by passing the wl_display around.
Protocol objects are passed around by their struct wl_proxy pointers.

As you know, the protocol IPC implementation does a fair amount of
object tracking. The protocol also relies on ordered delivery. These
two mean that one cannot really have two instances of the IPC state,
there must be only one that everything uses.

What could you do then, if you don't want to wrap the C implementation
of libwayland...

Borrowing the idea from Daniel Stone from whom I heard it first, the
only other option is to reimplement libwayland *including* its C ABI in
Rust. You need to completely throw away the C implementation of
libwayland and replace that with your own libwayland-*.so built with
Rust. Then you will get libEGL calling into your implementation and it
will be the sole implementation, which should let things work.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170505/f608723d/attachment.sig>