1777345 - linux sysroot includes related to drm (xf86drm.h and drm_fourcc.h) need updates to support libwebrtc pipewire updates

Status: RESOLVED WONTFIX

(Firefox Build System :: General, enhancement, P3)

Description

[Michael Froman [:mjf]]

In order to support the libwebrtc fast-foward work, the linux sysroot includes related to drm, specifically xf86drm.h and drm_fourcc.h, should be updated so we can continue to bring in the upstream commits related to pipewire for screen sharing.

At the moment, we're missing identifiers for DRM_FORMAT_MOD_INVALID, drmGetDevices2, drmDevicePtr, and DRM_NODE_RENDER.

Those symbols do exists in /usr/include on my Ubuntu 20.04 machine, fwiw.

Comment 1

[Mike Hommey [:glandium]]

Before updating the sysroot we need to determine whether the result would break binary compatibility with the currently supported set of distros and/or whether we can drop some of them.

Comment 2

[Nico Grunbaum [:ng, @chew:mozilla.org]]

DRM_FORMAT_MOD_INVALID was added four years ago in 7ec689a5406a4c5f468e126007c5aa9d72dd7f59, first appearing in release libdrm-2.4.83.
drmGetDevices2 was added five years ago in 11687bf4180f7e21045ed9c4730533c40fe01ea5 , first appearing in release libdrm-2.4.75.
drmDevicePtr was added six years ago in b556ea127e004b734b2a7bf8e67cdcf56312171d, first appearing in release libdrm-2.4.65.
DRM_NODE_RENDER was added seven years ago in f1adc4b375a16b07f560b86a34e617984049c422, first appearing in release libdrm-2.4.60.

Comment 3

[Michael Froman [:mjf]]

Do we know who needs to be involved in making the decision on how/when we move forward?

Comment 4

[Jan Grulich]

I was told here https://bugzilla.mozilla.org/show_bug.cgi?id=1790496#c29 this is blocked on Ubuntu 18.04 support, but when I check https://packages.ubuntu.com/bionic/libdrm-dev I can see there is already version of libdrm new enough to have everything needed.

Running Ubuntu 18.04 in Podman:

root@35f837811183:/usr/lib/x86_64-linux-gnu# nm -D libdrm.so | grep -i "drmGetDevices2"
0000000000008eb0 T drmGetDevices2

root@35f837811183:/usr/include# grep -ir "DRM_NODE_RENDER"
xf86drm.h:#define DRM_NODE_RENDER  2
root@35f837811183:/usr/include# grep -ir "DRM_FORMAT_MOD_INVALID"
drm/drm_fourcc.h:#define DRM_FORMAT_MOD_INVALID fourcc_mod_code(NONE, DRM_FORMAT_RESERVED)
libdrm/drm_fourcc.h:#define DRM_FORMAT_MOD_INVALID      fourcc_mod_code(NONE, DRM_FORMAT_RESERVED)
root@35f837811183:/usr/include# grep -ir "drmDevicePtr"
xf86drm.h:} drmDevice, *drmDevicePtr;

Is there anything I can help with? You really want the latest WebRTC code to be used instead as the old one is broken, highly inefficient and as you see with https://bugzilla.mozilla.org/show_bug.cgi?id=1790496 it doesn't work properly.

Firefox is now way behind Chromium and that's kind of sad, because Wayland is now widely used and people use screen sharing support more than before.

Comment 5

[Jan Grulich]

WebRTC now links against libdrm in upstream: https://webrtc-review.googlesource.com/c/src/+/279023. This makes me believe you should also be good to go.

Comment 6

[Mike Hommey [:glandium]]

Sorry for the delay here. After surveying the distros we currently support and updated the Firefox linux compatibility matrix, it looks like bumping to 2.4.83 would only drop support for RHEL 7.4 and older. https://glandium.github.io/firefox-linux-compat-matrix/#scope=runtime&version=108&show_eol=false&sort_by=drm (the EOL dates are definitely wrong for RHEL dot releases before 7.9 and 8.6, hopefully, that will eventually be fixed).

Up-to-date Ubuntu 18.04 systems have at least version 2.4.99, FTR. It appears the docker images we have for tests on CI have 2.4.101 (so the info in the matrix would appear to be outdated already).

The open question is how to handle the situation smoothly for systems that aren't quite up-to-date. Plainly depending on the new version of libdrm will just lead to a crash. Bug 1359918 would turn that into a startup failure, but we're not ready to land that yet.

Comment 7

[Mike Hommey [:glandium]]

Attachment: Bug 1777345 - Update sysroot version of libdrm to 2.4.83.

Comment 8

[Mike Hommey [:glandium]]

(so the info in the matrix would appear to be outdated already).

ah that's because I took the version in bionic, not in bionic-updates. So "at least 2.4.99" is still accurate, as long as users are somehow up-to-date.

Comment 9

[Mike Hommey [:glandium]]

Note the attached patch is contingent on confirmation that RHEL 7.4 and older are, indeed, EOL (which I think is the case).

Comment 10

[Mike Hommey [:glandium]]

It's worth noting that we currently don't depend on libdrm: None of the executable and libraries in Firefox link against it. It's dlopen()ed and we gracefully fail if it's not there.

Comment 11

[Mike Hommey [:glandium]]

Do you still need this?

Comment 12

[Michael Froman [:mjf]]

I believe we do. Nico was looking into something related to this recently.

Comment 13

[Nico Grunbaum [:ng, @chew:mozilla.org]]

I am working on this in 1790496.

Comment 14

[Mike Hommey [:glandium]]

Looking at the patches in that bug, it looks like you don't need this one...

Comment 15

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Let's leave this open for now, and revisit it after the other dependencies in bug 1790496 are worked out.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:glandium, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.

Comment 17

[Nick Alexander :nalexander [he/him]]

I'm not the person to consult here.

Comment 18

[Mike Hommey [:glandium]]

I'll assume we don't need this anymore. We can dig this up if this turns out to be required in the future.