6f4b580f7c
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>
101 lines
3.2 KiB
Markdown
101 lines
3.2 KiB
Markdown
# 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.
|