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

firefox-fourier patch #3: accept AV_HWDEVICE_TYPE_V4L2REQUEST too #61

Merged
marfrit merged 1 commits from fix/firefox-v4l2request-type-accept-2026-05-21 into main 2026-05-21 04:18:29 +00:00
Conversation 3 Commits 1 Files Changed 1
+75 -48
marfrit commented 2026-05-20 22:10:12 +00:00
Owner
Copy Link
Copy Source

Closes part of #60 (firefox-side patch update for fourier2 ffmpeg).

libavcodec61-fourier2 registers hwaccels with AV_HWDEVICE_TYPE_V4L2REQUEST (FFmpeg 7.1+ dedicated enum), not AV_HWDEVICE_TYPE_DRM as fourier1 did. Firefox patch walked hw_configs looking only for DRM → fell through to SW.

Changes: CreateV4L2RequestDeviceContext takes int aDeviceType (Mozilla bundled headers may lack the enum), hw_configs walk accepts DRM OR V4L2REQUEST (int values 13 Kwiboo, 14 upstream-AMF), member renamed mDRMDeviceContext → mV4L2RequestDeviceContext.

+75/-48 lines, all internal-to-patch-3.

Closes part of #60 (firefox-side patch update for fourier2 ffmpeg). libavcodec61-fourier2 registers hwaccels with `AV_HWDEVICE_TYPE_V4L2REQUEST` (FFmpeg 7.1+ dedicated enum), not `AV_HWDEVICE_TYPE_DRM` as fourier1 did. Firefox patch walked hw_configs looking only for DRM → fell through to SW. Changes: `CreateV4L2RequestDeviceContext` takes `int aDeviceType` (Mozilla bundled headers may lack the enum), hw_configs walk accepts DRM OR V4L2REQUEST (int values 13 Kwiboo, 14 upstream-AMF), member renamed `mDRMDeviceContext` → `mV4L2RequestDeviceContext`. +75/-48 lines, all internal-to-patch-3.
marfrit added 1 commit 2026-05-20 22:10:12 +00:00
firefox-fourier patch #3: accept AV_HWDEVICE_TYPE_V4L2REQUEST too 5f21a71770 
Closes part of #60 (firefox-side patch update for fourier2 ffmpeg).

Background: libavcodec61-fourier2 (Kwiboo v4l2-request-n7.1.3 backed)
registers its hwaccels with AV_HWDEVICE_TYPE_V4L2REQUEST (the dedicated
enum added in FFmpeg 7.1+), not AV_HWDEVICE_TYPE_DRM as fourier1 did.
The firefox-fourier patch #3 walked hw_configs looking only for DRM
and fell through to software for every codec.

Patch updates:
- CreateV4L2RequestDeviceContext now takes an int aDeviceType (Mozillas
  bundled libavutil headers may lack the V4L2REQUEST enumerator), passed
  through to av_hwdevice_ctx_create.
- hw_configs walk accepts DRM (legacy) OR V4L2REQUEST integer value
  (13 on Kwibooss no-AMF tree, 14 on upstream-AMF tree).
- Renamed mDRMDeviceContext to mV4L2RequestDeviceContext for accuracy.

Build pkgrel will be bumped at debian-package level to +fourier2.
claude-noether commented 2026-05-21 00:22:40 +00:00
Contributor
Copy Link
Copy Source

Verified end-to-end on higgs (autonomous 02:17 test) that the currently-installed firefox 1:150.0.3-1+rpt1+fourier2 hits exactly the gap this PR addresses. After the test ran (apt update + restart daedalus + relaunch firefox against /tmp/bbb-test.html with MOZ_LOG decoder tracing):

=== per-codec Supported hardware devices ===
  h264         cuda vaapi vdpau vulkan v4l2request
  hevc         cuda vaapi vdpau vulkan v4l2request
  vp9          cuda vaapi vdpau v4l2request
  vp8          vaapi cuda v4l2request
  av1          cuda vaapi vdpau vulkan v4l2request
  mpeg2video   cuda vaapi vdpau v4l2request
=== daemon over 20s ===  REQ_DECODE=0 decoder:OK=0
=== Firefox decoder lines ===
[RDD ...]: Using preferred software codec h264 (x repeats)
VERDICT: ❌ FAIL — software fallback

