Creating a very basic wayland compositor that draws directly to the framebuffer

[floers]

Hello,

I try to understand how to write compositors with smithay. I started a pet project where I want to create a compositor that draws into the framebuffer. Unfortunately I am stuck here. I was able to create a wayland server and client that can can deal with input events by going through the examples. I think I got how to fill a slot::Buffer with bytes (I basically do this: https://github.com/Smithay/client-toolkit/blob/master/examples/generic_simple_window.rs). But I don't see how to get this buffer to the server and actual deal with it there. I know this ticket is related but if I understand this correct I should be able to create a basic setup that deals with just "fullscreen" clients without this feature being implemented?

My understanding of wayland and smithay is very basic at this point. I think I need to implement a custom Renderer and access a DumbBuffer but I don't understand how and after hours of reading and searching I think i just need some help.

[Drakulix]

draws into the framebuffer.

Modern drm-drivers don't really have the concept of a framebuffer anymore. I recommend rather going with something like smithays DrmDevice.

But I don't see how to get this buffer to the server and actual deal with it there.

So what happens on the wayland-connection would be to attach said buffer to a surface and commit said surface. The example you linked does that at the end of draw.

If I understand this correct I should be able to create a basic setup that deals with just "fullscreen" clients without this feature being implemented?

Yes, although we do have a software renderer (based on pixman) these days, so I went ahead and closed that issue.

I think I need to implement a custom Renderer and access a DumbBuffer but I don't understand how and after hours of reading and searching I think i just need some help.

You don't. You can deal with DumbBuffers, but they are painfully slow. I would much rather recommend to use the GbmAllocator smithay provides to get buffers you can draw on with the GlesRenderer. You can however also export a Dmabuf from a DumbBuffer, which can be used with the GlesRenderer or the PixmanRenderer just the same.

Have you looked at smallvil or anvil in the smithay repository? Both are example compositors (though smallvil is limited and e.g. only works nested, not with a drm device) that deal with all of this. smithay abstracts quite a bit over the buffer mechanisms of the wayland-connection as a lot of protocols change how these buffers need to be drawn. As such in smithay you usually "draw" a surface.

But it sounds to me like you already figured out a good amount of stuff, regarding the drm device. Any more specific questions?

Also I highly recommend joining our matrix-chat instead (see the README), where lots of people would be more than happy to get you started. :)

[floers]

Hey, Thanks for the response. I looked at anvil but I found it only after I started this discussion. The thing is: I am not sure whether it does what I am trying to do. I guess I should have mentioned it earlier. I am targeting embedded devices. Especially the remarkable2. I want to see whether I can create a wayland compositor and shell for eink tablets. Writing bytes to the framebuffer and handling touch and pen events is all I need for now. I believe this means I don't need most of the things I see in the examples. Like XdgShell, udev, gbm, drm, and whatever all those things are.

From reading into wayland and trying to understand the examples I was able to create my own "wayland" and compositor in no time. I mean: unix socket, shared memory, binary protocol and there you go. It works perfectly well but I think it's a better approach to implement common standards... I just find it quite impossible to understand how to do it :D. At least in a reasonable amount of time.

[Drakulix]

I believe this means I don't need most of the things I see in the examples. Like XdgShell, udev, gbm, drm, and whatever all those things are.

XdgShell is the standard protocol for windows in wayland. You most likely want it.

Does the remarkable not have any sort of hardware acceleration? Most embedded devices come with gpus and standard drm/gbm interfaces these days.

If you have something that still uses Fbdev or similar and you just have a framebuffer, you can either copy by memory (in that case I recommend just rendering into a slice of memory with the PixmanRenderer) or if you can push DumbBuffers to that, exporting them as dmabufs and binding that to either a GlesRenderer (if you have a gpu) or a PixmanRenderer as well. All of that depends on the apis you have available to push screen contents.

At least in a reasonable amount of time.

Not to burst your bubble, as this is a pretty cool project and smithay should be able to help you a fair bit with this, but I have been at this for seven years. Writing a wayland compositor is barely possible in a reasonable amount of time. 😆

One of the youngest and usable projects based on smithay is niri: https://github.com/YaLTeR/niri . And even that is 8 months old at this point.

I just find it quite impossible to understand how to do it

I highly recommend you join our matrix chat. There are so many helpful people, that would be glad to bring you up to stuff with: Terminology, the different wayland protocols, how smithay abstracts over them, how all the backend stuff and rendering works, and so on!

[floers]

Alright. I already joined. I will go through your answers and the example I linked... and ask questions in matrix :)