The hardware cursor plane is blended by the display engine after the
compositor has already encoded its framebuffer into the output's colour
space. renderHWCursorBuffer() renders the cursor as plain sRGB, so on a
colour-managed output those values are reinterpreted in the output space.
On a PQ output that means a white cursor lands near peak luminance and is
blinding relative to every other SDR surface, which is what
hyprwm/Hyprland#14419 reports. Setting cursor:no_hardware_cursors=1 avoids
it because software cursors go through the normal, colour-managed pass.
Tag the cursor framebuffer with the monitor's image description so the
texture pass converts into the output colour space. The target selection in
CHyprOpenGLImpl already prefers the current FB's image description when it
has one, so no other plumbing is needed.
wlroots fixed the same issue in its DRM backend (!5190, "cursor: apply
output image description when preparing texture").
applyCMType() replaces the output's image description and marks the blur FB
dirty, but never damages the monitor. Anything already composited under the
previous colour transform therefore stays on screen until something else
happens to damage it.
It is most visible on transparent surfaces after leaving HDR: a faint grey
overlay that persists for roughly half a second, until the surface repaints
for an unrelated reason. Confirmed by A/B - leaving HDR normally shows it,
while leaving HDR followed immediately by a forced full repaint does not.
This was previously masked by the ~1s blank an HDR transition used to cause,
which force-repainted everything.
Navon John LukoseandGitHub