All six codecs advertise v4l2request in their hwaccel list (the new dedicated AV_HWDEVICE_TYPE_V4L2REQUEST type — value 13 on Kwiboo's tree per the patch's V4L2REQUEST_KWIBOO constant). Firefox's current 0003 walk only matches AV_HWDEVICE_TYPE_DRM, so the walk falls through and every codec lands on SW. This PR's expanded acceptance (DRM OR V4L2REQUEST_KWIBOO OR V4L2REQUEST_UPSTREAM) plugs exactly that.

The patch shape is clean:

  • raw-int comparison via cast lets it compile against Mozilla's bundled libavutil headers even when the V4L2REQUEST enumerator isn't declared
  • the added AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX check is the missing prereq before binding hw_device_ctx
  • variable rename mDRMDeviceContext → mV4L2RequestDeviceContext matches the new generality

Sequencing flag

The commit message ends with "Build pkgrel will be bumped at debian-package level to +fourier2." But higgs currently has firefox 1:150.0.3-1+rpt1+fourier2 installed — that's the build with the broken patch. For apt to see the rebuild, the next package needs to land as +fourier3 (or +fourier2 with a pkgrel bump, e.g. 1+rpt1+fourier2~2). Likely just a typo in the commit message — flagging so the rebuild lands at a version higgs will actually pull.

Once merged + rebuilt + installed on higgs, the same autonomous test (/tmp/test-firefox-hwdecode.sh) should flip to ✅ PASS with daemon REQ_DECODE traffic at H.264 30fps.

Verified end-to-end on higgs (autonomous 02:17 test) that the currently-installed firefox `1:150.0.3-1+rpt1+fourier2` hits exactly the gap this PR addresses. After the test ran (apt update + restart daedalus + relaunch firefox against /tmp/bbb-test.html with MOZ_LOG decoder tracing): ``` === per-codec Supported hardware devices === h264 cuda vaapi vdpau vulkan v4l2request hevc cuda vaapi vdpau vulkan v4l2request vp9 cuda vaapi vdpau v4l2request vp8 vaapi cuda v4l2request av1 cuda vaapi vdpau vulkan v4l2request mpeg2video cuda vaapi vdpau v4l2request === daemon over 20s === REQ_DECODE=0 decoder:OK=0 === Firefox decoder lines === [RDD ...]: Using preferred software codec h264 (x repeats) VERDICT: ❌ FAIL — software fallback ``` All six codecs advertise `v4l2request` in their hwaccel list (the new dedicated `AV_HWDEVICE_TYPE_V4L2REQUEST` type — value 13 on Kwiboo's tree per the patch's V4L2REQUEST_KWIBOO constant). Firefox's current `0003` walk only matches `AV_HWDEVICE_TYPE_DRM`, so the walk falls through and every codec lands on SW. This PR's expanded acceptance (DRM OR V4L2REQUEST_KWIBOO OR V4L2REQUEST_UPSTREAM) plugs exactly that. The patch shape is clean: - raw-int comparison via cast lets it compile against Mozilla's bundled libavutil headers even when the V4L2REQUEST enumerator isn't declared - the added `AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX` check is the missing prereq before binding `hw_device_ctx` - variable rename mDRMDeviceContext → mV4L2RequestDeviceContext matches the new generality ### Sequencing flag The commit message ends with *"Build pkgrel will be bumped at debian-package level to +fourier2."* But higgs currently has firefox `1:150.0.3-1+rpt1+fourier2` installed — that's the build with the broken patch. For apt to see the rebuild, the next package needs to land as `+fourier3` (or `+fourier2` with a pkgrel bump, e.g. `1+rpt1+fourier2~2`). Likely just a typo in the commit message — flagging so the rebuild lands at a version higgs will actually pull. Once merged + rebuilt + installed on higgs, the same autonomous test (/tmp/test-firefox-hwdecode.sh) should flip to ✅ PASS with daemon REQ_DECODE traffic at H.264 30fps.
marfrit merged commit a640633ea7 into main 2026-05-21 04:18:29 +00:00
marfrit deleted branch fix/firefox-v4l2request-type-accept-2026-05-21 2026-05-21 04:18:29 +00:00
marfrit commented 2026-05-21 04:29:21 +00:00
Author
Owner
Copy Link
Copy Source

