Skylane - implementation of Wayland protocol


#1

Hi

I’d like to announce skylane. Skylane is implementation of Wayland written in Rust from scratch (it’s not binding, does not require libwayland-*.so.)

Repo: https://github.com/perceptia/skylane

Let me know if someone is interested.


#2

Wow, very nice. A couple of Rust compositors are based on wlc which is written in C… and currently “in low-maintenance mode and will be abadoned in future”. Hopefully there’ll be a replacement based on this. Seems like perceptia is modular…


#3

Yay, I’m glad to finally see wayland implemented in Rust. Excited to see what this leads to.


#4

Thank you for comments. I’m exited too :smile:

Regarding perceptia - I try to keep each part of program as separate as possible mainly for unit tests but there is also extracting reusable parts in the back of my head. I wouldn’t call it fully modular right now but certainly it’s modulation-ready. I also plan plugin support so that it could be used as bare patch-customized minimum like dwm or full-featured machinery.


#5

Very cool! Do you have some screenshots where we can see it running?

PS: Maybe send this news to Phoronix which has a big audience!


#6

Since there doesn’t seem be any example, I’m curious how far ahead this is?

As far as I know you cannot use OpenGL/EGL or Vulkan without using the libwayland written in C. Yes that seems stupid, but that’s how people have decided to design it.
And I may be wrong but if I’m not mistaken OpenGL or Vulkan are the only possible way one can display something on a wayland window.


#7

Example is perceptia - Wayland compositor (or window manager): https://github.com/perceptia/perceptia/ It uses server side of skylane and perceptiactl (a supportive application) uses client side (only for screenshots so far).

One screenshot is on wiki: https://github.com/perceptia/perceptia/wiki/Screenshots

perceptia is in very early stage of development. I don’t even use it myself on my desktop yet, so I think its too soon for user-oriented audience like that on Phoronix (actually I posted link in some old thread, but probably nobody noticed that). I’m focusing now on stability and sketching overall shape to make it visible where the project intends to go.

skylane misses some things but it’s in quite good shape. At least I thought so… I hoped adding EGL support will come down to fabrication of some pointers, but indeed mesa does quite a bit of magic. While on client side it would require linking against libwayland-client.so or small change in mesa, on server side it’s tough nut. I will have to think about it.

Nevertheless yes, it is possible to draw on Wayland window without OpenGL or Vulkan. Client and server simply share (CPU/RAM) memory. Of course if client uses OpenGL for rendering it’s faster to share buffer on GPU than copy buffer to RAM, send it to server and load back to GPU, but perceptia is performing good without it.

Thank you for comments! Notice about EGL was very important.


#8

Wow, that’s really surprising. I hope it’s just a temporary flaw.


#9

FYI, I asked question about this hardware acceleration on Wayland mailing list:
https://lists.freedesktop.org/archives/wayland-devel/2017-May/034034.html


#10

It’s inherent in the design of EGL/Vulkan WSI. You need some object to pass to the windowing system integration part, and the driver needs to know what it can do with it.

In X11 the driver gets passed a Display; in Wayland the driver gets passed a wl_display to build an EGLDisplay on, and wl_surface to create an EGLSurface on. Those objects are defined by, and interacted with, libwayland-client.so.

You could theoretically use pure Rust implementation as long as you ensured that the structures you use for rust_wl::Display and rust_wl::Surface are laid out identically to the libwayland structures. In practise, these are private structures and their internal representation involves a bunch of Rust-hostile features (like intrusive wl_lists and the like).

Alternatively, you could make your Rust implementation expose the libwayland-client.so C ABI and replace the system libwayland-client.so with it. The core Wayland libraries aren’t huge, so this would almost be a reasonable approach (which you could then plausibly propose upstream, to replace the C implementation).


#11

Why can you only use the C version? Can the Rust version be released with a C wrapper and that would do fix it?


#12

Desire to avoid wrappers is exactly the reason why skylane was created. And it would have to either be not only wrapper but be absolutely compatible on binary level or completely replace libwayland-*.so becoming [joke mode] the monster it wants to kill.

I will soon start experimenting with dmabuf and will let you know about results.


#13

Little update about client hardware acceleration support: skylane was meant to be binary incompatible with libwayland so by design of EGL it should be its next platform. Of course I wanted to avoid such solution not only because of its complexity, but also because having new platform for each implementation of Wayland would be horrible. Fortunately it was possible (and very easy) to provide support for hardware acceleration only with GBM. I implemented it in perceptia and prepared simple client examples:

https://github.com/perceptia/perceptia/tree/master/src/skylane_simple_framework/examples

They are only proof of concept and show only first frame. Drawback is that they are currently compatible only with mesa. I’m currently working on perceptia. If someone would like learn about Wayland and low-level user-space Linux graphics and finish the examples (show more frames with moving objects) I would be very happy.

There are also couple of easy issues in skylane if someone wants to help.