kernel: register H.264 DECODE_MODE + START_CODE menu controls #4

2026-05-21T09:02:08Z

marfrit commented

2026-05-21 09:02:08 +00:00

Symptom

With firefox-fourier playing H.264 YouTube through the daedalus daemon path, every Firefox process logs (once per context init):

v4l2-request: Unable to set control(s): Invalid argument (error_idx=2/2 ioctl-level)

Cause

libva-v4l2-request-fourier sets two H.264 device-wide controls in src/context.c:577–589 at context init time, before any per-request controls are bound:

V4L2_CID_STATELESS_H264_DECODE_MODE = FRAME_BASED
V4L2_CID_STATELESS_H264_START_CODE = ANNEX_B

The call is v4l2_set_controls(video_fd, -1, dev_ctrls, 2), cast to (void) — libva treats failures as best-effort and continues. But our daedalus_stateless_ctrls[] registers SPS/PPS/SCALING_MATRIX/PRED_WEIGHTS/SLICE_PARAMS/DECODE_PARAMS only — not these two menu controls. v4l2-core's S_EXT_CTRLS validate step then returns EINVAL for both, producing the noisy warning.

No functional impact: the daemon already operates as FRAME_BASED + ANNEX_B (it consumes a full frame per REQ_DECODE and the H.264 SPS/PPS synthesiser prepends Annex-B-delimited NAL units), and the per-request SPS/PPS/SCALING_MATRIX/DECODE_PARAMS batch lands fine — Firefox playback through the daedalus path on Pi CM5 succeeds despite the warning.

Change

Register both as v4l2_ctrl_new_std_menu with the single value each the daemon actually accepts; mask out the unsupported alternate (SLICE_BASED, NONE). This matches the rkvdec / hantro pattern. Capacity hint on v4l2_ctrl_handler_init bumped to ARRAY_SIZE(daedalus_stateless_ctrls) + 2.

Verification

Built clean against 6.18.29+rpt-rpi-2712 on higgs (Pi CM5).
No frame-size warnings introduced (pre-existing one on daedalus_device_run is unchanged).
Field-test: pending — the running daemon on higgs is currently driving live YouTube playback; will swap the module in once the user signals it's OK to interrupt (or it lands via the next daedalus-v4l2-dkms bump).

Closes the cosmetic gap surfaced during 2026-05-21 Pi CM5 verification (Phase 8.10 chain alive end-to-end after DKMS rebuild).

## Symptom With firefox-fourier playing H.264 YouTube through the daedalus daemon path, every Firefox process logs (once per context init): ``` v4l2-request: Unable to set control(s): Invalid argument (error_idx=2/2 ioctl-level) ``` ## Cause libva-v4l2-request-fourier sets two H.264 device-wide controls in `src/context.c:577–589` at context init time, before any per-request controls are bound: - `V4L2_CID_STATELESS_H264_DECODE_MODE = FRAME_BASED` - `V4L2_CID_STATELESS_H264_START_CODE = ANNEX_B` The call is `v4l2_set_controls(video_fd, -1, dev_ctrls, 2)`, cast to `(void)` — libva treats failures as best-effort and continues. But our `daedalus_stateless_ctrls[]` registers SPS/PPS/SCALING_MATRIX/PRED_WEIGHTS/SLICE_PARAMS/DECODE_PARAMS only — not these two menu controls. v4l2-core's `S_EXT_CTRLS` validate step then returns EINVAL for both, producing the noisy warning. No functional impact: the daemon already operates as FRAME_BASED + ANNEX_B (it consumes a full frame per `REQ_DECODE` and the H.264 SPS/PPS synthesiser prepends Annex-B-delimited NAL units), and the per-request SPS/PPS/SCALING_MATRIX/DECODE_PARAMS batch lands fine — Firefox playback through the daedalus path on Pi CM5 succeeds despite the warning. ## Change Register both as `v4l2_ctrl_new_std_menu` with the single value each the daemon actually accepts; mask out the unsupported alternate (SLICE_BASED, NONE). This matches the rkvdec / hantro pattern. Capacity hint on `v4l2_ctrl_handler_init` bumped to `ARRAY_SIZE(daedalus_stateless_ctrls) + 2`. ## Verification - Built clean against `6.18.29+rpt-rpi-2712` on higgs (Pi CM5). - No frame-size warnings introduced (pre-existing one on `daedalus_device_run` is unchanged). - Field-test: pending — the running daemon on higgs is currently driving live YouTube playback; will swap the module in once the user signals it's OK to interrupt (or it lands via the next `daedalus-v4l2-dkms` bump). Closes the cosmetic gap surfaced during 2026-05-21 Pi CM5 verification (Phase 8.10 chain alive end-to-end after DKMS rebuild).

marfrit added 1 commit 2026-05-21 09:02:09 +00:00

kernel: register H.264 DECODE_MODE + START_CODE menu controls 69a62a922f

libva-v4l2-request sets V4L2_CID_STATELESS_H264_DECODE_MODE and
V4L2_CID_STATELESS_H264_START_CODE on the device fd at context init
(see libva-v4l2-request-fourier src/context.c:577 — best-effort call,
result is (void)cast).  Our ctrl_handler did not advertise either
control, so v4l2-core returned EINVAL on validate; userspace logged
the noisy

    v4l2-request: Unable to set control(s): Invalid argument
                  (error_idx=2/2 ioctl-level)

at every Firefox/ffmpeg context creation, despite decode itself
succeeding (the daemon already operates as FRAME_BASED + ANNEX_B and
the per-request SPS/PPS/SCALING_MATRIX/DECODE_PARAMS batch lands
fine).

Register the two as v4l2_ctrl_new_std_menu with the only value each
the daemon actually supports — FRAME_BASED for DECODE_MODE,
ANNEX_B for START_CODE — and mask out the unsupported alternates
(SLICE_BASED, NONE).  Pattern matches rkvdec / hantro.  Update the
handler-init capacity hint to ARRAY_SIZE(daedalus_stateless_ctrls)
+ 2 to cover the additions.

Verified: builds clean on 6.18.29+rpt-rpi-2712 (Pi CM5) DKMS source
tree.

marfrit merged commit 7ff2d897ea into main

2026-05-21 09:02:43 +00:00

marfrit deleted branch noether/kernel-h264-menu-ctrls

2026-05-21 09:02:43 +00:00

marfrit referenced this issue from a commit

2026-05-21 09:02:45 +00:00

Merge pull request 'kernel: register H.264 DECODE_MODE + START_CODE menu controls' (#4) from noether/kernel-h264-menu-ctrls into main

marfrit referenced this pull request

2026-05-21 09:29:52 +00:00

Firefox VAAPI present path: NV12 dmabuf zero-copy not engaging; YUV→RGB lands CPU-side, stalls the daemon decode loop #5

claude-noether referenced this issue from a commit

2026-05-21 10:41:35 +00:00