Sometimes after Windows restart, value of saturation in AMD driver is set to 0

[partoftheworlD]

duplicate of issue #74

Started using vibranceGUI again and this time managed to reproduce the bug. If log out of user account several times, saturation is reset to 0 and can only be restored by manually changing the value.

reproducing bug

vibranceGUI.zip

[juv]

Hi,

thanks for creating this issue. Unfortunately, the AMD version of vibranceGUI is no longer maintained because the contributor for the AMD portion of the code has lost interest. Because I do not have access to an AMD gpu, this will be hard to test and find a solution for. It's unlikely that this can be resolved anytime soon if not someone else steps up and tries to implement a bugfix for this.

[SwatX18]

I think there's a source-provable mechanism for this, and it matches every detail of the report — including why it's "sometimes" and why it's specifically after a restart.

AMD's restore path wrote the Windows saturation level to every display before that level was known.

The proxy subscribes its foreground hook during construction, at VibranceGUI.cs:110 in the form's constructor. But SetVibranceWindowsLevel — the thing that actually loads your saved Windows level out of the INI — isn't reached until VibranceGUI.cs:186, from backgroundWorker_DoWork, which first sits in while (!this.IsHandleCreated) Thread.Sleep(500).

In that window, _vibranceInfo.userVibranceSettingDefault is still the struct default: 0.

And AMD's restore branch called it unconditionally:

_amdAdapter.SetSaturationOnAllDisplays(_vibranceInfo.userVibranceSettingDefault);

So any foreground change arriving between those two points wrote saturation 0 to every attached display. Each detail of the report lines up:

• "Sometimes" — it's a race. You need a foreground event inside that window.
• "after Windows restart" — autostart is exactly when the app is racing its own message loop while the desktop is still settling and windows are appearing.
• "set to 0" — not a low value, precisely 0, because that's the struct default rather than any setting.
• AMD specifically — AMD's path wrote all displays here. NVIDIA's equivalent wrote one arbitrary handle, which is a different and less visible symptom (I've written that one up on VibranceGUI affects secondary screen #60).

Note the ordering makes this independent of your saved level: it isn't that the wrong value was read, it's that the write happened before any value was read at all.

---

I've fixed it on a fork by gating both vendors' restore paths on whether the Windows level has actually been loaded yet: SwatX18/vibranceGUI#11. The guard is one flag set in SetVibranceWindowsLevel and checked at the top of the restore path — restore is simply a no-op until the real level is known, instead of writing a placeholder.

That PR also fixes three related multi-monitor defects in the same area (#60, #36, #144, #95), and it's offered upstream as #160.

Not reproduced on AMD hardware — I don't have an AMD GPU, so this is traced from source rather than confirmed on a machine that shows the symptom. If anyone here still has the setup: the tell is that it only happens when something takes the foreground during the first second or two after launch, so it should be much more likely on a cold boot with autostart than on a manual launch from the desktop.