daedalus-v4l2{,-dkms}: 462aa4b -> f0d4186 — per-ctx vb2 lock

Upstream PR #3 — kernel per-context vb2_queue lock so concurrent
clients of /dev/video0 don't serialise on a device-wide mutex.
Pi 5 Firefox VAAPI playback (RDD + content + GPU processes each
opening the device) now works without S_FMT EBUSY collisions.

Verified on higgs: YouTube playback engages daedalus at sustained
~230 fps decode through the libavcodec dlopen path, ~7× headroom
over the 30fps@1080p Pi 5 Fourier target.

Both packages: pkgver 0.1.0.r24.f0d4186, pkgrel reset to 1.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

debian/daedalus-v4l2/debian/changelog

@@ -1,3 +1,22 @@
+daedalus-v4l2 (0.1.0+r24+gf0d4186-1) bookworm trixie; urgency=medium
+
+  * Bump to f0d4186 — kernel per-ctx vb2 lock fix.  daedalus_queue_init
+    was wiring src_vq->lock and dst_vq->lock to ctx->dev->m2m_lock (a
+    device-wide mutex), serialising every vb2 ioctl across all
+    concurrent clients of /dev/video0.  For Firefox (which spawns
+    separate content + RDD + GPU processes that each open the device
+    and run libva probe simultaneously), one libva session's
+    S_FMT(OUTPUT_MPLANE) hit EBUSY while another was mid-streamon —
+    Firefox VAAPI playback fell apart at startup.
+  * Fix gives each open() its own ctx->vb_mutex; vb2 ioctls run
+    independently per client.  Matches cedrus / rkvdec / hantro
+    pattern.
+  * Verified on higgs: Firefox YouTube playback engages VAAPI cleanly,
+    sustained ~230 fps decode at 640x368 through the daedalus daemon,
+    zero EBUSY in stderr or daemon journal.
+
+ -- Markus Fritsche <mfritsche@reauktion.de>  Wed, 20 May 2026 23:00:00 +0000
+
 daedalus-v4l2 (0.1.0+r22+g462aa4b-1) bookworm trixie; urgency=medium
 
   * Bump to 462aa4b — kernel-side fix for control-binding gap that