API feedback for an alternate libwayland implementation tailored for ffi bindings

[Drew DeVault]

Thanks for explaining, Victor.

On Mon Jul 1, 2019 at 8:54 PM Victor Berger wrote:
> I never imagined to actually replace libwayland with wayland-rs, but I
> understand how my original message may have felt like this. Sorry for
> not being clear enough.

Phew. This came on the ends of some similar discussions in #wayland
(which I admittedly heard about secondhand) so I was worried.

> Now, I've partially solved this issue for Rust by also making a
> full-rust implementation of the Wayland protocol in wayland-rs. But as
> soon as one needs to interact with something else (notably Mesa for
> OpenGL or Vulkan), this is an immediate no-go, as Mesa and the client
> app must use pointers coming from the same Wayland implementation.

> This is why I came up with the idea of introducing an alternate API in
> libwayland, which would be more fundamental and more FFI-friendly.
> This would allow easier interop between the different languages and C
> libraries like Mesa or GTK.

Ah, the mesa problem. This makes a lot of sense. Another possible
approach would be reimplementing src/egl/drivers/dri2/platform_wayland.c
(and similar Vulkan code) in Rust - Mesa needn't be the only
implementation of the linux-dmabuf protocol. I suspect we have access to
enough mesa internals to implement it outside of mesa, but if not I
would approve of an effort to bring more of these things out into the
public API.

I think this kind of approach would fare better than extending
libwayland in this manner.

> However I have no interest in developing a Rust implementation of
> libwayland's API if I cannot use it in a better way than the C
> implementation from Rust. So if this project is not welcome, I'll just
> stick to what I have currently: "You can use the Rust implementation
> only if you don't need Vulkan, openGL, or any interop with a
> Wayland-aware system library".

Isn't the latter more of the RiiR way, anyway? ;)

-- 
Drew DeVault