Re: API feedback for an alternate libwayland implementation tailored for ffi bindings
On Mon, 01 Jul 2019 10:14:26 + "Victor Berger" wrote: > Hi everyone, > > A few weeks ago was discussed on IRC the idea or re-using my Rust > implementation of the Wayland protocol [1] to build an alternate > implementation of the libwayland C API. This is an idea I'm > interested in, and apparently at least a few other persons are > interested as well. > > However, if I'm going to re-implement a libwayland with a C API, I'd > be willing to adapt its API, to make it more friendly to FFI bindings > (after all Rust remains the main language in which I interact with > Wayland). Breaking backwards compatibility being naturally a > nonstarter, my idea is to rather create a library exposing both the > current C API and an alternate API, under a different namespace. > > This alternate API would be specifically targeted at languages > bindings, and not meant to be used directly by C applications. I have > made a draft of such an API for client-side, with detailed comments > about the guarantees it'd provide and how it should be used on this > gist: [2]. ... > My focus would then be to implement this new API using Rust, and then > add the necessary glue code to implement the current C API on top of > it, then exposing the whole thing as a drop-in alternative to > libwayland-client.so. I leave handling the server-side API for a > later time. > > I'd like to have your feedback on this tentative API before I try to > implement it, especially from other language bindings maintainers. I > may very well have missed some important question when designing it. > > [1]: https://github.com/Smithay/wayland-rs > [2]: https://gist.github.com/vberger/417729269d15cf11c8098aff683d5c56 Hi Victor, all I can personally say at this time is that the general idea sounds fine to me. I have no off-hand reason to NAK the idea of adding new APIs to libwayland to better suit more programming languages as long as everything that already exists keeps on working at least as well as it did. The current C implementation of libwayland is not going away. I imagine distributions will be choosing which implementation they ship, so it will be up to distributions to decide when the Rust implementation is good enough (features, quality, architecture and OS support) to take into use. As long as there is a maintained distribution using the C implementation, the C implementation will remain and be maintained. I wish you success in this effort. Thanks, pq pgpKM4ZTQvvr8.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: API feedback for an alternate libwayland implementation tailored for ffi bindings
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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: API feedback for an alternate libwayland implementation tailored for ffi bindings
Hi Drew, 1 juillet 2019 21:08 "Drew DeVault" a écrit: > Hey Victor! I want to quickly thank you for all of your hard work > allowing Wayland to flourish in the Rust ecosystem, along with the rest > of the community that supports you. Thanks! > Big +1 to more implementations of the Wayland protocol. wayland-rs is a > great example of this. However, if this discussion leads to "we should > replace libwayland upstream with something like this", hard NACK from > me. Such a move would shrink the pool of contributors, deeply affect > libwayland's portability (consider for example that I, personally, work > with Wayland on RISC-V, which is not supported by Rust), and > dramatically increase complexity and churn for questionable gains. 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. Coming from my history working on wayland-rs for 4 years now, there is something I can say for sure: libwayland's current API is *not* rust-friendly. As a result, wayland-rs contains a lot of boilerplate to fit it in a reasonable way into Rust's ownership model. I've at occasions seen on #wayland maintainers for other languages formulate similar complains. 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. I'm thus proposing a tentative design of such an API, and the possibility of implementing in wayland-rs as an experiment. If this is something that people are interested in and the experiment is successful, then I can imagine two paths forward (there might be more though, my imagination is limited): - the newly designed API could be integrated into libwayland (but I expect this to require a significant refactor) - I could reasonably provide an implementation of the ffi-taylored API on top of libwayland's API (after all I'm already doing something similar with wayland-rs) This second path would mean (assuming the whole project succeeds) that users would then have 2 options: - use the current C libwayland-client, and optionally a libwayland-client-ffi built on top of it - use wayland-rs, which would directly implement libwayland-client-ffi, and provide a libwayland-client built on top of it 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". Victor ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: API feedback for an alternate libwayland implementation tailored for ffi bindings
Hey Victor! I want to quickly thank you for all of your hard work allowing Wayland to flourish in the Rust ecosystem, along with the rest of the community that supports you. Big +1 to more implementations of the Wayland protocol. wayland-rs is a great example of this. However, if this discussion leads to "we should replace libwayland upstream with something like this", hard NACK from me. Such a move would shrink the pool of contributors, deeply affect libwayland's portability (consider for example that I, personally, work with Wayland on RISC-V, which is not supported by Rust), and dramatically increase complexity and churn for questionable gains. wayland-rs: woo-hoo! libwayland RiiR: cause for forking -- Drew DeVault ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
