A big merge today to Mesa Git ahead of next week’s Mesa 25.2 code branching is removing the pre-DMA-BUF winsys support and as part of that clearing out all of the old DRI2 driver support.
Direct Rendering Infrastructure DRI2 was replaced by DRI3 a decade ago. All the important and useful drivers support DRI3 these days – and have for years. One year ago in Mesa 24.2 the DRI2 support was gated off by a “legacy-x11” build-time option.
With no user complaints and the DRI2 / legacy X11 support not receiving any love, Mesa 25.2 is going ahead and stripping out the code. In doing so, Mesa is more than three thousand lines of code lighter in removing this legacy code.
Daniel Stone of Collabora opened the merge request last week “Bonfire of pre-dmabuf winsys support” that was merged today. He commented there:
“X11’s DRI2 protocol was deprecated in 24.2, hidden behind a legacy-x11 build option, with DRI3 being used everywhere instead. A year on, we can remove it, which cleans up the byzantine X11 client support code.
Wayland similarly had the EGL_WL_bind_wayland_display extension from a time before dmabuf was a thing, and from before modifiers were a thing. We’ve had a universal way to exchange buffers for a long time now, with compositors and clients both using zwp_linux_dmabuf_v1 to negotiate and exchange buffers between them. We can move bind_wayland_display support behind a similar legacy-wayland build flag, with the aim of deprecating it in a couple of release cycles.
Even if we do have bind_wayland_display and its wl_drm extension, we can very much assume that anyone using it also has support for dmabufs, and unconditionally remove the old codepath to use the global GEM names (as distinct from context-local GEM handles) which is as much a security risk as it is a bad idea.
Doing this allows us to burn dri2_from_names(), whittling down the possible frontend <-> Gallium entrypoints for creating images.”
This code is now removed for Mesa 25.2 that in turn will debut as stable in August.
