When the last camera reader disconnects, cycle the output pipeline
(v4l2sink) through READY → PLAYING to reset v4l2loopback's format
state. Without this, switching between camera apps that use different
PipeWire paths (e.g. Chromium → GNOME Snapshot) fails with "no more
input formats" because v4l2loopback retains stale format state from
the previous session.
The reset is guarded by an input_was_active flag so it only triggers
after an actual streaming session, not during PipeWire's brief device
probes on startup.
Tested on Dell XPS 16 (Panther Lake) with PipeWire 1.6.2:
- Snapshot → Zoom → Snapshot: working
- Suspend → resume → Snapshot: working
- Boot → first Snapshot: 30fps
Replace camera-feed-watch and camera-session with v4l2-relayd, a
single-process daemon that manages the icamerasrc -> v4l2loopback feed.
v4l2-relayd uses V4L2_EVENT_PRI_CLIENT_USAGE kernel events to detect
when an app starts/stops streaming, providing zero-polling on-demand
camera activation with LED control.
This is a generic solution that works with all PipeWire apps (Snapshot,
Chromium, Firefox, etc.) without per-app wrappers or .desktop patching.
The key advantage over the previous camera-feed-watch approach: v4l2-relayd
keeps a single persistent v4l2sink writer, switching only the data source
(splash vs icamerasrc) via appsrc. This avoids the PipeWire stale mmap
buffer issue that caused degraded framerate on subsequent camera sessions
when the writer process changed.
Changes:
- Add v4l2-relayd as package dependency
- Add /etc/v4l2-relayd.d/ipu7.conf with icamerasrc pipeline config
- Add systemd service override for GST_PLUGIN_PATH and device access
- Remove camera-feed-watch, camera-feed-watch.service, camera-session,
camera-feed.service, and Snapshot .desktop patching
- Restore PipeWireCamera feature flag for Chromium/Brave/Chrome
- Enable v4l2-relayd@ipu7.service at install time
Gaggery