I'm not able to reproduce this on git-master (but I do see an unrelated bug with the mouse cursor being stuck)

Steps to reproduce
1. Chose Breeze Dark as the global theme, toggled on dark mode at night
2. Configured a manual Day-Night Cycle so sunset was before the current time and ended in the morning. Breeze Dark was correctly applied.
3. Put laptop to sleep
4. Woke laptop
Observed that the night light color was applied and Breeze Dark was in use.

5. Chose a different color theme in Colors & Themes
No crash / black screen, colors were applied

The fact that after step 5, the screen is black except for the mouse cursor, indicates a crash or other misbehavior of kwin. Can you see if there's a coredump on your system for kwin or plasmashell from the time you forced the color scheme?  If there is, can you please attach a backtrace of the crash using the coredumpctl command-line program? See this for details on doing both of those - https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl ?

(In reply to TraceyC from comment #1)
> I'm not able to reproduce this on git-master (but I do see an unrelated bug
> with the mouse cursor being stuck)
> 
> Steps to reproduce
> 1. Chose Breeze Dark as the global theme, toggled on dark mode at night
> 2. Configured a manual Day-Night Cycle so sunset was before the current time
> and ended in the morning. Breeze Dark was correctly applied.
> 3. Put laptop to sleep
> 4. Woke laptop
> Observed that the night light color was applied and Breeze Dark was in use.
> 
> 5. Chose a different color theme in Colors & Themes
> No crash / black screen, colors were applied
> 
> The fact that after step 5, the screen is black except for the mouse cursor,
> indicates a crash or other misbehavior of kwin. Can you see if there's a
> coredump on your system for kwin or plasmashell from the time you forced the
> color scheme?  If there is, can you please attach a backtrace of the crash
> using the coredumpctl command-line program? See this for details on doing
> both of those -
> https://community.kde.org/Guidelines_and_HOWTOs/Debugging/
> How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl ?

Hi,

I couldn't find a coredump.

I tried restarting plasmashell with the commands 
- kquitapp6 plasmashell
- kstart plasmashell
My desktop was working again. But when I tried to close a notification, plasmashell froze.
When I switched to a tty and then back to the plasmashell tty, I had a black screen. Only the mouse could move.

No coredumpctl available.

After trying several times to reproduce the initial bug, I think that it may not be the night/day change that is causing the bug. But perhaps it is the computer waking up after going into standby mode.

If the system is hard-locking, it might well be a graphics card or kernel bug. Just to make sure, you see nothing relevant in "journalctl -S today" after the freeze happens (and rebooting)?

Created attachment 184093 [details]
journatcl 23.18 to 23:32

(In reply to FoxOdd from comment #4)
> Created attachment 184093 [details]
> journatcl 23.18 to 23:32

I performed the following steps:
- Put the computer to sleep at 23h18
- Woke the computer up at 23h32.

Before the screen went black, I was able to note the message from the kwin notification (translated from French): “The desktop effects have been reset following a reset of the graphics module.” 

Then, from a tty, I retrieved all the logs with the command: journtactl --since “23:18” --until “23:32”

Thanks so much for the system logs. Some interesting parts:

août 14 23:32:31  kernel: NVRM: Xid (PCI:0000:2d:00): 13, Graphics Exception: Shader Program Header 11 Error
août 14 23:32:31  kernel: NVRM: Xid (PCI:0000:2d:00): 13, Graphics Exception: Shader Program Header 18 Error
août 14 23:32:31  kernel: NVRM: Xid (PCI:0000:2d:00): 13, Graphics Exception: ESR 0x405840=0xa2040800
août 14 23:32:31  kernel: NVRM: Xid (PCI:0000:2d:00): 13, Graphics Exception: ESR 0x405848=0x80000000
août 14 23:32:31  kernel: NVRM: Xid (PCI:0000:2d:00): 13, pid=1889, name=kwin_wayland, Graphics Exception: ChID 00dc, Class 0000c597, Offset 00000000, Data 00000000

There are a lot of these

août 14 23:32:45  kwin_wayland[1889]: kwin_wayland_drm: EglGbmLayerSurface::renderTestBuffer: failed to make opengl context current
août 14 23:32:45  kwin_wayland[1889]: kwin_wayland_drm: Checking test buffer failed!


août 14 23:32:45  kwin_wayland[1889]: kwin_core: Applying output configuration failed!
août 14 23:32:45  kwin_wayland[1889]: kwin_wayland_drm: EglGbmLayerSurface::renderTestBuffer: failed to make opengl context current
août 14 23:32:45  kwin_wayland[1889]: kwin_wayland_drm: Checking test buffer failed!
août 14 23:32:45  kwin_wayland[1889]: kwin_wayland_drm: EglGbmLayerSurface::renderTestBuffer: failed to make opengl context current
août 14 23:32:45  kwin_wayland[1889]: kwin_wayland_drm: Checking test buffer failed!

I'll let the kwin developers take a closer look.

i seem to have the opposite issue on Fedora Asahi Remix, though it seems to stem from the same problem. i have a night light schedule that starts at 6PM and ends at 4AM. if i leave my laptop to sleep while in night light mode (say ~midnight) then come back the following morning after the night light schedule should have ended, it does not, instead the night light screen temperature is still applied, and that is the despite the fact the brightness and colour applet reports daytime temperature. if i then go to the night light settings and preview some different temperature, the display will then afterwards return to the desired daytime temperature.

SOFTWARE/OS INFORMATION
Operating System: Fedora Linux Asahi Remix 42
KDE Plasma Version: 6.5.4
KDE Frameworks Version: 6.21.0
Qt Version: 6.9.3
Kernel Version: 6.17.12-400.asahi.fc42.aarch64+16k (64-bit)
Graphics Platform: Wayland
Processors: 6 × Apple Firestorm (M1 Pro), 2 × Apple Icestorm (M1 Pro)
Memory: 31.1 GiB of usable RAM
Graphics Processor 1: Apple M1 Pro
Graphics Processor 2: llvmpipe
Product Name: Apple MacBook Pro (14-inch, M1 Pro, 2021)

(In reply to Talya from comment #7)
> i seem to have the opposite issue on Fedora Asahi Remix, though it seems to
> stem from the same problem. 

To determine if these both have the same root cause, we need to compare logs. Can you attach system logs, generated the same was as was asked for in comment 3? Thanks!

Created attachment 188314 [details]
journalctl asahi "today" (0:00 to 10:58)

There are a few
> atomic commit failed: Device or resource busy
but that shouldn't be relevant. Colors get updated whenever KWin renders any image, it's not limited to doing it at some specific time.

When the color temperature is wrong, does just changing brightness or the display refresh rate correct it, or is the color temperature preview needed?

If it's the former, then the issue will be on the drm level, but if it's the latter, then maybe the night light plugin doesn't properly re-compute the color temperature after suspend.

just ran a quick test and indeed changing the brightness or the refresh rate did not help (which was as i remembered but i wanted to test to make sure). interestingly enough neither did changing the day/night schedule help, which makes sense since it's not like KDE thinks it's still in night mode, it doesn't, it just displays as if it is.
also attaching the journal from right before it went into night mode (at 12:30), then sleep in night mode, then being woken up, just in case it helps.

Created attachment 188865 [details]
journalctl output from test with refresh rate and brightness

Good, that at least narrows it down to the night light plugin. I don't currently see anything obviously wrong with the code though, and also no suspicious warnings in your log.