Module caps 

ShellCaps — what a backend can actually do, asked as a question about capability rather than about identity.

The regression this exists to prevent

if cfg!(target_os = "linux") && std::env::var("WAYLAND_DISPLAY").is_ok() {
    // …use the viewport path
}

That code is wrong three ways and all three are invisible until someone files a bug: it is wrong on a Wayland compositor that does not implement wp_viewporter, wrong under XWayland, and wrong the day the shell grows a backend nobody thought about. The windowing rules in docs/notes/backends.md are explicit — “the renderer picks blit-vs-viewport and windowed-aspect behavior from caps, never from am I on Wayland” — and this module is the mechanism. It mirrors crcbl-hal’s Features, where the renderer asks for DRAW_INDIRECT_COUNT rather than for Vulkan.

Caps are per-shell, not per-window

A capability here is a property of the connection and the protocols the server advertised, so it is fixed for the shell’s lifetime and reported by Shell::caps rather than per window. The one thing that genuinely varies per window — its current size and scale — is WindowState, not a capability.

There is a real edge here, and it is stated rather than hidden: a Wayland compositor can bind a global after startup, so a protocol could in principle appear mid-session. Backends must not flip caps bits when that happens; a renderer that picked the blit path at init cannot be told halfway through a frame that it should have picked the viewport path. Capabilities are latched at connection time, and a missing protocol stays missing until the next run.

Structs

ShellCaps

What a shell backend supports.