gogpu v0.42.5 - Wayland Subpixel Detection Fix

gogpu/gogpu v0.42.5 was published on June 24, 2026 with a focused fix for Wayland wl_output.subpixel detection. The important change is that the value parsed from Wayland geometry now feeds the runtime detection chain instead of stopping after parse time. This release is not marked as a prerelease.

The full release notes and downloads are on the GitHub release page.

This is a small release, but it fixes a real correctness path. In v0.42.4, gogpu/gogpu parsed the Wayland subpixel value, but the release notes say that parsed value was not wired into the detection chain. v0.42.5 closes that gap.

For data engineers, the narrow scope is the point. Visual web processing jobs often depend on stable raster output, even when the job is not a user facing desktop app. Screenshot diffing, page capture, PDF rendering, OCR prework, and image based validation all become harder to reason about when the graphics stack reports one value and the process uses another.

The release wires wl_output.subpixel into the detection path. That means a Wayland compositor can now provide the subpixel layout through wl_output.geometry, and gogpu/gogpu can use it as a runtime input rather than falling through too early.

The notes call out a Pure Go registry binding during init. That matters for operators who care about how much native surface area a worker image carries. It does not remove the need for a Wayland environment, but it keeps this part of the probe inside the Go runtime rather than adding a separate helper path.

The release also performs a roundtrip for the geometry event. That detail is operationally relevant because display metadata is event driven. Without waiting for the geometry event, the process can make a decision before the compositor has supplied the relevant output data.

The value being read is the compositor reported subpixel layout, described in the notes as EDID based. In plain terms, hardware reported display metadata now has a chance to win before the code falls back to configuration files or a default.

The release notes document the detection order, and that is useful during rollout. The order is GOGPU_SUBPIXEL_LAYOUT, then wl_output.geometry, then fontconfig, then SubpixelNone.

That order gives operators a clear override path. If a worker fleet has mixed Wayland behavior, GOGPU_SUBPIXEL_LAYOUT can force a known value. If the environment is clean, the compositor geometry can provide the value. If Wayland does not supply it, fontconfig remains the fallback. If neither source gives an answer, the runtime lands on SubpixelNone.

This is also easier to debug. A rendering mismatch can be traced against a known chain instead of treated as a generic font or compositor issue. For batch capture jobs, that reduces the search space when two runners produce slightly different output from the same source page.

This release is not a broad feature drop. It is a targeted fix for Linux graphics correctness under Wayland. That makes it relevant to teams that run rendering or capture workloads on modern Linux desktops, virtual display stacks, or containers attached to a compositor.

The change does not promise faster rendering, new GPU support, or a different deployment model. It changes which source of truth is used for subpixel layout. The practical result should be more consistent text rendering where the compositor already exposes the correct value.

Teams already on v0.42.4 should treat this as a low surface area fix if Wayland output quality matters. Teams not using Wayland or not comparing raster output may see little direct impact. The GitHub release page is short, so it is worth reading before rolling the tag into a shared worker image.