Firefox – we’re finally getting HW acceleration on Linux

A first image from original WebRender article. Published three years ago.

Firefox 84.0 is a big milestone for Firefox Linux development as it comes with HW acceleration by default for some Linux users. Stock Mozilla Firefox 84.0 enables WebRender (HW accelerated backend) for Gnome/X.org and Gnome/Wayland will be supported in Firefox 85.0. Fedora is bit ahead and enables WebRender for Gnome/Wayland in Firefox 84.0 too.

WebRender by default is restricted to AMD/Intel graphics cards as NVIDIA is known for various issues – both proprietary and Noveau drivers.

And why it’s enabled in Gnome only for now? For instance KDE is also a popular desktop environment. I think it’s because Gnome utilizes HW acceleration so when Gnome works on your box there’s assumption that Firefox will work too. KDE provides choices how to disable/restrict HW acceleration setup (for instance it supports disabled screen compositing) and it’s more difficult to cover various scenarios.

Another excluded group are XWayland users. It means you have Wayland as a desktop compositor but for some reasons you use X11 emulation layer and run Firefox as X11 application. It’s a valid scenario, Firefox with Wayland backend still suffers from some annoying bug, mostly related to popup windows.

But don’t worry, Mozilla folks are going to bring WebRender to the most Linux users on various desktops and graphics. Jan created a brief Linux WebRender state overview. And you can help with it! Please check if you have WebRender enabled and eventually try to enable it. Test various web pages, video playback, WebGL and report your experience. You can use comments below or drop me a mail at stransky@redhat.com.

The first fully tested Fedora Firefox package

Mozilla testsuite running natively on Wayland. There is still a room for improvement 🙂

We hit a big milestone in Firefox deployment on Fedora with firefox-84.0.2 package. It’s the first fully tested Firefox package released to Fedora users. Let’s see what’s so exciting on it.

Mozilla has a large testsuite as a part of development and release process. When any new patch hits Firefox repository, it’s built and tested for functional and speed regressions. The testsuite is also a developers nightmare as it contains some old and outdated test environments and it may be difficult to pass patches through it.

So if you download a Mozilla Firefox binary you can be sure it’s generally working at least on X.org and Ubuntu 18.04 which is main test setup there. But what about distro builds?

There are may differences how Firefox is built by various distributions. The very first difference is used compiler. Mozilla compiles by custom patched Clang which is not available for distributions although they actually don’t want it.

GCC is the favorite compiler among Linux hackers and that brings extra maintenance burden to Firefox distro maintainers. Compiler crashes and code miscompilation are companions of every new GCC version (no to mention an extra fun with LTO).

Distros also tend to modify Firefox sources with various integration patches or patches from Nightly, run Firefox on Wayland backend or use system NSS so maintaining such package is like dancing in a minefield.

And there comes the Mozilla testsuite. If we manage to run it in our environment with our package modifications it greatly helps to reduce unwelcome surprises like Bug 1893474. And it needs to run in automated manner and test every Firefox build we may release to user on all arches.

And that’s done now. Almost. The latest Firefox Fedora builds (F32, F33) run the testsuite as a part of the build process and test results are generated as a new package (firefox-testresults).

If I say we’re almost there, I mean the most difficult work is done as the tests are run in Koji. There are still some failing tests which needs to be inspected and disabled or fixed. The testsuite needs to be run on Wayland – it checks X11 backend now. And it should be integrated to Fedora test infrastructure to show test results in some user-friendly way.

Firefox on Fedora with OpenH264

Firefox on Fedora which sits in the updates [F32][F31] right now comes with enabled OpenH264 Cisco decoder for video playback and fdk-aac-free used for audio decoding.

It’s implemented by GMP (Gecko Media Plugin) API so the OpenH264 is not used through ffmpeg library but Firefox sandboxed interface, the same as Firefox uses for Widevine CDM plugin.

The OpenH264 GMP video playback is a fallback solution when system ffmpeg is missing and internal ffvpx library can’t decode the stream, so ffmpeg from RPM Fusion is always a better alternative if you can install it.

The video streams are decoded by system wide OpenH264 2.1.1 which is shipped by Fedora as mozilla-openh264 rpm package. Even if Mozilla OpenH264 (1.8.1) plugin is installed in your profile and claimed at about:plugins page, the Fedora system one is used.

You can also remove the old plugin from your profile (see Bug 1648024 for details) and with the updated Firefox packages ([F32][F31]) it won’t be installed again.

OpenH264 plugin utilization, version and playback parameters can be confirmed from GMP log, just run Firefox on terminal as:

MOZ_LOG=”GMP:5″ firefox

and look for OpenH264 version / path and so on.

Also if you find any bug during video playback (and you definitely will find one :-)), please report that at bugzilla.redhat.com or Cisco bug tracker along with the video link.

Firefox 81 on Fedora with VA-API, WebRTC and X11

Mozilla Firefox continues to implement more and more HW acceleration features on Linux and Fedora comes with extra integration patches to enable it.

Firefox 78 introduced VA-API video decoding on Wayland. Firefox 81 (a latest stable release) comes with VA-API for WebRTC streams decoding and enables VA-API on X11 for supported platforms.

Let’s start with X11. Firefox implements VA-API on top of DMABuf where particular video frames are exported by vaExportSurfaceHandle from libva and imported by EGL_EXT_image_dma_buf_import extension to OpenGL/EGL. That’s the default OpenGL sequence on Wayland where the VA-API was implemented first.

There are two options how to bring VA-API on X11 – vaPutSurface/GLX or vaExportSurfaceHandle/EGL. GLX is the default Firefox OpenGL backend on X11, it’s well supported on all devices including NVIDIA proprietary drivers and it’s generally well tested. On the contrary Firefox does not implement native X11 pixmap textures in any HW accelerated backend, shm based textures are used everywhere. There was an attempt to implement VA-API/vaPutSurface with Basic compositor but it was rejected.

VaExportSurfaceHandle/EGL is the second option for X11. EGL is well supported on Intel/AMD drivers but almost completely missing on NVIDIA, both proprietary and free ones (a partial solution may be GLX/EGL wrapper by Adam Jackson). But with EGL we can recycle most of the work done for Wayland and use the same code path which led to final EGL/X11 implementation by Robert Mader.

The EGL backend is not used by default yet, we’re working to enable it for Mesa drivers. Until that happens you need to run Firefox with set MOZ_X11_EGL env variable to switch from GLX to EGL, so run Firefox as:

MOZ_X11_EGL=1 firefox

As a consequence the dmabuf/vaapi preferences has been changed. Enable VA-API decoding by media.ffmpeg.vaapi.enabled set to true at about:config. That’s a single option for both Wayland and X11 backends as well as for WebRTC decoding (see bellow). Also make sure WebRender (Firefox HW accelerated backend) is enabled.

Users of Mozilla stock builds or other distros than Fedora need also set media.ffvpx.enabled to false until VA-API decoding is implemented in in-tree ffvpx library.

And now the WebRTC VA-API decoding. I tested the implementation on BlueJeans video conferencing system as it’s used by Red Hat internally. BlueJeans uses VP8 video streams and Intel HW decoder produces YV12 video frames which have to be handled by DMABuf surfaces. And we also want to route WebRTC video through external decoder by default [1][2].

If you use Fedora Firefox builds you are settled here, the patches [1][2] are included in the builds.

Users of other distros or Mozilla Firefox stock builds must set media.ffmpeg.low-latency.enabled and media.navigator.mediadatadecoder_vpx_enabled to true at about:config.

Firefox GNOME Shell search provider

Firefox has a long history of Gtk desktop integration. We use native Gtk3 theme to style widgets, we try to use system colors where it’s possible, honor global dark themes and so on and we feel that the application should play nicely with the rest of the system.

Plasma/KDE users may admit that Firefox is a GTK application and KDE integration is missing as well as integration for various tiling windows managers. This isn’t an intention but merely a lack of manpower to code and maintain that.

Another step in the Gnome integration effort is to provide a global search experience by Firefox. It’s already available in Fedora by default by downstream patches but the patches were integrated upstream so they’re available for all users of Mozilla stock builds since Firefox 78 (that also includes recent ESR line).

Firefox GNOME Search provider can be enabled in three easy steps:

• Install Firefox desktop and Firefox search provider files. You can use prepared ones from Mozilla or create your own. Copy firefox.desktop to /usr/share/applications/ and firefox-search-provider.ini to /usr/share/gnome-shell/search-providers.
• Run Firefox, go to about:config and set
  browser.gnome-search-provider.enabled to true.
• Restart Firefox.

Now, when Firefox is running, you should see search results when you hit ‘Super’ key in Gnome and type something. If you don’t get anything, check:

• Is D-Bus service running? Use D-Feet tool to inspect if Firefox provides org.mozilla.Firefox.SearchProvider interface on Session Bus.
• Are Firefox search results shown? If not, go to Gnome Settings -> Search and look for Firefox. If the Firefox is missing in search engines, your firefox-search-provider.ini isn’t properly installed. To see Firefox search results, move Firefox up to the top.