| Summary: | With HDR enabled, lock screen cursor dimming is out of sync with actual screen dimming | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | ctj9512 |
| Component: | colour-management | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | kdedev, nate, postix, triooum |
| Priority: | NOR | ||
| Version First Reported In: | 6.3.90 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=508320 | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/fd068d10b6559ce94b77508b267e1370274be729 | Version Fixed In: | 6.5.0 |
| Sentry Crash Report: | |||
| Attachments: | Screen recording | ||
|
Description
ctj9512
2025-05-27 21:15:49 UTC
I imagine you're using a light cursor theme that makes this visible, right? I applied the Breeze Light color scheme and I can't reproduce it on current git master. Can you attach a screen recording or phone video, whichever one shows the issue? Created attachment 181804 [details]
Screen recording
Cursor is darker than usual, until I move it above the textbox which changes the cursor, which makes the cursor light again.
The screen recording is darker than usual but is probably an issue with gpu-screen-recorder.
Also, HDR is enabled on my monitor which might be relevant to this issue.
Would be interesting indeed to know if it reproduces when HDR is disabled. (In reply to Nate Graham from comment #3) > Would be interesting indeed to know if it reproduces when HDR is disabled. Issue does not occur with HDR disabled; it looks like the display is dimmed using DDCCI brightness (but cannot confirm for sure, for some reason if I open the monitor's brightness control, KDE's dimming no longer works). No wonder I couldn't reproduce it: I don't have an HDR-capable screen! I'm able to reproduce this on git-master, with Qt 6.8 with an HDR display enabled (laptop) as well as on the two external displays that don't have HDR enabled. - Mouse cursors set to Breeze Light - Screen dim at 30sec - Screen lock at 1min Here is the sequence of events I observed, regardless of display: - Locked the screen - After 30sec, the screen was dimmed, but the mouse cursor was not - I moved the cursor. The screen undimmed and the mouse cursor dimmed - Moving the mouse cursor over the password input and then away from it undimmed the cursor A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7727 Git commit fd068d10b6559ce94b77508b267e1370274be729 by Xaver Hugl. Committed on 16/07/2025 at 14:26. Pushed by zamundaaa into branch 'master'. compositor: paint, enable and disable the cursor only in composite() (only) doing it asynchronously has disadvantages: - we can easily miss some situations in which the layer needs repainting - when moving the cursor plane fails, we can have some time between hiding the cursor plane and showing the software cursor, or likewise, some time between showing the cursor plane and hiding the software cursor - it requires special casing presentation feedback for the cursor With this change, the cursor is still moved asynchronously, so primary plane updates still can't slow cursor movement down or affect its latency. M +113 -126 src/compositor.cpp M +2 -0 src/core/outputlayer.cpp M +3 -0 src/core/outputlayer.h M +10 -0 src/scene/cursoritem.cpp M +1 -0 src/scene/cursoritem.h M +1 -0 src/scene/imageitem.cpp M +6 -0 src/scene/item.cpp M +1 -0 src/scene/item.h M +21 -0 src/scene/scene.cpp M +2 -0 src/scene/scene.h https://invent.kde.org/plasma/kwin/-/commit/fd068d10b6559ce94b77508b267e1370274be729 *** Bug 508320 has been marked as a duplicate of this bug. *** |