yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

backends/drm: re-allow the hardware cursor with color management

Browse source 
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
This commit is contained in:
Xaver Hugl 2023-11-13 20:27:34 +01:00
parent 5ee2d53561
commit 38575ac33d
1 changed files with 3 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
src/backends/drm/drm_egl_cursor_layer.cpp
View file

@ -48,10 +48,9 @@ EglGbmCursorLayer::EglGbmCursorLayer(EglGbmBackend *eglBackend, DrmPipeline *pip
std::optional<OutputLayerBeginFrameInfo> 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());
}