On Thu, 4 May 2017 17:59:03 +0200 Wojciech Kluczka <wojciech.kluc...@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
pgpt5mDexHHut.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel