marfrit/marfrit-packages
0
0
Fork 1
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

firefox-fourier: vendor-prefs install path correction (browser/defaults -> defaults) #13

Merged
marfrit merged 1 commits from claude-noether/marfrit-packages:noether/firefox-fourier-vendor-prefs-correct-path into main 2026-05-15 14:23:32 +00:00
Conversation 0 Commits 1 Files Changed 1
+9 -2
claude-noether commented 2026-05-15 14:18:33 +00:00
Contributor
Copy Link
Copy Source

Empirical follow-up to #9 — caught while installing & testing 150.0.1-4 on fresnel.

The symptom

MOZ_LOG of a fresh-profile H.264 playback on fresnel after pacman -S firefox-fourier:

D/FFmpegVideo FFMPEG: Using preferred software codec h264
D/FFmpegVideo FFMPEG: Using preferred software codec vp9
D/FFmpegVideo FFMPEG: Using preferred software codec vp8

Exactly the issue #8 failure pattern. PDM init order in the RDD child showed FFmpeg(FFVPX) > FFmpeg(OS) > Agnostic — no VAAPI PDM at all. The patched code path never reached.

The cause

The vendor-prefs file landed at /usr/lib/firefox-fourier/browser/defaults/preferences/rockchip-fourier-defaults.js per #9. That path is not a vendor-prefs scan location in Firefox 150 — I had guessed wrong. Mozilla's canonical scan dir is /usr/lib/<app>/defaults/preferences/ (no browser/ prefix).

The verification

Copied the same file to /usr/lib/firefox-fourier/defaults/preferences/ and re-ran the test. MOZ_LOG immediately showed engagement:

D/FFmpegVideo FFMPEG: Requesting pixel format VAAPI_VLD
D/Dmabuf VideoFrameSurface: VAAPI locking dmabuf surface UID 26267 FFMPEG ID 0x4000000
D/Dmabuf VideoFrameSurface: VAAPI locking dmabuf surface UID 26268 FFMPEG ID 0x4000001
D/Dmabuf VideoFrameSurface: VAAPI locking dmabuf surface UID 26269 FFMPEG ID 0x4000002
...

15+ DMABUF surface locks across two MediaPDecoder threads. End-to-end zero-copy via libva-v4l2-request-fourier iter38b → hantro/rkvdec H.264 decode.

What this PR does

Single-line install-path correction:

  • Before: ${pkgdir}/usr/lib/firefox-fourier/browser/defaults/preferences/rockchip-fourier-defaults.js
  • After: ${pkgdir}/usr/lib/firefox-fourier/defaults/preferences/rockchip-fourier-defaults.js

Plus an inline comment documenting the empirical finding so a future me/you doesn't fall for the same path again.

pkgrel 4 → 5. Vendor-prefs file content unchanged.

Postmortem note

The issue body's "Alternative" mentioned /usr/lib/firefox-fourier/defaults/pref/ (singular pref). I instinctively reached for browser/defaults/preferences/ because it looked more "modern-Firefox". Should have stuck closer to what the issue actually suggested. Adding to the "verify, don't infer" memory pile.

Bot: claude-noether

Empirical follow-up to #9 — caught while installing & testing 150.0.1-4 on fresnel. ## The symptom MOZ_LOG of a fresh-profile H.264 playback on fresnel after `pacman -S firefox-fourier`: ``` D/FFmpegVideo FFMPEG: Using preferred software codec h264 D/FFmpegVideo FFMPEG: Using preferred software codec vp9 D/FFmpegVideo FFMPEG: Using preferred software codec vp8 ``` Exactly the issue #8 failure pattern. PDM init order in the RDD child showed `FFmpeg(FFVPX) > FFmpeg(OS) > Agnostic` — no VAAPI PDM at all. The patched code path never reached. ## The cause The vendor-prefs file landed at `/usr/lib/firefox-fourier/browser/defaults/preferences/rockchip-fourier-defaults.js` per #9. That path is **not** a vendor-prefs scan location in Firefox 150 — I had guessed wrong. Mozilla's canonical scan dir is `/usr/lib/<app>/defaults/preferences/` (no `browser/` prefix). ## The verification Copied the same file to `/usr/lib/firefox-fourier/defaults/preferences/` and re-ran the test. MOZ_LOG immediately showed engagement: ``` D/FFmpegVideo FFMPEG: Requesting pixel format VAAPI_VLD D/Dmabuf VideoFrameSurface: VAAPI locking dmabuf surface UID 26267 FFMPEG ID 0x4000000 D/Dmabuf VideoFrameSurface: VAAPI locking dmabuf surface UID 26268 FFMPEG ID 0x4000001 D/Dmabuf VideoFrameSurface: VAAPI locking dmabuf surface UID 26269 FFMPEG ID 0x4000002 ... ``` 15+ DMABUF surface locks across two MediaPDecoder threads. End-to-end zero-copy via libva-v4l2-request-fourier iter38b → hantro/rkvdec H.264 decode. ## What this PR does Single-line install-path correction: - Before: `${pkgdir}/usr/lib/firefox-fourier/browser/defaults/preferences/rockchip-fourier-defaults.js` - After: `${pkgdir}/usr/lib/firefox-fourier/defaults/preferences/rockchip-fourier-defaults.js` Plus an inline comment documenting the empirical finding so a future me/you doesn't fall for the same path again. pkgrel 4 → 5. Vendor-prefs file content unchanged. ## Postmortem note The issue body's "Alternative" mentioned `/usr/lib/firefox-fourier/defaults/pref/` (singular `pref`). I instinctively reached for `browser/defaults/preferences/` because it looked more "modern-Firefox". Should have stuck closer to what the issue actually suggested. Adding to the "verify, don't infer" memory pile. Bot: claude-noether
claude-noether added 1 commit 2026-05-15 14:18:33 +00:00
firefox-fourier: move vendor-prefs to defaults/preferences/ (the path Firefox actually scans) d63d1cef72 
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.
marfrit merged commit 201e671d61 into main 2026-05-15 14:23:32 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
marfrit (Markus Fritsche)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marfrit/marfrit-packages#13
Delete Branch "claude-noether/marfrit-packages:noether/firefox-fourier-vendor-prefs-correct-path"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?