Differences
This shows you the differences between two versions of the page.
| |
| ohm_gl_fix:phase5_review_2026-05-01 [2026/05/01 14:04] – Phase 5 second-model review — Sonnet 4.6 challenges of the four Phase 4 §7 questions markus_fritsche | ohm_gl_fix:phase5_review_2026-05-01 [2026/05/01 16:41] (current) – fix //path// inside code spans (escape with %%) markus_fritsche |
|---|
| ==== Steelman against ==== | ==== Steelman against ==== |
| |
| The plan commits to libva-v4l2-request multiplanar rewrite as the primary path because "Brave is libva." But that conclusion rests entirely on one Phase 3 data point: "libva failed at vaInitialize" for S6 Brave, producing 0 ''VIDIOC_*'' in the strace boundary count. The plan interprets this as "Brave tries libva but libva is broken, so fix libva." The stronger reading of the same evidence is: libva is broken on this device, so Brave has silently fallen back to its non-hardware path already. That path is not libva at all — it's whatever Chromium does when ''VaapiVideoDecoder'' fails its capability check. Chromium's fallback on Linux/Wayland for devices without working VAAPI is typically the ''V4L2VideoDecoder'' (the stateless V4L2 interface exposed via the ''//media/gpu/v4l2/'' stack, distinct from the libva path). The feature flag ''UseChromeOSDirectVideoDecoder'' controls exactly this: on ChromeOS and some Linux builds it bypasses libva entirely and drives V4L2 stateless directly from the GPU process. If Brave's packaged Chromium (M138-class on Arch ARM) has this path compiled in and enabled, then the right fix surface is not libva-v4l2-request at all — it is either (a) verifying that Chromium's built-in ''V4L2VideoDecoder'' is capable of addressing ''/dev/video1'' on RK3566, or (b) enabling the correct feature flags to activate it. This would completely bypass libva and make the 4-8 week multiplanar rewrite irrelevant to Brave's actual path. | The plan commits to libva-v4l2-request multiplanar rewrite as the primary path because "Brave is libva." But that conclusion rests entirely on one Phase 3 data point: "libva failed at vaInitialize" for S6 Brave, producing 0 ''VIDIOC_*'' in the strace boundary count. The plan interprets this as "Brave tries libva but libva is broken, so fix libva." The stronger reading of the same evidence is: libva is broken on this device, so Brave has silently fallen back to its non-hardware path already. That path is not libva at all — it's whatever Chromium does when ''VaapiVideoDecoder'' fails its capability check. Chromium's fallback on Linux/Wayland for devices without working VAAPI is typically the ''V4L2VideoDecoder'' (the stateless V4L2 interface exposed via the ''%%//%%media/gpu/v4l2/'' stack, distinct from the libva path). The feature flag ''UseChromeOSDirectVideoDecoder'' controls exactly this: on ChromeOS and some Linux builds it bypasses libva entirely and drives V4L2 stateless directly from the GPU process. If Brave's packaged Chromium (M138-class on Arch ARM) has this path compiled in and enabled, then the right fix surface is not libva-v4l2-request at all — it is either (a) verifying that Chromium's built-in ''V4L2VideoDecoder'' is capable of addressing ''/dev/video1'' on RK3566, or (b) enabling the correct feature flags to activate it. This would completely bypass libva and make the 4-8 week multiplanar rewrite irrelevant to Brave's actual path. |
| |
| ==== What would have to be true ==== | ==== What would have to be true ==== |
| |
| Brave's Chromium build (packaged in Arch Linux ARM's brave-bin) must have ''//media/gpu/v4l2/v4l2_video_decode_accelerator.cc'' or ''//media/gpu/v4l2/v4l2_stateless_video_decoder.cc'' compiled and linked, and the ''UseChromeOSDirectVideoDecoder'' or ''V4L2FlatStatelessVideoDecoder'' flag must be reachable via command-line feature flags. A secondary condition: the RK3566 V4L2 stateless interface must be enumerable as a ''/dev/videoN'' node with the correct capabilities from Chromium's GPU sandbox. | Brave's Chromium build (packaged in Arch Linux ARM's brave-bin) must have ''%%//%%media/gpu/v4l2/v4l2_video_decode_accelerator.cc'' or ''%%//%%media/gpu/v4l2/v4l2_stateless_video_decoder.cc'' compiled and linked, and the ''UseChromeOSDirectVideoDecoder'' or ''V4L2FlatStatelessVideoDecoder'' flag must be reachable via command-line feature flags. A secondary condition: the RK3566 V4L2 stateless interface must be enumerable as a ''/dev/videoN'' node with the correct capabilities from Chromium's GPU sandbox. |
| |
| ==== Cheapest test ==== | ==== Cheapest test ==== |
| |
| //Phase 5 ends here. Markus reviews and redacts; the next step is either a Phase 4 amendment incorporating the surfaced action items (and possibly pivoting away from libva-v4l2-request if Q1's cheap test fires) or a fresh Phase 4 iteration. Phase 6 implementation does not begin until Phase 4 is locked.// | //Phase 5 ends here. Markus reviews and redacts; the next step is either a Phase 4 amendment incorporating the surfaced action items (and possibly pivoting away from libva-v4l2-request if Q1's cheap test fires) or a fresh Phase 4 iteration. Phase 6 implementation does not begin until Phase 4 is locked.// |
| | |
| |
