Files
daedalus-v4l2/docs/roadmap.md
T
marfrit 6f4b580f7c Phase 8.5: full V4L2 m2m driver, VP9 decode via QBUF/DQBUF
Replaces the Phase 8.4 debugfs-triggered chardev path with a
real V4L2 m2m driver. Userspace clients now drive decoding the
standard way — S_FMT / REQBUFS / QBUF on the OUTPUT (bitstream)
queue, DQBUF on the CAPTURE (NV12M) queue. Kernel device_run
packs the bitstream into REQ_DECODE; daemon decodes via FFmpeg;
RESP_FRAME's inline NV12 pixel payload lands in the CAPTURE
buffer. Phase 8.6 swaps the inline payload for dmabuf so big
frames stop being capped at 64 KiB.

Kernel (daedalus_v4l2_main.c, rewritten + main.h added):
- Per-open struct daedalus_ctx: v4l2_fh, m2m_ctx, ctrl_handler,
  per-queue v4l2_pix_format_mplane.
- Two vb2_queues (vb2_vmalloc_memops for both — no DMA needed
  yet; 8.6 switches CAPTURE to dma_contig for dmabuf-export):
    OUTPUT  = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,  VP9_FRAME
    CAPTURE = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE, NV12M
- Full v4l2_ioctl_ops table: querycap, enum_fmt, g/s/try_fmt
  for both queues, reqbufs/querybuf/qbuf/dqbuf/create_bufs/
  prepare_buf/expbuf/streamon/streamoff via v4l2_m2m_ioctl_*
  helpers.
- v4l2_m2m_ops.device_run: peeks next OUTPUT buf, builds
  REQ_DECODE inline with the bitstream bytes, enqueues with an
  auto-incrementing cookie, stores {ctx, src_buf, dst_buf} in
  a per-device inflight list. Job stays open until RESP_FRAME.
- daedalus_complete_resp_frame(): pops the inflight entry,
  memcpys inline NV12 pixels into the CAPTURE buffer (Y plane
  + interleaved CbCr), finishes via
  v4l2_m2m_buf_done_and_job_finish — NOT plain buf_done +
  job_finish, which leaves the src buf on the m2m queue and
  causes device_run to immediately re-run on the same input
  (caught on first run; second REQ_DECODE for same bitstream +
  eventual oops in stop_streaming on teardown).

Kernel (daedalus_v4l2_chardev.c):
- RESP_FRAME handler now hands inline pixel payload to
  daedalus_complete_resp_frame so it lands in the CAPTURE
  vb2 buffer. Existing PONG and debugfs test_decode paths still
  work; the latter produces a harmless ratelimited "unknown
  cookie" since it bypasses V4L2 m2m.

Daemon (decoder.c, decoder.h):
- daedalus_decoder_run_request signature extended with
  (nv12_out, nv12_cap, nv12_used). After the FNV-1a digest the
  decoder packs YUV420P into NV12 in the caller's buffer: Y
  plane line-by-line stripped of stride padding; Cb/Cr
  interleaved into a single chroma plane. Truncation silent —
  kernel only memcpys what fits in the CAPTURE plane.

Daemon (chardev_client.c):
- handle_req_decode allocates a response buffer sized for the
  full chardev payload, lets decoder fill the pixel area
  after the resp_frame struct, sends the full payload via the
  existing send_response.

Test client (tools/test_m2m_decode.c, new):
- Minimal V4L2 m2m client: S_FMT both queues, REQBUFS 1 each,
  mmap+fill OUTPUT, QBUF both, STREAMON, poll, DQBUF, dump
  CAPTURE planes to a raw NV12 file. ~250 LOC; verifies the
  whole flow without needing v4l2-ctl framing.

Roadmap update (docs/roadmap.md):
- Phase 8.4 retitled "daemon ↔ kernel decode round-trip"
  to reflect what actually shipped (vs. the original V4L2-
  ioctl-driven plan which moved here).
- Phase 8.5 retitled "full V4L2 m2m driver" with closure
  status.
- Phase 8.6 reshaped to two tracks: dmabuf + AV1/H.264/
  stateless controls + media controller. Adds the punch list
  of v4l2-compliance failures (DECODER_CMD, S_FMT colorspace)
  that 8.6 will fix.

Verification on hertz (Pi 5, 6.12.75+rpt-rpi-2712):

  Kernel + daemon build clean (-Wall -Wextra clean both sides).
  Test harness drives one VP9 keyframe end-to-end:
    OUTPUT REQBUFS -> 2
    CAPTURE REQBUFS -> 2
    QBUF OUTPUT[0] bytesused=1566
    QBUF CAPTURE[0]; STREAMON both
    poll revents=0x5
    DQBUF OUTPUT[0] flags=0x4001 (DONE)
    DQBUF CAPTURE[0] flags=0x4000 payloads=[12288, 6144]
    wrote 12288 Y + 6144 UV bytes to /tmp/out_m2m.nv12

  Pixel correctness vs reference:
    ffmpeg -i vp9_small.ivf -pix_fmt nv12 -f rawvideo -y ref.nv12
    cmp /tmp/out_m2m.nv12 /tmp/ref.nv12 → match ✓
  Byte-for-byte identical to FFmpeg's stock CPU decode.

  v4l2-compliance: detected as Stateless Decoder; most ioctls
  pass; two expected fails documented in closure doc
  (DECODER_CMD/media controller, S_FMT colorspace).

  Clean teardown: SIGTERM the daemon, rmmod the module, no
  oops/WARN in dmesg.

