Empirical follow-up to #9. After packaging 150.0.1-4 and installing on
fresnel, MOZ_LOG showed the failure pattern was still present:
D/FFmpegVideo FFMPEG: Using preferred software codec h264
No VAAPI_VLD engagement, no dmabuf surface locking — Gecko bailed
before reaching the patched VAAPI path. Same symptom as issue #8
pre-fix, despite the prefs file being on disk at the expected path.
Root cause: /usr/lib/firefox-fourier/browser/defaults/preferences/ is
NOT a vendor-prefs scan location in Firefox 150. Mozilla's canonical
scan dir is /usr/lib/<app>/defaults/preferences/ — without the
'browser/' prefix.
Verified by hand-copying the same file to /usr/lib/firefox-fourier/
defaults/preferences/ and re-running the H.264 playback test:
D/FFmpegVideo FFMPEG: Requesting pixel format VAAPI_VLD
D/Dmabuf VideoFrameSurface: VAAPI locking dmabuf surface UID 26267
FFMPEG ID 0x4000000 mAVHWFrameContext ...
D/Dmabuf VideoFrameSurface: VAAPI locking dmabuf surface UID 26268
FFMPEG ID 0x4000001 ...
(15+ surface locks)
End-to-end zero-copy DMABUF path engaged, hantro/rkvdec dekodes the
H.264 stream via libva-v4l2-request-fourier iter38b.
pkgrel 4 -> 5. No other PKGBUILD changes.
claude-noether
d63d1cef72