Skylane - implementation of Wayland in Rust

[Pekka Paalanen]

On Fri, 5 May 2017 19:49:37 +0200
Wojciech Kluczka <wojciech.kluczka at gmail.com> wrote:

> > 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.  
> 
> 
> This is some solution but it's huge workaround. I would rather use
> bindings.

Hi,

what do you mean? Was that what you did not want to do?

> > If you want an EGL driver to
> > talk to Wayland, you need the driver and the server to share a C
> > implementation of the protocol library.

Not necessarily a C implementation, just some implementation that
also offers the C ABI.

The important point here is that all software components in the
same process must agree on which implementation to call. Other
processes are free to use other implementations.

If you had multiple implementations called arbitrarily in the same
process, then those implementations would have to be not just
ABI-identical, but also 100% identical in their internal binary
data structures. I believe there would be no point in that.

> 
> With this approach there either
> - has to be the one and only implementation or
> - every implementation provides its own stuff to mesa or
> - (what I meant in second point in my first message) mesa is generic enough
> to be used by any implementation. EGL_WL_bind_wayland_display takes
> wl_display and fills wl_buffer_interface and wl_drm_interface with pointers
> to functions taking wl_resource in arguments. I can imagine extension which
> takes implementation-independent structure and fills it with
> implementation-independent functions which can be used to construct (by
> server) implementation-dependent wl_drm in Rust, Haskell, or whatever that
> talks C ABI.

You are still talking about EGL_WL_bind_wayland_display which is
server side. Are you not interested in the client side at all? They
are not that different in the message handling.

How would another C ABI change things?

What would it look like?

In a single process context, would it be aiming for a single
implementation usable from different languages, or multiple
language-specific implementations cooperating through something?

Where would you maintain the per-connection object id map or how
would you guarantee strict message ordering, for example?

There is also the practical issue of proprietary EGL
implementations being more or less carved in stone in binary.

> 
> But...
> 
> 
> > Yes, you don't need to use the EGL extension. You can implement wl_drm
> > or the dma-buf extension directly in your rust based compositor.  
> 
> 
> ... if so, then I'm more than good with that. I will see what I can do.

But that applies only to the server side, letting you get away
(maybe! depending on hardware and driver details) with never using
EGL_WL_bind_wayland_display.

Also wl_drm is a Mesa internal implementation detail. You cannot
expect any other EGL implementation to be using the same.


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/20170506/0ea3caf0/attachment.sig>