Closed Bug 1777345 Opened 2 years ago Closed 5 months ago

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


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



(Not tracked)



(Reporter: mjf, Assigned: glandium, NeedInfo)




(1 file)

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.

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.

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.

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

Severity: -- → S3
Flags: needinfo?(mh+mozilla)
Priority: -- → P3

I was told here this is blocked on Ubuntu 18.04 support, but when I check 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 | 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 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.

WebRTC now links against libdrm in upstream: This makes me believe you should also be good to go.

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. (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.

Flags: needinfo?(mh+mozilla)
Assignee: nobody → mh+mozilla

(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.

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

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.

Do you still need this?

Flags: needinfo?(mfroman)

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

Flags: needinfo?(mfroman) → needinfo?(na-g)

I am working on this in 1790496.

Flags: needinfo?(na-g)

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

Flags: needinfo?(na-g)

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

Depends on: 1790496

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.

Flags: needinfo?(nalexander)
Flags: needinfo?(mh+mozilla)

I'm not the person to consult here.

Flags: needinfo?(nalexander)

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

Closed: 5 months ago
Flags: needinfo?(mh+mozilla)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.