Files
claude-noether 0b2393cecc libva-v4l2-request-ohm-gl-fix: mark deprecated, point at -fourier
Predecessor experimental package (tarball + 18 stacked patches) is
superseded by libva-v4l2-request-fourier (git-tracked fork tip,
iter38 multi-device probe). The successor already declares
replaces=('libva-v4l2-request-ohm-gl-fix') so installs migrate
automatically; this commit just makes the deprecation visible in
README + pkgdesc.

Kept in-tree as historical reference for the ohm_gl_fix Phase 6
audit trail.
2026-05-17 01:00:25 +02:00

78 lines
3.4 KiB
Markdown

# libva-v4l2-request-ohm-gl-fix
> ## ⚠ DEPRECATED — use [`libva-v4l2-request-fourier`](../libva-v4l2-request-fourier/) instead
>
> This package is the **predecessor experimental** build (tarball pin
> + 18 stacked patches) and is no longer maintained as of 2026-05-16.
> Its successor `libva-v4l2-request-fourier` tracks the campaign fork's
> git history directly
> ([git.reauktion.de/marfrit/libva-v4l2-request-fourier](https://git.reauktion.de/marfrit/libva-v4l2-request-fourier))
> so iteration sweeps (DEBUG removal, follow-up bugfixes) land in a clean
> linear log, and adds the iter38 multi-device probe that lets a single
> libva session serve rkvdec H.264/HEVC/VP9 + hantro MPEG-2/VP8 without
> needing `LIBVA_V4L2_REQUEST_VIDEO_PATH` overrides.
>
> `libva-v4l2-request-fourier` declares
> `replaces=('libva-v4l2-request-ohm-gl-fix')`, so installing it will
> remove this package automatically. Kept in-tree as historical reference
> for the ohm_gl_fix Phase 6 audit trail.
---
Bootlin's libva-v4l2-request VA-API backend, with hantro-vpu
multi-planar + chromium-149-era stateless H.264 patches developed
in the [ohm_gl_fix campaign](../../../ohm_gl_fix/) Phase 6 Step 1
(2026-05-01..2026-05-02).
Patches 0001-0018 are contract-correct against the kernel V4L2
stateless H.264 UAPI, validated by inspection against
hantro_h264.c and v4l2_h264_init_reflist_builder() in linux 6.19.x.
See ohm_gl_fix's `phase6/step1/audit_0008_decode_params_2026-05-01.md`
and `phase6/step1/api_contract_findings_2026-05-01.md` for the
audit trail.
## Honest characterisation
This package compiles cleanly, installs cleanly, and `vainfo` with
`LIBVA_DRIVER_NAME=v4l2_request LIBVA_V4L2_REQUEST_VIDEO_PATH=/dev/video1`
enumerates all H.264 profiles. It is, however, **not on Brave's
critical decode path** on the ohm_gl_fix Step-1+Step-2 stack —
Brave/Chromium uses its own `V4L2VideoDecoder` in
`media/gpu/v4l2/`, opens `/dev/video1` directly, and never loads
libva. See `phase3_remeasure_2026-05-02/B3_decoder_discovery.md`
in the ohm_gl_fix repo for the strace/maps evidence.
For libva consumers that DO route through libva (mpv with
`--hwdec=vaapi`, ffmpeg-vaapi, Firefox with
`media.ffmpeg.vaapi.enabled=true`), this backend would in
principle engage hantro hardware decode — but each consumer hits
its own downstream issue:
- mpv `--vo=gpu-next`: blocked by a Mesa-panfrost WSI pitch bug
during EGL dmabuf import (out of scope for this package; see
`phase3_remeasure_2026-05-02/A3_mesa_wsi_pitch.md`).
- mpv `--vo=image`: silently falls back to libavcodec SW decode
rather than engaging the libva session (see
`phase3_remeasure_2026-05-02/A1_morning_pass_disambiguation.md`).
Reason not yet diagnosed.
The most likely use case where this backend cleanly delivers
hardware decode end-to-end is **Firefox via libavcodec-vaapi**, on
a stack that also has the Mesa pitch issue resolved (or that
doesn't hit the EGL import path because Firefox's video element
composites differently). Untested at time of writing.
## DEBUG patches in the series
`0010-DEBUG-hex-dump-output-capture.patch`,
`0011-DEBUG-sentinel-capture-buffer.patch`, and
`0014-DEBUG-vapic-bytes-dump.patch` produce verbose stderr output
useful for diagnosing decode-path issues but excessive for
production. They are intentionally kept in the applied series
during development; remove for cleaner runs.
## Status
Tagged stable as of 2026-05-02 against chromium-149 / linux-6.19.10
/ libva-2.22.0. Contract-correct; ecosystem-validation-pending.