Files

T

claude-noether e83298f0da phase 0 deliverables 1-3: SDDM watchpoint, V4L2 inventory, iter8 fork smoke

Three Phase 0 deliverables, three findings worth flagging.

Deliverable #1 — SDDM recovery (phase0_recovery_2026-05-07.md):

Closed as watchpoint, not as root-caused fix. Greeter is green on
this boot — mfritsche has been in Plasma Wayland on tty1 since 20:32.
The "Process crashed (exit code 1)" in journalctl -u sddm is the
post-login greeter teardown, not the pre-login crash described in
~/.claude/plans/dynamic-forging-piglet.md. No coredumps, no qFatal
strings. No package changed since the 2026-04-28 Syyuu; the only
difference between the failing boot and this one is a reboot —
likely a flaky panfrost/GBM cold-init that happened to succeed.
Plan procedures + /var/cache/pacman/pkg rollback candidates remain
ready if regression fires.

Deliverable #2 — V4L2 inventory (phase0_evidence/2026-05-07/
v4l2_inventory_findings.md, raw capture in v4l2_inventory.txt
which is gitignored as raw data):

Full v4l2-ctl --all + --list-ctrls-menus + --list-formats-out per
node, plus media-ctl topology, plus DT compatibles. Authoritative
codec map on running kernel 6.19.9-99-eos-arm:

  /dev/video3 (rkvdec, rockchip,rk3399-vdec):
    OUTPUT_MPLANE: S265 (HEVC), S264 (H.264), VP9F (VP9)
    CAPTURE_MPLANE: NV12

  /dev/video5 (hantro-vpu-dec, rockchip,rk3399-vpu):
    OUTPUT_MPLANE: MG2S (MPEG-2), VP8F (VP8)
    CAPTURE_MPLANE: NV12

This contradicts phase0_findings.md (and README.md), which both
claim hantro-vpu-dec on RK3399 also does H.264. It does not on
this kernel. Open Question #2 from phase0_findings.md ("two-block
H.264 routing") is null on RK3399. Correction commit follows.

Deliverable #3 — iter8 fork build + vainfo (phase0_evidence/
2026-05-07/iter8_build_smoke.md):

Built libva-v4l2-request-fourier master tip 65969da on fresnel
directly (no distcc per locked precedent), gcc 15.2.1, meson 1.11.1,
ninja 1.13.2, libva 1.23.0, libdrm 2.4.131. Clean build, 302 KB
.so, two harmless v4l2.h forward-decl warnings. Installed to
/usr/lib/dri/v4l2_request_drv_video.so. vainfo enumerates:

  rkvdec bind: H.264 {Main, High, ConstrainedBaseline, MultiviewHigh,
                      StereoHigh}, HEVCMain
  hantro-vpu-dec bind: MPEG-2 {Simple, Main}

Substrate is iter8 master, not iter5 as the campaign docs frame —
libva-multiplanar continued past iter5 into iter6-iter8 between the
2026-05-05 iter5 close and the 2026-05-07 fresnel-fourier scaffold.
Building from master inherits per-OUTPUT-slot REINIT, slot-leak
fix, cap_pool harness, msync verify harness, OUTPUT-pool teardown.
Correction commit follows.

HEVC anomaly worth flagging: src/config.c:146-151 probes
V4L2_PIX_FMT_HEVC_SLICE before adding VAProfileHEVCMain. rkvdec
advertises S265 so the probe succeeds; HEVCMain gets enumerated.
But src/meson.build excludes h265.c from the build. A consumer
that calls vaCreateConfig(VAProfileHEVCMain) will succeed (config.c
validation list includes HEVCMain) but actual decode will fault
at dispatch since no h265 symbols are linked. Phase 4 decision:
re-enable h265.c, gate enumeration on a compile-time #ifdef, or
strip enumeration honestly.

Per-codec routing confirmed one-env-var-per-process: request.c:149
reads LIBVA_V4L2_REQUEST_VIDEO_PATH once at init. A single backend
instance binds to either rkvdec or hantro-vpu-dec, not both. Phase 4
will need either a wrapper-script-per-consumer hack or a backend
probe-loop change to route by VAProfile across both decode nodes.

Build infrastructure (gitignore):

Switched from blanket phase*_evidence/ exclude to extension-based
allow-list — track narrative .md, ignore raw .txt/.log/.trace/.pcap/
.bin/.gz/.zst/.json/.dat/.ftrace/.strace. Keeps the V4L2 inventory
text untracked (reproducible from the v4l2-ctl invocation) while
preserving the findings narrative in-repo.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-07 20:54:38 +00:00

5.4 KiB

Raw Permalink Blame History

V4L2 inventory findings — fresnel 2026-05-07

Companion to v4l2_inventory.txt (raw v4l2-ctl / media-ctl / sysfs output captured 2026-05-07T22:34 CEST).

Verified facts

Two decode blocks, six v4l2 nodes total

Node	Driver	DT compatible	Function
`/dev/video0`	`rockchip-rga`	`rockchip,rk3399-rga`	RGA scaler/converter (out of scope)
`/dev/video1`	`uvcvideo`	—	USB camera capture
`/dev/video2`	`uvcvideo`	—	USB camera metadata
`/dev/video3`	`rkvdec`	`rockchip,rk3399-vdec`	Stateless decoder (3 codecs)
`/dev/video4`	`hantro-vpu`	`rockchip,rk3399-vpu`	Encoder (JPEG only)
`/dev/video5`	`hantro-vpu`	`rockchip,rk3399-vpu`	Stateless decoder (2 codecs)

