1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
|
# Feature gap survey: srdwm vs. comparable Wayland compositors
Requested directly: compare srdwm against similar projects and note what
else is worth having. Compared against niri (cloned at
`~/reference-wms/niri`, smithay-based like `crates/wayland`, the closest
architectural sibling per `docs/PRIOR_ART.md`) plus general knowledge of
Hyprland and sway, since neither is cloned locally. srdwm is dynamic/
floating-first with opt-in tiling (`crates/core/src/layout.rs`), not
tiling-first - comparisons below are scoped to what a daily-driver desktop
user would actually notice, not "does it tile as well as sway."
## Already comparable
Confirmed by reading the actual code, not by trusting `docs/TODO.md`'s own
claims:
- **Session lock** (`ext-session-lock-v1`) - full implementation
(`crates/wayland/src/lock.rs`), verified live with a purpose-written
protocol test client, not just against a real locker binary.
- **Tiling** - a real dwm/i3-style master-stack layout
(`crates/core/src/layout.rs`), opt-in per srdwm's dynamic-first design,
not the only layout.
- **Global menu / app menu export** - `com.canonical.AppMenu.Registrar`
and dbusmenu (`crates/platform/src/appmenu_registrar.rs`,
`crates/wayland/src/appmenu.rs`). Neither niri nor sway ship this at all;
it is a GNOME-HUD/Unity-era convention most compositors dropped.
- **Right-click desktop/icon context menus** - real, compositor-owned
floating UI (`crates/wayland/src/desktop_menu.rs`,
`crates/wayland/src/context_menu.rs`). niri and sway have no desktop
icons at all; this is closer to what Hyprland users get from a separate
panel, but srdwm draws it itself.
- **Gamma control** (`wlr-gamma-control-unstable-v1`, night-light/redshift-
style color temperature) - `crates/wayland/src/gamma_control.rs`. Same
protocol niri implements.
- **Idle handling** (`ext-idle-notify-v1`, `zwp-idle-inhibit-manager-v1`)
- `crates/wayland/src/protocols/idle.rs`, `crates/wayland/src/
output_power.rs`. Screen-dim/DPMS-on-idle and an app's ability to
suppress it (a video call staying awake) both work.
- **Layer-shell** (bars, docks, launchers, notifications) - full, with
exclusive-zone handling on fractionally-scaled outputs (a genuinely hard
case niri and sway both get right too, and srdwm has now independently
fixed the same class of bug on its own scale-below-1.0 feature).
- **Output management** (`wlr-output-management-unstable-v1`) - real,
plus srdwm's own layout persistence (`crates/wayland/src/
monitor_layout.rs`) that neither waits on nor depends on a panel to
restore monitor position/enabled-state across a restart.
- **XWayland** - full, with WM_TRANSIENT_FOR-based dialog detection,
clipboard bridging, and EWMH.
## Genuine gaps, ranked by how much a daily user would notice
1. **No screen-sharing / video-call screen capture.** `grep -rn pipewire`
and `grep -rn portal` across `crates/wayland/src` return nothing. niri
ships real PipeWire-backed screencasting (`src/screencasting/
pw_utils.rs`) so `xdg-desktop-portal-wlr`/`-gnome` can hand a window or
output to Zoom, Discord, Google Meet, OBS, etc. srdwm has
`zwlr_screencopy_manager_v1` (one-shot capture, what `grim` uses) but
nothing a portal can wire to for a *live* video stream. This is the
single most likely thing a daily user hits and can't work around --
worth scoping as real work, not a one-line addition (needs a PipeWire
dependency and an `xdg-desktop-portal` backend, or at minimum wiring an
existing generic wlr backend against srdwm's own screencopy).
2. **No `zwlr_virtual_pointer_manager_v1`.** Already flagged in `docs/
TODO.md`'s own protocol-gaps section: `ydotool` and any UI-automation
tool that wants precise synthetic clicks has no real protocol path here
(`zwp_virtual_keyboard_manager_v1` exists; the pointer half doesn't).
niri implements this (`src/protocols/virtual_pointer.rs`). Directly
relevant to this project's own testing methodology, independent of
whether any real user-facing app needs it.
3. **No `ext-workspace-v1`.** srdwm's workspaces are real and queryable
(`srd workspaces`), but only through its own bespoke IPC - a
third-party panel/switcher that speaks the standardized
`ext-workspace-v1` protocol (what niri and sway both also implement
for exactly this reason) has nothing to bind to. Low-impact today only
because AGS is a first-party shell built against `srd`'s own IPC
directly; would matter the moment someone wants to run a generic
workspace-switcher widget unmodified.
4. **No touchscreen support (`wl_touch`).** Zero matches for
`TouchHandler`/touch-slot handling anywhere in `crates/wayland/src`.
Both niri and sway support it. Not clearly a gap worth closing blind --
see `docs/TODO.md`'s own "decide scope first" note on this: a
touchscreen on a device with no on-screen keyboard/gesture layer is a
different, larger product decision than just wiring the protocol.
5. **No accessibility tree (AccessKit or similar).** niri ships a real
`a11y.rs` exposing window/workspace state to assistive tech via
AccessKit. Nothing comparable exists in srdwm. Niche for this specific
user's own daily-driver use case, but worth naming since sway has had
growing accessibility interest too.
6. **No live/animated wallpaper support in the compositor itself.** Not
actually a gap versus niri or sway - neither of them render wallpapers
either; that is `swaybg`/`swww`/`mpvpaper`-style external clients'
job, and srdwm already has exactly that split (`awww`, a swww fork,
launched from `~/.config/srd/autostart.sh`, with the compositor just
compositing whatever that client draws via layer-shell). If "live
wallpapers" means something *animated* rather than just a static image,
that is an `awww`/wallpaper-daemon feature request, not a compositor
one - worth confirming with whoever owns that tool before treating it
as an srdwm gap at all.
## Deliberately out of scope / not real gaps
- **Multi-GPU.** Documented and accepted (`docs/IMPLEMENTATION_STATUS.md`):
only the primary GPU's connectors are driven, a GPU appearing/
disappearing is logged and ignored. Neither a laptop-daily-driver nor
this machine's real hardware needs it.
- **A native GUI settings app.** Never existed even as working code in
the legacy C++ project; Lua config plus `srd` CLI covers the same
ground niri's own KDL config file does, and neither niri nor sway ship
a GUI settings app either - this would be an srdwm-specific addition,
not catching up to a peer.
- **Hardware DRM cursor plane / direct scanout / VRR / HDR.** Real,
ranked gaps against niri and Hyprland specifically (both do real
GPU compositing with these), but already tracked in `docs/TODO.md`'s
own "Render pipeline - researched, ranked, not started" section as
large, sequenced architectural work, not something this survey adds
anything new to.
- **"Different monitor modes combined in one," phone-monitor/VM special
workspace, optional AGS/srdwm phone mode.** None of niri, sway, or
Hyprland have anything resembling these - they are not features to
catch up on from a peer project, they are net-new product ideas
specific to this user's own workflow. Out of scope for a feature-parity
survey; each needs its own real design pass (see `docs/TODO.md`/the
night's parked questions for what's still undecided about them).
|