mesa-25.3.1 (remove VDPAU)

[Bruce Dubbs]

New minor version.

[zeckma]

Now 25.2.4.

[zeckma]

Now 25.2.5.

[Xi Ruoyao]

Now 25.2.6.

[zeckma]

Thanks for adjusting, Xi!

[zeckma]

Now 25.2.7. 25.2.8 has been added to the release calendar, I believe some time after 25.3.0.

[Xi Ruoyao]

25.3.0 is released.

[zeckma]

25.3.0 removes VDPAU support. On my Intel system, I went VDPAU-less. For NVIDIA GPUs, it won't matter regardless and would only be useful for the NVIDIA proprietary driver. In regards to BLFS, I think it will be safe axing VDPAU from the book (libvdpau and libvdpau-va-gl).

libvdpau-va-gl is a bit of a special case as it is a driver layering on top of VA-API and OpenGL. The use for VDPAU however instead of directly using VA-API seems slim. The project mentions a usecase being that you can offload work to the GPU in Flash Player. Ruffle is a very good replacement, utilizing WebGL/WebGPU.

Other packages in the book are good settling with VA-API, and some software outright require that support. But VDPAU mainly acts as a bridge for that optional support to use VDPAU drivers if they exist.

Since VA-API support in Mesa covers most GPUs, the decision is clear. If NVIDIA users aren't using Mesa, all that stuff is covered in GLFS+SLFS. VA-API in Mesa supports NVIDIA GPUs, so they aren't left stranded.

[Xi Ruoyao]

It blows up my configuration: ​https://gitlab.freedesktop.org/mesa/mesa/-/issues/14303

:(

[zeckma]

Hopefully will get fixed in 25.3.1/25.3.2. Thanks for reporting the issue upstream!

[Xi Ruoyao]

It turns out to be a GTK issue, the fix is ​https://gitlab.gnome.org/GNOME/gtk/-/commit/fc6581cf3be54d8a578f83f1fee71d63a779a8bf.patch.

[zeckma]

Replying to Xi Ruoyao:

It turns out to be a GTK issue, the fix is ​https://gitlab.gnome.org/GNOME/gtk/-/commit/fc6581cf3be54d8a578f83f1fee71d63a779a8bf.patch.

I can add this in when I do the Mesa update.

[Xi Ruoyao]

It should be included in gtk-4.20.3 (#22424) now.

[zeckma]

Thanks for letting me know.

[zeckma]

Mesa-25.3 now depends on libdisplay-info. I see it as either recommended or optional. Its main purpose in Mesa is to parse EDIDs for HDR information for the Vulkan WSI. In short, exposes HDR information for Vulkan drivers in Mesa. This dependency does not lead to an extra driver, just enhances already existing Vulkan drivers.

[Bruce Dubbs]

Replying to zeckma:

Mesa-25.3 now depends on libdisplay-info. I see it as either recommended or optional.

It's used in 5 other places. Lets make it recommended.

[zeckma]

An additional note on the libdisplay-info dependency, I'm now on the side of optional since Vulkan HDR works without it. The main use case is to expose the EDID information to VR headsets running off of an AMD GPU via Monado.

From ​https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35461:

> in what cases could be useful this extension to be merged?

Assuming you're asking for possible uses for the MR, this MR is a pre-requisite for getting HDR VR up and running on AMD GPUs with Monado (an open source OpenXR runtime). While there isn't a significant amount of VR gear that supports HDR, the relatively popular PSVR2 supports it, and through some initial testing, this MR does seem to work with the PSVR2 on my 6900XT.

Before that comment, it was mentioned that mpv can use Vulkan HDR on Wayland no problem without the MR.

[Bruce Dubbs]

I'll note that libdisplay-info is only 0.1 SBU and only needs hwdata that is also needed in several other places.

[zeckma]

Yeah. It doesn't matter much either way. Making it recommended will be safe too, as it may get increased importance in Mesa.

[zeckma]

Another note too about installed contents, /usr/lib/dri has increased the contents to:

apple_dri.so       imx-lcdif_dri.so    nouveau_drv_video.so   st7735r_dri.so
armada-drm_dri.so  ingenic-drm_dri.so  panel-mipi-dbi_dri.so  sti_dri.so
crocus_dri.so      iris_dri.so         pl111_dri.so           stm_dri.so
exynos_dri.so      kirin_dri.so        r300_dri.so            sun4i-drm_dri.so
gm12u320_dri.so    kms_swrast_dri.so   r600_dri.so            swrast_dri.so
hdlcd_dri.so       komeda_dri.so       r600_drv_video.so      udl_dri.so
hx8357d_dri.so     libdril_dri.so      radeonsi_dri.so        virtio_gpu_dri.so
i915_dri.so        mali-dp_dri.so      radeonsi_drv_video.so  virtio_gpu_drv_video.so
ili9163_dri.so     mcde_dri.so         rcar-du_dri.so         vkms_dri.so
ili9225_dri.so     mediatek_dri.so     repaper_dri.so         vmwgfx_dri.so
ili9341_dri.so     meson_dri.so        rockchip_dri.so        zink_dri.so
ili9486_dri.so     mi0283qt_dri.so     rzg2l-du_dri.so        zynqmp-dpsub_dri.so
imx-dcss_dri.so    mxsfb-drm_dri.so    ssd130x_dri.so
imx-drm_dri.so     nouveau_dri.so      st7586_dri.so

libdril_dri.so is still a regular library, the _drv files are symlinks to libgallium, and the rest are symlinks to libdril_dri.so. I don't know why the amount of symlinks increased, especially when most of them aren't applicable to us.

[zeckma]

Now 25.3.1.

[zeckma]

Currently under active testing. Zink+NVK have gotten more stable. Hardware cursors have a tough time working correctly, however, and I have submitted an issue upstream for that. See ​https://gitlab.freedesktop.org/mesa/mesa/-/issues/14425 for more information.

A previous issue (see ​https://gitlab.freedesktop.org/mesa/mesa/-/issues/13047) doesn't seem to be the case anymore for now, and will close that issue if it does not happen again in a day or two. That means this package will be in testing for a day or two before I start running stats and making changes, axing VDPAU in the process.

This issue can be expected to be resolved in half a week or so.

[zeckma]

Fixed at 9cae264f45d3d8a202e0d4f2e18bcada5aadecd6.

[Bruce Dubbs]

Milestone renamed