test0r
b47938e0bc
build and publish packages / distcc-avahi-aarch64 (push) Successful in 1m3s
build and publish packages / lmcp-any (push) Successful in 9s
build and publish packages / lmcp-debian (push) Successful in 4s
build and publish packages / claude-his-any (push) Failing after 4s
build and publish packages / ffmpeg-v4l2-request-aarch64 (push) Has been skipped
build and publish packages / claude-his-debian (push) Has been skipped
Mirrors phase6/step1/ from the ohm_gl_fix campaign. Contract-correct
hantro multi-planar / chromium-149-era stateless H.264 port of
bootlin's libva-v4l2-request, patches 0001..0018 + fourier-local.
Honest characterisation in README:
- Builds cleanly on chromium-builder LXC (boltzmann)
- vainfo enumerates H.264 profiles cleanly with LIBVA_DRIVER_NAME=v4l2_request
- NOT on Brave's decode path on ohm_gl_fix stack — Brave uses
Chromium's own V4L2VideoDecoder in media/gpu/v4l2/.
- Most likely useful for a future Firefox-via-libavcodec-vaapi
campaign, modulo a separate Mesa-panfrost WSI pitch issue.
- DEBUG patches (0010, 0011, 0014) intentionally kept in series
for development; remove for cleaner production runs.
Audit trail in the source repo at ohm_gl_fix:
phase6/step1/audit_0008_decode_params_2026-05-01.md
phase6/step1/api_contract_findings_2026-05-01.md
phase3_remeasure_2026-05-02/B3_decoder_discovery.md (why this
isn't on Brave's path)
54 lines
2.0 KiB
Diff
54 lines
2.0 KiB
Diff
From: Markus Fritsche <fritsche.markus@gmail.com>
|
||
Date: 2026-05-01
|
||
Subject: [PATCH] DEBUG: sentinel-pattern test for CAPTURE buffer write
|
||
|
||
Diagnostic-only. Writes 0xab×32 into the CAPTURE buffer's first 32
|
||
bytes immediately before VIDIOC_QBUF. The 0010 hex-dump after
|
||
DQBUF reveals which case we're in:
|
||
|
||
- All 0xab → kernel never wrote to this buffer (wrong buffer
|
||
chosen, alias, or no decode actually happened despite
|
||
bytesused=3655712 reported).
|
||
- All zeros → kernel did write 0x00s (overwriting our
|
||
sentinel), and the apparent "no picture" output is the
|
||
kernel-side decode actually producing zeros (e.g. parser
|
||
rejected the bitstream).
|
||
- Mix of zeros and real luma values → kernel wrote real
|
||
decoded pixels; CPU read sees stale-cached zeros somewhere
|
||
OR the sentinel area was a header that decoder zeroed but
|
||
rest is real. Need to check more bytes.
|
||
- All 0xab still → kernel never touched this region but other
|
||
parts of buffer may be filled (incomplete decode).
|
||
|
||
Removed once Step 1 decode is verified.
|
||
|
||
Signed-off-by: Markus Fritsche <fritsche.markus@gmail.com>
|
||
---
|
||
--- a/src/picture.c 2026-05-01 21:50:11.123117853 +0000
|
||
+++ b/src/picture.c 2026-05-01 22:20:20.589037667 +0000
|
||
@@ -349,6 +349,24 @@
|
||
if (rc != VA_STATUS_SUCCESS)
|
||
return rc;
|
||
|
||
+ /*
|
||
+ * DEBUG INSTRUMENTATION (0011): write a sentinel pattern into
|
||
+ * the CAPTURE buffer's first 32 bytes BEFORE QBUF. If after
|
||
+ * DQBUF the sentinel survives (per surface.c hex dump), the
|
||
+ * kernel never wrote to this buffer. If the sentinel is gone
|
||
+ * (replaced by zeros), the kernel did write but our CPU read
|
||
+ * sees stale-cached data — cache-coherency issue.
|
||
+ */
|
||
+ {
|
||
+ unsigned char *p = (unsigned char *)
|
||
+ surface_object->destination_map[0];
|
||
+ if (p != NULL) {
|
||
+ unsigned int i;
|
||
+ for (i = 0; i < 32; i++)
|
||
+ p[i] = 0xab;
|
||
+ }
|
||
+ }
|
||
+
|
||
rc = v4l2_queue_buffer(driver_data->video_fd, -1, capture_type, NULL,
|
||
surface_object->destination_index, 0,
|
||
surface_object->destination_buffers_count);
|