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.
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...