Closing — the hand-written 0003 update in this PR has malformed hunk offsets (patch: malformed patch at line 231). Build pipeline shipped the same logical change via in-source sed in the firefox-rpios build script (v8 → fourier2 published to trixie pool, installed on higgs).

Proper patch follow-up: regenerate via real firefox source tree (apply 0001-0005, edit manually, git diff against pre-edit baseline). Tracked separately as a marfrit-packages TODO.

Closing — the hand-written 0003 update in this PR has malformed hunk offsets (`patch: malformed patch at line 231`). Build pipeline shipped the same logical change via in-source sed in the firefox-rpios build script (v8 → fourier2 published to trixie pool, installed on higgs). Proper patch follow-up: regenerate via real firefox source tree (apply 0001-0005, edit manually, git diff against pre-edit baseline). Tracked separately as a marfrit-packages TODO.
claude-noether commented 2026-05-21 08:07:36 +00:00
Contributor
Copy Link
Copy Source

Retracting this comment — wrong diagnosis.

Verified on higgs (Pi CM5) that the cause of Codec X is not accelerated / IsHardwareAccelerated=0 is NOT a probe-side gap in GetAcceleratedFormats or any Firefox patch deficiency. It is purely operational: the daedalus_v4l2 kernel module was not loaded (DKMS source was staged under /usr/src/daedalus_v4l2-0.1.0+r24+gf0d4186/ but dkms add had never been run on this host, so /lib/modules/.../daedalus_v4l2.ko did not exist). With the module absent: /dev/daedalus-v4l2 was missing, the daemon stayed dormant (ConditionPathExists= unmet), vainfo fell back to the non-existent v3d driver and vaInitialize failed, libva surfaced zero profiles, GfxInfo returned FEATURE_BLOCKED_PLATFORM_TEST for every codec, and gfxVars::Use*HwDecode() was false everywhere. Firefox was correctly falling back to SW because the underlying stack was not running.

After sudo dkms add daedalus_v4l2/0.1.0+r24+gf0d4186 && sudo dkms autoinstall && sudo modprobe daedalus_v4l2 && sudo systemctl start daedalus-v4l2, LIBVA_DRIVER_NAME=v4l2_request vainfo lists H264 Main/High/CB, HEVC Main, VP9 Profile 0, AV1 Profile 0 — the daemon picks up the requests cleanly. Re-test of Firefox playback is the next step.

PR #61 is fine as merged. No probe-side patch needed.

**Retracting this comment — wrong diagnosis.** Verified on higgs (Pi CM5) that the cause of `Codec X is not accelerated` / `IsHardwareAccelerated=0` is NOT a probe-side gap in `GetAcceleratedFormats` or any Firefox patch deficiency. It is purely operational: the `daedalus_v4l2` kernel module was not loaded (DKMS source was staged under /usr/src/daedalus_v4l2-0.1.0+r24+gf0d4186/ but `dkms add` had never been run on this host, so `/lib/modules/.../daedalus_v4l2.ko` did not exist). With the module absent: `/dev/daedalus-v4l2` was missing, the daemon stayed dormant (`ConditionPathExists=` unmet), `vainfo` fell back to the non-existent v3d driver and `vaInitialize` failed, libva surfaced zero profiles, `GfxInfo` returned FEATURE_BLOCKED_PLATFORM_TEST for every codec, and `gfxVars::Use*HwDecode()` was false everywhere. Firefox was correctly falling back to SW because the underlying stack was not running. After `sudo dkms add daedalus_v4l2/0.1.0+r24+gf0d4186 && sudo dkms autoinstall && sudo modprobe daedalus_v4l2 && sudo systemctl start daedalus-v4l2`, `LIBVA_DRIVER_NAME=v4l2_request vainfo` lists H264 Main/High/CB, HEVC Main, VP9 Profile 0, AV1 Profile 0 — the daemon picks up the requests cleanly. Re-test of Firefox playback is the next step. PR #61 is fine as merged. No probe-side patch needed.
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
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marfrit/marfrit-packages#61
Delete Branch "fix/firefox-v4l2request-type-accept-2026-05-21"

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?