Smithay-based Wayland/XWayland compositor for HWDE.
state.rs-HwdeState(core struct) +ManagedWindowbookkeeping (minimize/maximize/focus/close-by-id,is_ssddecoration tracking - backing the unified taskbar withstarthwde).handlers/- one file per Wayland protocol:compositor.rs- core compositor/buffer/shm.xdg_shell.rs- xdg-shell, incl. interactive move/resize (grabs.rs) and popup handling.seat.rs,output.rs- seat/output plumbing.data_device.rs- clipboard (wl_data_device_manager) and primary selection ("middle-click paste").decoration.rs- xdg-decoration negotiation; tracksis_ssdper window forrender_elements.rsto draw.layer_shell.rs- wlr-layer-shell protocol +LayerMaparrangement.xwayland_shell.rs(feature = "xwayland") - required byX11Wm.
render_elements.rs- the full per-frame render pipeline: wallpaper + all fourwlr-layer-shelllayers (via Smithay'sspace_render_elements, correctly interleaved in front of/behind the window stack) + windows + minimal server-side decorations, assembled back-to-front and driven through the lower-levelOutputDamageTracker::render_outputdirectly (bypassingspace::render_output's single-group-always-behind limitation - see this file's module doc for why).grabs.rs- interactive move/resize pointer grabs, shared by native Wayland (handlers/xdg_shell.rs), XWayland (xwayland.rs), and SSD grab bars (input.rs).winit_backend.rs- the default, wired-into-mainbackend: nested/windowed.input.rs- forwards winit keyboard/pointer/touch events into the seat; hit-tests SSD grab bars/close buttons before normal client dispatch; triggers popup-dismiss-on-outside-click.wallpaper.rs- loads HWDE's wallpaper and renders it as a full-screen background element every frame; reloadable live via IPC (see below).ipc.rs- thehwde-ipccontrol socket: external app launching, the unified window-list/focus/close/minimize/maximize protocol, live wallpaper changes (a Settings change now reaches an already-running compositor immediately, not just its next restart), shutdown.xwayland.rs(feature = "xwayland", default on) - starts XWayland, maps X11 clients into the same desktop space as native Wayland windows, real interactive move/resize.backend_drm.rs(feature = "drm-experimental", NOT wired intomain) - session/udev-hotplug/libinput wiring is real, ported from Smithay's ownanvilreference compositor. The atomic-KMS device/connector setup and vblank-driven render loop are deliberately left as a precise, sourced outline rather than a mechanical port - see the module's doc comment for why (short version: that specific ~300 lines of anvil code is exactly the kind of GPU-buffer-lifetime-sensitive code that's genuinely unsafe to "port and hope" without a real compile-run-fix loop against actual KMS hardware).
- wlr-layer-shell now actually renders (all four layers, not just Background/Bottom) - previously the protocol worked but nothing was painted.
- Minimal server-side decorations: a solid-color grab bar + close
button for windows that negotiate
Mode::ServerSidevia xdg-decoration - drag to move, click the red square to close. No drawn title text yet (needs a font-rasterization pipeline this compositor doesn't have). - Primary selection ("middle-click paste") alongside the main clipboard.
- Touch input forwarded to clients (down/motion/up/cancel/frame).
- Live wallpaper reload: changing the wallpaper in Settings now reaches
an already-running
comphwdevia IPC instead of only taking effect on the compositor's next start. - DRM/udev backend: upgraded from a pure doc-comment plan to a real, substantial session/device-discovery/input scaffold - still not the default, still needs the atomic-KMS core built against real hardware.
- The DRM/udev backend's atomic-KMS render core (see
backend_drm.rs). - Native Wayland output/display management (
xrandr-equivalent) - blocked on the above, since there's no KMS connector/mode info without it. - SSD title text (grab bar has no label, just a drag handle + close button) - needs text rendering, which needs a font rasterizer.
- Tablet input and multi-touch gesture recognition as a compositor-level
concept (raw touch points are forwarded; pointer gesture events are
passed through during an active grab in
grabs.rs, but there's no standalone gesture recognizer).
None of this is an accident - it's the deliberate "narrow but real" scope the project asked for, with the bigger/hardware-dependent pieces flagged for follow-up rather than faked.