swvkc
is an experimental Wayland compositor meant to explore the possibility
of using Vulkan as a rendering backend.
swvkc
prioritizes direct scanout of client buffers when possible. When
compositing needs to be done, it renders to the screen with simple copy commands
from the Vulkan API.
Some goals/directions of the project:
- Do the minimal work necessary to display client buffers, do not introduce screen tearing/stuttering or input lag.
- Stick to minimal window management features.
- Try to write simple, easy to understand code.
- The mechanism to import both shm and dma buffers into Vulkan has been quickly sketched, but it needs to be made more robust (some assumptions about the buffer formats should be removed too).
- I tried for some time to implement tear-free single-buffered rendering (by restricting rendering to VBlank Intervals) but failed to achieve it consistently. Using double-buffering for now.
- The Wayland protocol has been implemented partially so only some clients work at the moment.
- Only one surface is focused and displayed at a time
- One single client can be run at startup (I suggest a terminal)
- Focus can be changed (see Usage notes)
- No popups [coming soon...]
- No clipboard [coming soon...]
- The hardware is required to support the modern DRM atomic commit interface
- No XWayland support
swvkc
tries to have minimal dependencies. Here is the full list:
- Wayland
wayland-server
, the core server APIwayland-protocols
to generate protocol headers and code
- DRM
libdrm
for controlling the screenlibdrm_intel
(optional) to use the intel buffer manager instead of GBM
- Vulkan
vulkan-loader
to load the appropriate vendor-specific libraries- the vendor-specific Vulkan implementation (e.g.:
vulkan_intel
oramdvlk
)
- Mesa
gbm
for the GBM buffer manager but also required byegl
egl
[legacy] I have to keep it to provide thewl_drm
interface, on which Mesa relies to authenticate against DRM
xkbcommon
for keyboard standardization, it is practically required by the Wayland speclibudev
for GPU discovery and monitor hotplugging (not yet)
After installing meson
, run the command:
$ meson build
and install any missing dependency that is reported. Then run:
$ ninja -C build
Upon successful compilation the binary is located inside the build
directory.
- The presence of the environment variable
XDG_RUNTIME_DIR
is required, and it must point to an appropriate folder (this is automatically set up bysystemd
orelogind
) - Provide the required permissions (e.g. by adding the user to group video and input)
- Start the program from the Linux console (not inside another X11/Wayland compositor)
- Pass it the client (and its arguments) you want to run
- Hold the LEFTMETA (Win) key and press ESC to exit
- To change focus: hold LEFTMETA and start to type the client name until an unambiguous match is found
- Keyboard settings (such as layout) are set through XKB_DEFAULT* environmental variables.
Importing memory created by DRM/GBM into Vulkan images is undefined behaviour
without the VK_EXT_image_drm_format_modifier
extension: even when the image
is created with linear layout and without modifiers, there is no way to
specify the correct row pitch (please correct me if I'm wrong):
From Issues in https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/chap44.html#VK_EXT_external_memory_dma_buf
How does the application, when creating a VkImage that it intends to bind to dma_buf VkDeviceMemory containing an externally produced image, specify the memory layout (such as row pitch and DRM format modifier) of the VkImage? In other words, how does the application achieve behavior comparable to that provided by EGL_EXT_image_dma_buf_import and EGL_EXT_image_dma_buf_import_modifiers?
+
RESOLVED. Features comparable to those in EGL_EXT_image_dma_buf_import and EGL_EXT_image_dma_buf_import_modifiers will be provided by an extension layered atop this one.
The extension mentioned in the last line is precisely
VK_EXT_image_drm_format_modifier
. If you are unable to display clients like
weston-simple-shm
, weston-terminal
and firefox
, the absence of this
extension is likely to be the problem.