No color changes under Windows Insider 19H1
@rseiler okay I put 18845 under our compatibility just now.
Thankfully I found this thread - my F.lux wasn't working with build 18342 and my eyes were burning out staring at my BLUE screen after dark! I just manually closed F.lux and reopened it and it turned on (PHEW)! So glad to have it back. Hope it's fixed in a new build soon.
Intel Corporation 220.127.116.1172: Intel(R) HD Graphics 630 (20190129)
Generic PnP Monitor, 16 x 9mm, built 2016
sRGB gamut: 91%, AdobeRGB gamut: 64%
Windows Build: 18342
Does it make any sense that the workaround mode could possibly cause some black video blotching/tearing in some apps some of the time (Outlook seems to be the main one seeing this)? The black "blocks" randomly flash in a portion of the window and then disappear.
It took me forever to realize that f.lux was doing it, since it's not a constant thing at all, though only since the workaround has been needed.
Well I am not aware that blacks should be affected by it.
I know about some flashing like this in 1803/1809, due to the way the profiles are loaded/reset from Windows. Generally the bug we are working around in the shipping versions is that the system treats any device change (like a bluetooth headset or USB insert) as a "reset" to the color system, and so we have to race around trying to fix it. I don't know what is going on in this new version yet, but I am watching - guess we have another potential release later today.
@herf That's right, 18348 is out.
Just to explain it a little better in case it matters, it's not that blacks are affected exactly, but black artifacts appear randomly over non-black areas. In this sense, you might say that it's whites being affected, or at least anything not black.
@rseiler Downloading, will see what's going on in a couple hours...
@rseiler pushed another compatibility update.
The problem MAY be fixed.
I hadn't noticed that 18348 (Mar 1) had this in the release notes:
"If you use third party apps to adjust the color of your screen, we’ve made a fix with this build to address feedback that certain apps were no longer working. We’re continuing to investigate feedback in this space."
And today's 18850 has the same note.
Did you find 18348 still needed the workaround? I'm about to try 18850, so I don't know about it yet, but it should be in the same boat as 18348/18351.
Updating our test machine now! 18348 did not work but I am hoping for a fix in the '50s somewhere. :)
18850 doesn't work, either, so maybe they're working their way through third party apps (I'm not aware of any others, though they must exist).
18851 is working. Looking at what is new there.
That's surprising, since the release notes for 18351 didn't mention anything about this other than the usual note that they're still looking at issues.
But based on that trajectory (the build after when they said they fixed it actually does), I'd expect next week's 20H1 (post 18850) build to also have the fix.
herf last edited by herf
Pushed 4.97 beta with full compatibility under 18351. Looks like everything is working a lot better now.
The main (release) build will work also, but this one should be more efficient.
Flickering while using 4.97 with 18356 caused me to have to un install f.lux for the time being...
@breezewood can you share any details? When does it flicker? I am seeing lots of regressions in these insider builds.
Ok I think these things are fixed in the 4.99 beta.
I've installed beta 4.99 on a Build 18362 (19H1) , Windows Nightlight isn't running, but still f.lux does not change the color of my displays. I've 2 displays hooked up on af DisplayLink running the latest driver vers. 9.1 M0 19 Mar 2019.
Sadly vers. 4.100 didn't do anything either ;-(