Bug 419858

Are you on X11 or Wayland?

(In reply to Vlad Zahorodnii from comment #1)
> Are you on X11 or Wayland?

I am sorry for my late reply, I forgot to add myself to the CC list. I am on X.

I have a similar, although somewhat different issue with Night Color:
My system is a desktop, with two monitors. One of them is on HDMI, 60Hz, in portrait orientation (with rotated output), and the other one is on DisplayPort, 120Hz, in landscape orientation. I am on X11 as of now.

I have Night Color enabled, and in the evening, it dims the portrait monitor as expected, but not the landscape one.
Upon opening the preferences dialog, to manually toggle the Night Color feature:

In this inconsistent state, when disabling the feature and pressing Apply on the dialog, the landscape monitor immediately flashes to being a warmer color tone, just to then slowly fade back into blue, together with the other working monitor.

And after this, when Night Color is enabled again, they both fade into warm color together. For some reason, it just doesn't apply the color temperature automatically on the main display basedon time.
It might have something to do with me sometimes playing fullscreen games on that monitor, which disables compositing temporarily?

Back when I had gtk-redshift instead, it seemed to always work just fine.

Actually my issue is also similar to this one:
https://bugs.kde.org/show_bug.cgi?id=419690
Except I'm never disconnecting-reconnecting any of the displays.
However, I do send the computer into standby every night, which, I guess, effectively, disconnects both of them "at the same time"?

With geo-coordinates set to my gps manual location, kcm_nightcolor shows the correct start and end times, but night color is always on (noon). With Custom time, it works as advertised. For reasons I cannot explain, Current location and Detect location are 0, 0. What changed? This used to work as advertised.

I also see this behavior.

The application frequently fails to make any of the transitions occur.

I have custom times set and I frequently need to manually touch the sliders get it to "notice" what state its supposed to be in.

When touching either of the sliders it does select the correct state that it should have been in for the custom times set.

(In reply to adam from comment #6)
> I also see this behavior.
> 
> The application frequently fails to make any of the transitions occur.
> 
> I have custom times set and I frequently need to manually touch the sliders
> get it to "notice" what state its supposed to be in.
> 
> When touching either of the sliders it does select the correct state that it
> should have been in for the custom times set.

I should say I'm on debian bookworm with an amd gpu.

This has been happening for the last year'ish

Created attachment 164372 [details]
GUI config

For me it happens from time to time.
Seems like it misses either the current time (scheduledTransitionDateTime) or targetTemperature somehow.
Example state after such a miss; night color configured to 3000°K and not applied here:

    $ for p in `qdbus org.kde.NightColor /ColorCorrect | grep ^property | cut -d. -f5`; do
        echo "$p = `qdbus org.kde.NightColor /ColorCorrect $p`"
    done

    available = true
    currentTemperature = 5000
    enabled = true
    inhibited = false
    mode = 2
    previousTransitionDateTime = 1703224800
    previousTransitionDuration = 60000
    running = true
    scheduledTransitionDateTime = 1703275200
    scheduledTransitionDuration = 60000
    targetTemperature = 5000

    $ date
    Fri Dec 22 10:24:49 PM EET 2023

    $ date --date=@1703275200
    Fri Dec 22 10:00:00 PM EET 2023

Applet icon tells "Night Color is active (5000K)".
After clicking it generates message "Night Color off" (inhibited).

Screenshot of the graphical config attached.

Using Xorg, Fedora 39:
    kwin-common-5.27.10-1.fc39.x86_64
    plasma-workspace-libs-5.27.10-1.fc39.x86_64
    kdeplasma-addons-5.27.10-1.fc39.x86_64
    kde-workspace-common-4.11.22-39.fc39.noarch
    kde-baseapps-common-16.12.2-15.fc39.noarch
    kde-runtime-17.08.3-28.fc39.x86_64

Lots of things have changed here in Plasma 6, so there's a chance the issue may be fixed now.

Can I ask affected folks to try again in Plasma 6? If it's still broken, then at this point it's probably either a KWin issue or a driver issue.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!