/dev/video4 and /dev/video5 share the parent platform device ff650000.video-codec — same hantro IP, two function instances (enc + dec).

Decoder codec surface (authoritative — from `--list-formats-out`)

/dev/video3 (rkvdec) — three codecs:

[0]: 'S265' (HEVC Parsed Slice Data, compressed)
[1]: 'S264' (H.264 Parsed Slice Data, compressed)
[2]: 'VP9F' (VP9 Frame, compressed)

CAPTURE: NV12 only.

/dev/video5 (hantro-vpu-dec) — two codecs:

[0]: 'MG2S' (MPEG-2 Parsed Slice Data, compressed)
[1]: 'VP8F' (VP8 Frame, compressed)

CAPTURE: NV12 only.

Profile/level menus (from `--list-ctrls-menus`)

rkvdec exposes:

H.264 profiles: Constrained Baseline, Main, High, High 10, High 422, High 10 Intra, High 422 Intra. Levels 1 through 5.1 (16 entries). Note: 10-bit/422 entries listed are kernel-driver enumeration, not necessarily silicon-supported — the rkvdec driver may reject these at request submission.
HEVC profiles: Main, Main Still Picture, Main 10. Levels 1 through 5.1 (9 entries).
VP9 profile: 0 only (8-bit 4:2:0). No profile-2 (10-bit), profile-1 (4:4:4), or profile-3 listed.

hantro-vpu-dec exposes no profile/level menus — MPEG-2 and VP8 don't need them.

Stateless control payloads

rkvdec accepts:

H.264: H264_DECODE_MODE (Frame-Based), H264_START_CODE (Annex B), SPS, PPS, scaling matrix, decode params.
HEVC: HEVC_DECODE_MODE (Frame-Based), HEVC_START_CODE (Annex B), SPS, PPS, slice params (dynamic-array, max 600 elems), scaling matrix, decode params.
VP9: VP9_FRAME (frame decode params), VP9_PROBABILITIES_UPDATES (control type 260).

hantro-vpu-dec accepts:

VP8: VP8_FRAME (frame decode params).
MPEG-2: MPEG_2_SEQUENCE_HEADER, MPEG_2_PICTURE_HEADER, MPEG_2_QUANTISATION_MATRICES.

Both drivers report value=unsupported payload type from v4l2-ctl for compound controls — normal; v4l2-ctl can't serialize them, the kernel ABI uses VIDIOC_S_EXT_CTRLS with V4L2_CTRL_WHICH_REQUEST_VAL.

Media controller topology

/dev/media0 → uvcvideo (USB cam), entities 1/4/8/11/14.
/dev/media1 → rkvdec, simple source→proc→sink (3 entities).
/dev/media2 → hantro-vpu, holds both enc and dec sub-pipelines under one media device. Decode sub-pipeline: entities 15/17/20 (rockchip,rk3399-vpu-dec-source → -proc → -sink). Encode sub-pipeline: entities 1/3/6.

For per-codec media_path resolution the libva backend can use either fixed device-node paths (simple) or media-controller graph traversal (matches Bootlin sunxi-cedrus pattern). Phase 4 design decision.

Corrections required in locked Phase 0 docs

phase0_findings.md lines 26–28 and README.md:24–28 claim hantro-vpu-dec on RK3399 supports H.264 (V4L2_PIX_FMT_H264_SLICE). This is wrong on the running kernel 6.19.9-99-eos-arm. The actual surface is MPEG-2 + VP8 only.

Implications:

Open Question #2 from phase0_findings.md is null — there's no two-block H.264 routing decision to make. H.264 only goes to rkvdec on RK3399. The libva backend's device-selection logic for H.264 has exactly one valid bind target.
The "test cells per codec" sentence ("Two test cells per codec: rkvdec-bound H.264 and hantro-vpu-dec-bound H.264.") should be reduced to one cell.
Codec scope as locked stays correct in count — five codecs, just routed differently:
- rkvdec: H.264, HEVC, VP9
- hantro-vpu-dec: MPEG-2, VP8

These corrections should land as a follow-up commit on this campaign repo. Not done in this file to keep evidence and source-of-truth separable.

Why the doc was wrong

Likely carryover from RK3568 (ohm) hantro, which does support H.264 (DT compatible rockchip,rk3568-vpu). The RK3399 hantro IP / kernel variant in drivers/media/platform/verisilicon/ registers a different codec list. The phase0_findings.md table was written without empirical enumeration on this kernel.

Gaps left for Phase 1+

Resolution range per codec — not enumerated by v4l2-ctl --list-formats-out directly. Will need v4l2-ctl --try-fmt-out-mplane probes against rkvdec to find min/max width/height per codec, especially HEVC (4K+ would matter for VP9 but the panel is 1080p so probably moot).
Per-codec slice-mode vs. frame-mode capability — both decoders advertise frame-based only (*_DECODE_MODE menu min=1 max=1 default=1 (Frame-Based)). This matches the libva-v4l2-request-fourier fork's slice-buffer accumulation pattern from libva-multiplanar iter4.
Bit-depth limits — H264_HIGH_10 profile is enumerated on rkvdec but RK3399 silicon doesn't do 10-bit H.264. Test will reveal whether the driver rejects 10-bit submission or just silently produces garbage.

5.4 KiB Raw Permalink Blame History Unescape Escape