SUMMARY When turning on the "Night Color" option under X11 or Wayland, if utilizing the "Automatic" or "Location" modes, the shift happens immediately, no matter the time of day. Even at 11am, Night Color will be enabled, despite that location is being grabbed correctly, sunrise/sunset times are correct and it is not currently dark outside. STEPS TO REPRODUCE 1. Activate Night Color under the Night Color system settings dialog 2. Choose "Automatic" or "Location" from the operation mode 3. If using "Location" click "Get Location" and verify that the coordinates are correct. 4. Click Apply OBSERVED RESULT Night color turns on immediately and the screen color shifts, even if it is not currently night time. EXPECTED RESULT Night color only turns on during night. SOFTWARE/OS VERSIONS Linux/KDE Plasma: OpenSUSE Tumbleweed (available in About System) KDE Plasma Version: 5.16.90 KDE Frameworks Version: 5.62.0 Qt Version: 5.13.1 ADDITIONAL INFORMATION - "Times" mode works correctly. - Bug seems to be present for both Wayland and X11 sessions. - I previously tested this on Debian Buster using 5.14.5 and experienced the same bug (though under a Wayland session only). - Font DPI scaling is being used - Compositor is set to OpenGL 3.1 (2.0 doesn't seem to make a difference) Output of: qdbus org.kde.KWin /ColorCorrect nightColorInfo 11:43AM -- Night color is currently on when it should not be. (Lat/Longs have been rounded) Active: true ActiveEnabled: true Available: true CurrentColorTemperature: 4500 EveningBeginFixed: 18:00:04 LatitudeAuto: 0 LatitudeFixed: 49.0000 LocationEnabled: true LongitudeAuto: 0 LongitudeFixed: -123.0000 Mode: 0 ModeEnabled: true MorningBeginFixed: 06:00:04 NightTemperature: 4500 NightTemperatureEnabled: true Running: true TimingsEnabled: true TransitionTime: 30
Can you compile KWin with the following patch by Vlad and test again: https://phabricator.kde.org/D24153
I have built the package with the patch provided by Vlad. Test results: I set the night color mode to Automatic and hit apply. The screen still shifts to the night color mode. I then set the night color mode to Location and hit apply. The screen shifted out of red and to the daytime color. So at least that is looking better. It is currently just after noon. Still in Location mode, I manually adjusted the time to 9pm. Kwin shifts the color, as expected and setting the time back to the current time adjusts the color back. It appears to have partially fixed the bug as Location mode appears to be working correctly now; however Automatic mode is still shifting the screen as soon as I hit apply.
Can you post output of `qdbus org.kde.KWin /ColorCorrect nightColorInfo` when night color is in automatic mode?
Lat/Longs have been rounded again. Location Mode: Active: true ActiveEnabled: true Available: true CurrentColorTemperature: 6500 EveningBeginFixed: 18:00:00 LatitudeAuto: 0 LatitudeFixed: 49.0000 LocationEnabled: true LongitudeAuto: 0 LongitudeFixed: -123.0000 Mode: 1 ModeEnabled: true MorningBeginFixed: 06:00:00 NightTemperature: 4500 NightTemperatureEnabled: true Running: true TimingsEnabled: true TransitionTime: 30 Automatic Mode: ColorInfo Active: true ActiveEnabled: true Available: true CurrentColorTemperature: 4500 EveningBeginFixed: 18:00:00 LatitudeAuto: 0 LatitudeFixed: 49.0000 LocationEnabled: true LongitudeAuto: 0 LongitudeFixed: -122.0000 Mode: 0 ModeEnabled: true MorningBeginFixed: 06:00:00 NightTemperature: 4500 NightTemperatureEnabled: true Running: true TimingsEnabled: true TransitionTime: 30 It looks like Latitude/Longitude auto are still set for 0,0 which would be in UTC. If I set my timezone to UTC (From pacific) and correct the time manually, the Automatic mode seems to function correctly. I don't know if there's a way to bump the Lat/Long Auto manually, but considering it's Automatic, I would imagine that these location checks should be done without user intervention. For what it's worth, with "Automatic" mode enabled, the Lat/Longs displayed in the grayed out box in the Systems Setting module match the Lat/Longs Fixed reported by `qdbus org.kde.KWin /ColorCorrect nightColorInfo`
Hmm, indeed. It appears like there are issues with sending automatically detected location data to night color manager.
So, it seems like we need to fix two issues: * the actual implementation of night color (my patch) * kded module that sends location data to night color
s/issues/things/
Just an update for the kwin side of things: I have rebuilt kwin with the revisions to the diff requested by Roman and the behavior of Location mode has remained consistent across patches. Should a separate bug report be opened for kded?
What exactly happens in "Location" mode? If you click the "Get Location" button it shows the correct longitute/latitude values in the input fields? In case it shows the values you expect at your location, what times does it show then in the greyed out times fields above with and without the patch from Phabricator?
Created attachment 122845 [details] Location Mode Settings with Patch
Created attachment 122846 [details] Location Mode Settings without Patch
Created attachment 122847 [details] Automatic Mode Settings Patched or unpatched, looks the same
To answer your questions: > If you click the "Get Location" button it shows the correct longitute/latitude values in the input fields? Location Mode is grabbing the correct location, as expected. These coordinates are greyed out if switching over to Auto Mode, but they are still correct. If I manually define coordinates in the Location box (i.e. 49.0000, -122.0000), click apply and then change the mode to automatic, the grayed out box is automatically switched to the correct coordinates. > What times does it show then in the greyed out times fields above with and without the patch from Phabricator? Sunrise and Sunset times are correct for my locale, with or without the patch.
Thank you for the detailed information. So the location data seems to be made available correctly through kded. And the patch to KWin does not change the calculated times based on that location data. So receiving the location data and the timing calculation seems to work correctly. What's not working still is applying this timing data then in automatic mode. And it shows 0,0 in nightColorInfo via d-bus for the auto location values, but this could be an unrelated issue.
Git commit c265c7f2c698ce51c039d3fe009fe09981ce1267 by Vlad Zahorodnii. Committed on 26/09/2019 at 08:31. Pushed by vladz into branch 'Plasma/5.17'. [nightcolor] Use local time in Automatic and Location mode Summary: Currently Night Color doesn't handle time zones very well. For example, if the user's time zone is UTC-8, then computed timings of sunrise and sunset (in UTC) will be a bit gibberish as sunset occurs before sunrise rather than vice versa. This change switches relevant parts of Night Color to local time in order to fix expectations about the order of morning and evening in updateSunTimings() method as well to simplify the code a bit (dealing with UTC and local time can be painful sometimes). Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24153 M +25 -33 colorcorrection/manager.cpp M +1 -1 colorcorrection/manager.h M +25 -14 colorcorrection/suncalc.cpp M +1 -1 colorcorrection/suncalc.h https://commits.kde.org/kwin/c265c7f2c698ce51c039d3fe009fe09981ce1267
Git commit 086428754ecfce28a7603475e6256c13985a6539 by Vlad Zahorodnii. Committed on 26/09/2019 at 09:10. Pushed by vladz into branch 'Plasma/5.17'. [nightcolor] Print a debug message upon receiving new location from kded module Summary: This can be useful for debugging whether Night Color manager actually receives new location data from colorcorrectlocationupdater kded module. Test Plan: Run kwin with QT_LOGGING_RULES="kwin_colorcorrection.debug=true" Run from the terminal the following two commands qdbus org.kde.kded5 /kded unloadModule colorcorrectlocationupdater qdbus org.kde.kded5 /kded loadModule colorcorrectlocationupdater Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24236 M +2 -0 colorcorrection/manager.cpp https://commits.kde.org/kwin/086428754ecfce28a7603475e6256c13985a6539
@Samantha: Can you build kwin with two patches above and check whether night color manager actually receives correct location data when it's in automatic mode? You would need to run kwin_x11 from the terminal with the following command QT_LOGGING_RULES="kwin_colorcorrection.debug=true" kwin_x11 --replace # bash, zsh env QT_LOGGING_RULES="kwin_colorcorrection.debug=true" kwin_x11 --replace # fish Then open another terminal and reload colorcorrectlocationupdater kded module qdbus org.kde.kded5 /kded unloadModule colorcorrectlocationupdater qdbus org.kde.kded5 /kded loadModule colorcorrectlocationupdater Wait for a few seconds, and then post output of kwin_x11 here.
Icon theme "gnome" not found. OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2) OpenGL version string: 4.5 (Core Profile) Mesa 19.1.7 OpenGL shading language version string: 4.50 Driver: Intel GPU class: Unknown OpenGL version: 4.5 GLSL version: 4.50 Mesa version: 19.1.7 X server version: 1.20.5 Linux kernel version: 5.2.14 Requires strict binding: yes GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no kwin_colorcorrection: Received new location (lat: 49.000000, lng: -122.000000)
What's the output of `qdbus org.kde.KWin /ColorCorrect nightColorInfo` after that?
Huh, weird. I wonder if it was unloading and reloading the module that did it. I've restarted this computer a few times since opening this report and not sure why restarting wouldn't have a similar effect as reloading the module: Active: true ActiveEnabled: true Available: true CurrentColorTemperature: 6500 EveningBeginFixed: 18:00:00 LatitudeAuto: 49.0000 LatitudeFixed: 49.0000 LocationEnabled: true LongitudeAuto: -122.0000 LongitudeFixed: -122.0000 Mode: 0 ModeEnabled: true MorningBeginFixed: 06:00:00 NightTemperature: 4500 NightTemperatureEnabled: true Running: true TimingsEnabled: true TransitionTime: 30 It's currently 11am and "Automatic" mode appears to be working correctly. If I go back to the vanilla 5.16.90 kwin, the Lat/LongAuto appear to stick with the correct locations. (Though, due to the missing local time patch, the red shift is still applying).
Ah, one last piece of info that might help clarify. I noticed this last night, but was a bit sleep deprived and didn't think much of it at the time. If I switch to Location mode and run the command: `qdbus org.kde.kded5 /kded unloadModule colorcorrectlocationupdater` I receive the output: `false` I would imagine this is to be expected, as the module is probably not needed when in Location mode. However, if I switch to "Automatic", then: `qdbus org.kde.kded5 /kded unloadModule colorcorrectlocationupdater` I still receive the output: `false` I then run `qdbus org.kde.kded5 /kded loadModule colorcorrectlocationupdater` Receive: `true` I then run `qdbus org.kde.kded5 /kded unloadModule colorcorrectlocationupdater` And receive `true` this time. If I'm not mistaken, I'm to understand that `true` is the equivalent of "success", and if I receive a `false` response to the `unloadModule`, the module was not unloaded because it wasn't loaded before running the command. This leads me to wonder if the module is being correctly loaded in the first place.
Apologies to anyone's inbox regarding another notification, but I had the idea to check on a fresh boot if the module is being loaded. It doesn't appear to be on boot -- I don't know if it is actually intended to be, however: `qdbus org.kde.kded5 /kded loadedModules` kscreen khotkeys networkstatus proxyscout accounts bluedevil desktopnotifier remotenotifier touchpad wacomtablet appmenu statusnotifierwatcher ksysguard kded_printmanager networkmanagement ktimezoned `qdbus org.kde.kded5 /kded loadModule colorcorrectlocationupdater` true `qdbus org.kde.kded5 /kded loadedModules` kscreen khotkeys networkstatus proxyscout accounts bluedevil desktopnotifier remotenotifier touchpad wacomtablet appmenu statusnotifierwatcher ksysguard kded_printmanager networkmanagement ktimezoned colorcorrectlocationupdater
Can you include your ~/.config/kded5rc please
Created attachment 122968 [details] KCM I'm currently in Montreal and noticed the Night Color being activated at wrong time as well. qdbus org.kde.KWin /ColorCorrect nightColorInfo output: Active: true ActiveEnabled: true Available: true CurrentColorTemperature: 4500 EveningBeginFixed: 18:00:00 LatitudeAuto: 47.5355 LatitudeFixed: 0 LocationEnabled: true LongitudeAuto: 10.2849 LongitudeFixed: 0 Mode: 0 ModeEnabled: true MorningBeginFixed: 06:00:00 NightTemperature: 4500 NightTemperatureEnabled: true Running: true TimingsEnabled: true TransitionTime: 30 KCM shows correct location.
@David: here are the contents of ~/.config/kded5rc [Module-accounts] autoload=true [Module-appmenu] autoload=true [Module-baloosearchmodule] autoload=false [Module-bluedevil] autoload=true [Module-browserintegrationreminder] autoload=false [Module-colorcorrectlocationupdater] autoload=false [Module-device_automounter] autoload=false [Module-freespacenotifier] autoload=false [Module-kded_printmanager] autoload=true [Module-keyboard] autoload=false [Module-khotkeys] autoload=true [Module-kscreen] autoload=true [Module-ksysguard] autoload=true [Module-ktimezoned] autoload=true [Module-networkmanagement] autoload=true [Module-networkstatus] autoload=true [Module-proxyscout] autoload=true [Module-remotenotifier] autoload=true [Module-statusnotifierwatcher] autoload=true [Module-touchpad] autoload=true [PlasmaBrowserIntegration] shownCount=4 It looks like colorcorrectlocationupdater=false
(In reply to Samantha from comment #25) > It looks like colorcorrectlocationupdater=false Could you please remove this section > [Module-colorcorrectlocationupdater] > autoload=false and check whether colorcorrectlocationupdater is loaded on the next boot?
Turns out that it's not necessary to edit the file manually. Going to background services in system settings and enabling the color correction location updater service is enough. Once that's running, the location is updated correctly. I don't know if it's a bug with the opensuse defaults or what -- I am currently testing a plasma install of Solus and the service is enabled by default without user interaction and auto mode worked out of the box on a fresh install. I think this report is effectively solved -- the user just needs to be aware that the color correction service needs to be enabled if using the automatic mode.
(In reply to Samantha from comment #27) > I think this report is effectively solved -- the user just needs to be aware > that the color correction service needs to be enabled if using the automatic > mode. Well, it's "enabled" by default. The question is why it got "disabled."
Night color is backwards!!! Desktop changes to night color as the sun comes up, and switches to day-time color as the sun goes down. Settings: Mode: Location: Lat: 43 Lon: -1 Same happens in these modes: - Automatic - Time ("Heures" - My desktop runs in French - Should read "Heure", by the way + impossible to edit the times - they are read only) This could be the real culprit behind many of these bug reports.
Git commit e840617047b6e3fa81f4e90055bdbd4752ee5754 by Vlad Zahorodnii, on behalf of Natalie Clarius. Committed on 29/08/2022 at 09:17. Pushed by vladz into branch 'master'. plugins/nightcolor: fix wrong transition time update in location mode M +7 -5 src/plugins/nightcolor/nightcolormanager.cpp https://invent.kde.org/plasma/kwin/commit/e840617047b6e3fa81f4e90055bdbd4752ee5754
Git commit b6b478712c106c30a840c22f6844e415d81b6d0a by Vlad Zahorodnii, on behalf of Natalie Clarius. Committed on 29/08/2022 at 10:19. Pushed by vladz into branch 'Plasma/5.25'. plugins/nightcolor: fix wrong transition time update in location mode (cherry picked from commit e840617047b6e3fa81f4e90055bdbd4752ee5754) M +7 -5 src/plugins/nightcolor/nightcolormanager.cpp https://invent.kde.org/plasma/kwin/commit/b6b478712c106c30a840c22f6844e415d81b6d0a