An Aside: Firefox on Wayland

I didn’t need to write this post, but I did anyway, because I felt the need to document my ~2 hours of ferocious searching to figure out why something went wrong.

I wanted to test WebGL and VA-API hardware acceleration on Wayland on Firefox, new in FF 75. VA-API has been implented on Wayland before (!) X11 (bug), which gives me a sliver of hope for the future of Linux, and I suppose shows where priorities lie.

This blog post describes how to enable WebGL, and the ArchWiki explains how to enable VA-API, but there are a few more bumps in the road, as it wasn’t all plug and play for me.

Wayland

I might write about this in a future blog post, but I’ve switched entirely to Wayland on my new laptop - the Dell XPS 2-in-1 (7390). I really think it’s fantastic. I’m using Sway, and a handful of other tools described in the i3 Migration Guide with great success. I haven’t run into any dealbreakers as of yet, and the positives are great - better external display support, no tearing by default, the way that sway handles touch screen input mapping to displays:

# this even keeps the mapping accurate upon screen rotation e.g. via accelerometer!
input type:touch map_to_output eDP-1

🤌¹

But I digress.

WebGL

Theoretically, all the pieces are in place on the Firefox side. You need:

• Firefox >=75

OpenGL acceleration:

• layers.acceleration.force-enabled true

Or, alternatively, WebRender:

• gfx.webrender.enabled true
• gfx.webrender.all true

And the actual feature flag:

• widget.wayland-dmabuf-webgl.enabled true

But… doing this gave me nothing but a grey screen and Firefox tells me that WebGL “lost context”. What?

WebGL(0x7f10c4311800)::LoseContext(0)

After ~20 minutes of Googling, it’s a regression in Mesa. I wasn’t super stoked to build Mesa on this, so I suppose I’ll wait it out.

Sometimes it surprises me when things work at all…

VA-API

Alright, well, no dice there. What about hardware accelerated video?

The gpu in this laptop is supposed to be rather nice, compared to a traditional iGPU - it’s an “Iris Plus” after all. We’ll need the VA-API driver for it. Confusingly, there’s two - libva-intel-driver and intel-media-driver. Looks like it depends on which GPU you have. (Good thing I didn’t try this earlier…)

For VA-API in Firefox, you need acceleration on, as above… and:

• widget.wayland-dmabuf-vaapi.enabled true

Cool, let’s try it.

Oh. What?

[Child 18177: MediaPDecoder #1]: D/PlatformDecoderModule Initialising VA-API FFmpeg decoder
[Child 18177: MediaPDecoder #2]: D/PlatformDecoderModule AudioTrimmer[0x7f2cd908ec40] ::operator(): sample[0,21000] no trimming information
[RDD 18516: MediaPDecoder #1]: D/PlatformDecoderModule OpusDataDecoder[0x7f0fc702e4a0] ::ProcessDecode: Opus decoder skipping 312 of 960 frames
[Child 18177: MediaPDecoder #2]: D/PlatformDecoderModule AudioTrimmer[0x7f2cd908ec40] ::HandleDecodedResult: sample[0,21000] (decoded[0,13500] no trimming needed
Sandbox: seccomp sandbox violation: pid 18177, tid 18514, syscall 64, args 1140872792 1 1974 139830925202168 0 139830892768280.  Killing process.

You what? A sandbox violation?

Back to Google. Firefox currently does this rendering in the content process, instead of the RDD or GPU process. Generally you don’t want the process that executes untrusted JS accessing the hardware, I guess? Wacky.

Frustrated, but hopeful

I guess the reason I wrote this post was just out of frustration. That and it’s really quite amazing how many pieces need to be in place for graphics on Linux. Mesa, drivers, app writers, X11/Wayland…

I’ll write another proper post soon - I was able to pin down what was causing the stutter I was seeing in my previous post. Hint: A night with gpuvis helped.