[linlondp] Firefox crashes: RenderCompositorSWGL no DrawTarget — DRM master exclusif empêche les clients secondaires (XWayland/SWGL)

[lpennisi73-tech]

Environment

• Board: OrangePi 6 Plus (CIX CD8180 / Sky1)
• Kernel: 7.0.0 with Sky1 patches
• Mesa: 25.3.6 (Panfrost/Panthor)
• Distro tested: Gentoo Linux + Ubuntu 26.04 "Resolute Raccoon" (same result)
• Display: GNOME Shell on Wayland

Problem

Firefox crashes immediately on launch with:
RenderCompositorSWGL failed mapping default framebuffer, no dt
process exited on signal 11 (SIGSEGV)

Root cause — fully diagnosed

1. linlon_dp module ignores cmdline parameters

linlon_dp: unknown parameter 'enable_fb' ignored
linlon_dp: unknown parameter 'enable_render' ignored
The documented cmdline params linlon_dp.enable_fb=1 and
linlon_dp.enable_render=0 are silently ignored.
modinfo linlon_dp | grep parm reveals only two valid params:
force_linear_scanout_modifiers (bool)
force_scanout_8bpc_formats (bool)

2. /dev/fb0 disappears after GNOME takes DRM master

At boot, dmesg shows:
simple-framebuffer.0: fb0: simplefb registered!
linlondp 14160000.disp-controller: fb1: linlondpdrmfb frame buffer device
But after GNOME Shell takes exclusive DRM master on card1 (linlondp),
both fb0 and fb1 disappear — /dev/fb* does not exist at runtime.

3. GNOME holds exclusive master on card1 (linlondp)

/sys/kernel/debug/dri/1/clients:
systemd-logind → master=y
gnome-shell → master=n (active client)
Xwayland → master=n (active client)
framebuffer[182]: allocated by=gnome-shell, format=AR30, size=3840x2160
When Firefox tries to create a DrawTarget via SWGL on the same device,
there is no surface available → SIGSEGV.

4. DRI3 broken on XWayland path

libEGL warning: DRI3 error: Could not get DRI3 device
Firefox cannot access the GPU via DRI3 through XWayland.

5. Missing GLSL extension

error: extension `GL_EXT_shader_texture_lod' unsupported in fragment shader
Panfrost/Panthor Mesa 25.3.6 does not expose this extension on Mali-G720.

DRM device layout

card0 → panthor (15000000.gpu) — GPU render
card1 → linlondp (14160000.disp) — display controller only
renderD128 → panthor render node

Expected behavior

Secondary DRM clients (XWayland, Firefox SWGL) should be able to
create dumb buffers or map a framebuffer surface alongside the
compositor without requiring DRM master on card1.

Possible fix areas

• linlondp: implement/expose dumb_create for non-master clients
• linlondp: restore enable_fb parameter or document replacement
• Ensure fbdev emulation (CONFIG_DRM_FBDEV_EMULATION=y is set but
  ineffective) persists after compositor takes DRM master

Additional finding — kernel dumb_create works correctly

Tested dumb buffer creation directly on card1 (linlondp):

• DRM_IOCTL_MODE_CREATE_DUMB on /dev/dri/card1 → SUCCESS
• handle=1, pitch=7680, size=8294400 (1920x1080x32bpp)

linlondp_gem_dma_dumb_create confirmed loaded in kallsyms.

Conclusion: kernel side is correct. The issue is Mesa/Firefox
not using the dumb buffer path on card1, or EGL/DRI3 failing
to negotiate the correct device.

Patch set version

• Sky1-Linux: v6.18.1-1-85-g57e018a
• Branch used: patches-next (7.0 series, 22 patches)
• Repo last commit: 57e018a

Relevant CHANGELOG note (6.18.10-2)

The following fix exists in LTS/Latest but may be missing from patches-next:

drm: linlon-dp: DPU render node removed (conflicted with Panthor GPU),
fbdev always enabled

This suggests the fbdev regression in linlondp was already identified
and fixed in the LTS/Latest tracks but not yet ported to patches-next (7.0).

Update — deeper investigation

Additional finding: Firefox reports "No GPUs detected via PCI"
on this ARM64 platform SoC.

GPU is a platform device, not PCI:

• DRIVER=panthor
• OF_COMPATIBLE_0=arm,mali-valhall
• MODALIAS=of:NgpuT(null)Carm,mali-valhall

This means Firefox never successfully initializes GPU detection,
falls back to SWGL software rendering, which then fails to map
the framebuffer on card1 (linlondp) → SIGSEGV.

The issue may be split between:

1. Firefox bug: PCI-only GPU detection on ARM64 SoC
2. linlondp: fbdev/DRM client interaction (original report)

Opening a separate bug on bugzilla.mozilla.org for the Firefox
ARM64 platform GPU detection issue.

[coffnix]

try mesa 26 with sky1 patches: https://github.com/Sky1-Linux/mesa-sky1/releases/tag/mesa-26.0.0

my ebuild to emerge on macaroniOS (you can adapt to your gentoo):

/etc/portage/package.use:media-libs/mesa X egl gbm gles1 gles2 glvnd llvm zstd opencl sky1-patches vulkan

https://github.com/coffnix/coffnix-ebuilds/tree/master/media-libs/mesa

[lpennisi73-tech]

Update — Mesa Sky1 26.0.0 tested

Installed Mesa Sky1 26.0.0 fork as suggested.

EGL now correctly reports:

EGL driver name: panthor
OpenGL renderer: Mali-G720 MC10 (Panfrost)

However Firefox still crashes with the same error:
RenderCompositorSWGL failed mapping default framebuffer, no dt
process exited on signal 11 (SIGSEGV)

Additional finding:
Firefox reports No GPUs detected via PCI on this ARM64 SoC platform.
The Mali-G720 is a platform/AMBA device, not PCI:
DRIVER=panthor
OF_COMPATIBLE_0=arm,mali-valhall
MODALIAS=of:NgpuT(null)Carm,mali-valhall

This suggests the root cause is in Firefox GPU detection logic,
not in Mesa or the kernel driver.

A separate bug has been filed on Mozilla Bugzilla for this issue:
[Firefox ARM64 SoC — No GPUs detected via PCI — Mali-G720 Panthor]

Thank you for the Mesa Sky1 suggestion — the fork is working
correctly, the issue is upstream in Firefox.

[coffnix]

thanks for the feedback, @lpennisi73-tech test vkmark and glmark2

https://data.gpo.zugaina.org/bell07/app-benchmarks/