From 38575ac33de677162bc60dfdbe49b9726d15dac7 Mon Sep 17 00:00:00 2001 From: Xaver Hugl Date: Mon, 13 Nov 2023 20:27:34 +0100 Subject: [PATCH] backends/drm: re-allow the hardware cursor with color management It doesn't look wrong anymore, presumably what caused it to look wrong before was just a bug. Blending in sRGB or PQ is still technically wrong, but it looks okay, and that's an acceptable tradeoff to make in order to get the responsiveness and power usage improvements the hardware cursor offers --- src/backends/drm/drm_egl_cursor_layer.cpp | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/backends/drm/drm_egl_cursor_layer.cpp b/src/backends/drm/drm_egl_cursor_layer.cpp index 3d8e4ed718..474ecc837a 100644 --- a/src/backends/drm/drm_egl_cursor_layer.cpp +++ b/src/backends/drm/drm_egl_cursor_layer.cpp @@ -48,10 +48,9 @@ EglGbmCursorLayer::EglGbmCursorLayer(EglGbmBackend *eglBackend, DrmPipeline *pip std::optional EglGbmCursorLayer::beginFrame() { - if (m_pipeline->output()->needsColormanagement()) { - // TODO for hardware cursors to work with color management, KWin needs to offload post-blending color management steps to KMS - return std::nullopt; - } + // note that this allows blending to happen in sRGB or PQ encoding. + // That's technically incorrect, but it looks okay and is intentionally allowed + // as the hardware cursor is more important than an incorrectly blended cursor edge return m_surface.startRendering(m_pipeline->gpu()->cursorSize(), drmToTextureRotation(m_pipeline) | TextureTransform::MirrorY, m_pipeline->cursorFormats(), m_pipeline->colorDescription(), m_pipeline->output()->channelFactors(), m_pipeline->iccProfile(), m_pipeline->output()->needsColormanagement()); }