[heeen2]

Wayland does not require a GPU and the baseline protocol is just shared memory buffers. The protocol requires file descriptor for said buffers and getting gpu drivers to support mapping gpu memory to file descriptors is what allowed Wayland to become efficient through zero copy and just passing handles from clients to compositors

[immibis]

The Wayland base protocol is completely unusable since it does nothing by itself. Doing useful work with Wayland requires more stuff, like a GPU driver.

[heeen2]

It requires a GPU in the same sense that windows 3.1 or dos or whatever else requires a GPU to convert the contents of a memory buffer to a signal that a display can actually display.

But you can also just encode the result of your composition to a h264 stream and send that over the network if you so desire. no GPU required in this case.

> The simplest means of getting pixels from client to compositor, and the only one enshrined in wayland.xml, is wl_shm — shared memory. Simply put, it allows you to transfer a file descriptor for the compositor to mmap with MAP_SHARED, then share pixel buffers out of this pool. Add some simple synchronization primitives to keep everyone from fighting over each buffer, and you have a workable — and portable — solution.

https://wayland-book.com/surfaces/shared-memory.html

> [weston] Available back-ends:

> drm – run stand-alone on DRM/KMS and evdev (recommend) (DRM kernel doc)

> wayland – run as a Wayland application, nested in another Wayland compositor instance

> x11 – run as a x11 application, nested in a X11 display server instance

> rdp – run as an RDP server without local input or output

> headless – run without input or output, useful for test suite

> pipewire – run without input, output into a PipeWire node

https://wayland.pages.freedesktop.org/weston/toc/running-wes...