Per correctness-before-speed:
- Real V4L2 ioctl table (not stubs); uses v4l2-core helpers
  where they exist instead of reinventing.
- v4l2_m2m_buf_done_and_job_finish (not the manual sequence)
  to keep scheduler state consistent.
- Bit-exact reference comparison, not just "looks right."
- Documented every compliance failure with the planned fix.
- All resource paths (kmalloc/kfree, inflight list cleanup,
  src/dst buf removal in stop_streaming) handled on every
  error branch.

Phase 8.6 next: dmabuf-export for CAPTURE (removes 64 KiB
frame-size cap), add AV1+H.264 codecs, add V4L2 stateless
controls + media controller binding, fix the colorspace +
cookie-namespace compliance issues.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-18 15:55:10 +00:00

3.2 KiB

daedalus-v4l2 — roadmap

Sub-phases

Phase 8.1 — kernel module skeleton

Out-of-tree kernel module that:

  • Registers /dev/videoNN with VFL_TYPE_VIDEO + a no-op V4L2 stateless dispatch table.
  • Accepts open/close, S_FMT, REQBUFS ioctls without doing anything (yet).
  • Builds against /lib/modules/$(uname -r)/build.

Deliverable: modprobe daedalus_v4l2 works, v4l2-ctl --list-devices shows the new device.

Phase 8.2 — kernel ↔ daemon chardev bridge

  • Kernel module creates /dev/daedalus-v4l2 chardev.
  • Defines a simple req/resp protocol in include/daedalus_v4l2_proto.h.
  • Daemon connects, exchanges echo requests.

Deliverable: ping-pong test passes.

Phase 8.3 — daemon FFmpeg dlopen + parse

  • Daemon links libdaedalus_core.a from sibling.
  • Daemon dlopens FFmpeg.
  • Test program: feed a VP9 IVF file to FFmpeg parsers, extract block-level metadata, validate against expected.

Deliverable: daemon can parse a VP9 frame and walk the block-level info.

Phase 8.4 — daemon ↔ kernel decode round-trip (closed 2026-05-18)

Shipped as a debugfs-triggered chardev round-trip rather than the original V4L2-ioctl plan (which moved to Phase 8.5).

  • REQ_DECODE / RESP_FRAME wire protocol
  • Daemon decodes VP9 via FFmpeg dlopen, returns FNV-1a digest
  • Verified content-dependent + deterministic; structured error handling for bad bitstreams

See docs/phase_8_4_closure.md.

Phase 8.5 — full V4L2 m2m driver (closed 2026-05-18)

Real V4L2 m2m driver — userspace clients drive S_FMT/REQBUFS/QBUF/DQBUF the standard way. Bitstream flows kernel→daemon as inline REQ_DECODE payload; decoded NV12 pixels flow daemon→kernel as inline RESP_FRAME payload. Works end-to-end for small frames (≤ ~64 KiB NV12).

Deliverable hit: kernel m2m driver passes most v4l2-compliance checks; tools/test_m2m_decode produces a NV12 frame that's byte-for-byte identical to ffmpeg -pix_fmt nv12 reference.

See docs/phase_8_5_closure.md.

Phase 8.6 — dmabuf + AV1 + H.264 + stateless controls

Two interleaved tracks:

Track A (dmabuf):

  • Switch CAPTURE mem_ops to vb2_dma_contig_memops.
  • New DAEDALUS_IOC_GET_DMABUF on the chardev — daemon fetches a dmabuf-fd for the in-flight CAPTURE buffer, mmaps it, decodes pixels in place.
  • RESP_FRAME shrinks to metadata-only; chardev payload stops capping frame size.

Track B (codecs + compliance):

  • AV1 + H.264 codec contexts in the daemon (FFmpeg supports both already).
  • V4L2 stateless controls (VP9_FRAME, AV1_FRAME, H264_SLICE_PARAMS) — even if NULL-handled by the daemon, presence is needed for spec/compliance.
  • Media controller binding via v4l2_m2m_register_media_controller.
  • TRY_FMT colorspace round-trip.

Deliverable: real AV1/H.264 1080p clips decode end-to-end.

Phase 8.7 — performance + 30fps@1080p

  • Profile end-to-end pipeline.
  • Eliminate copies where possible.
  • Hit 30fps@1080p for daily YouTube videos (the project's user-facing success criterion per 30fps-floor-is-fine memory).

Deliverable: 30fps stable on real content.

Effort estimate

Each phase: ~1 week of focused work (~40 hours). Total: 7 weeks for v1.

Could be split across multiple sessions / contributors.