[ddevault]

>(c) Absolutely a negative reflection, there are two ugly things going on here. The official wayland libraries use a ownership style that really only makes sense in C imho, and despite the claim that wayland is just a protocol you can't actually not use the official libraries, because the drivers only work with the official libraries.

Not really sure what you're talking about here. Wayland is just a protocol, and a pretty simple one to boot. There also exists a pure Rust implementation of the Wayland protocol:

https://github.com/Smithay/smithay

The problem is that Rust and libwayland, the C implementation of Wayland, don't get along well, and that wlroots is designed to work with libwayland and inherits a lot of those design decisions that make it difficult to deal with in Rust. And to be honest, Rust is special in this regard. Other wlroots bindings exist for Go, Haskell, Common Lisp, OCaml, and Chicken Scheme - and all seem to do fine.

I think this points more to a failing in Rust, in that it's not designed to cope with this particular model well. Since this is a fairly common model, that seems like a big flaw.

[sly010]

> Wayland is just a protocol, and a pretty simple one to boot.

For a Wayland client to render using hardware acceleration, it has to link to an OpenGL library (typically mesa, specifically EGL to set up the OpenGL context). Mesa (a library written in C) links to libwayland-client (also written in C). The problem is that mesa is expecting a pointer to a C struct that is defined in libwayland-client. It will cast that pointer and call libwayland-client functions.

Mesa could have been written to use a different level of abstraction (e.g. take a struct of function pointers) it would be possible to wire it up with your own wayland library.

It doesn't help that libwayland-client was designed to be stateful (since the protocol itself it stateful).

So, while technically you can write a wayland client without using libwayland-client, you cannot create an OpenGL context without rewriting mesa. You also cannot link directly or indirectly with ANY libraries that use libwayland-client.

So people give in, use C, and move their abstraction layers higher up in the stack.

Edit: grammar.

[gpm]

Thank you for spelling out the details, I knew the issue existed but forgot the details.

[gpm]

At a glance, smithay depends on wayland-server depends on the official wayland libraries. More specifically the issue that makes this necessary is that it's the only way to get an OpenGL context (AIUI - it's been quite awhile since I worked on this).

Rust is special in that's it's even worse at representing it, but the C controlled event-loop/fd-based-dispatching/ownership model wayland uses isn't idiomatic in any language other than C. Maybe wlroots makes this better, like I said I've never used it and can't speak to it.

[Sir_Cmpwn]

Smithay has both a pure Rust and libwayland-based implementation, you can pick iiuc.

And the OpenGL problem isn't fair, OpenGL is such a flaming heap of poor design that binding to libwayland to use it is the least of your problems. Better to use Vulkan instead for this purpose imo.

Event loops are common in many languages.

[gpm]

> Event loops are common in many languages.

Including rust - I'd have to dig in again to remember exactly why the wayland one was so bad at interacting with rust to be honest. I know it had something to do with how ownership of callbacks and objects interacted with the event loop. I know I didn't think I could represent it much better in python.

OpenGL may be a shit show, but it's necessary (to be able to expose it to clients) for a modern desktop. I think I was doing this either before or in the really early days of Vulkan so I don't really know how that changed things.

[steveklabnik]

Rust can handle event loops just fine; our entire asynchronous IO story is based on them!