Two one-line workspace-dep fixes that drop the last remaining X11 crates
for Wayland-only builds:
- softbuffer: its default = [kms, x11, x11-dlopen, wayland, wayland-dlopen]
pulled tiny-xlib + as-raw-xcb-connection unconditionally even though
iced_tiny_skia only needed softbuffer/wayland. Disabling the default
lets iced_tiny_skia's own feature propagation ask for just wayland +
wayland-dlopen.
- window_clipboard: upstream pulled clipboard_x11 + clipboard_wayland
unconditionally on unix. Our local fork (branch yoda-x11-optional)
gates clipboard_x11 behind an opt-in feature, so default-features=false
+ features=["wayland"] drops ~500 x11 symbols (clipboard_x11, x11rb,
x11rb-protocol).
Combined with previous yoda-v4 cuts, cosmic-yoterm goes from
1526 -> 43 x11 symbols (-97%), and 55.4 MB -> 53.3 MB (-2.1 MB).
iced_wgpu's unix block unconditionally depended on as-raw-xcb-connection,
tiny-xlib and x11rb for a DRI3 device-id fallback in
window/compositor.rs that only fires when wayland can't determine the
GPU. On a Wayland-only build this code path never runs, so the deps
are pure bloat.
Changes:
- Cargo.toml: move the 3 x11 crates to optional + new feature `x11`
(not in default — wayland-only is the yoda target; users who need
X11 opt in).
- window.rs: cfg-gate `mod x11;` on feature = "x11"
- window/compositor.rs: cfg-gate `use super::x11::get_x11_device_ids`
+ the or_else fallback on feature = "x11" (wrapped in a let-binding
so the non-x11 branch compiles cleanly).
Result: iced_wgpu no longer pulls any x11 crate when built without
the feature.
Was pulling winit's full x11 backend (winit-x11 + x11-dl) unconditionally
despite iced_winit's own x11 feature being disabled. Fixed by adding
default-features=false on the workspace-level winit dep — iced_winit/wayland
+ wayland-dlopen propagate to winit/wayland + wayland-dlopen as needed.
I have >1000 fonts installed. COSMIC has always been somewhat laggy for me, but I had assumed it was just like that for everyone, or was the fault of my T480s. Eventually, when trying to diagnose some hitching, I ended up discovering that cosmic-launcher was consuming on average ~5% total CPU over time, which led me to discover that it was fetching all the fonts from disk and software rendering the fonts, every redraw, causing the high cpu usage *and* the stutters (as a result of hammering disk I/O). Oops.
The fix is simple: just persist the cache across redraws.
The session lock configure handler was missing receive_frame() and
request_redraw() calls that the layer surface configure handler has.
Without these, after S3 resume or DPMS wake, the FrameStatus entry
for lock surfaces could be missing, causing the rendering gate to
never reach Ready state — resulting in permanently grey lock screens.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
