search

lgblgblgb / xemu

Emulations (running on Linux/Unix/Windows/macOS, utilizing SDL2) of some - mainly - 8 bit machines, including the Commodore LCD, Commodore 65, and the MEGA65 as well.
https://github.com/lgblgblgb/xemu/wiki
GNU General Public License v2.0
208 stars 32 forks source link

UI: Xemu affects Windows 10's night shift mode #351

Closed godot64 closed 2 years ago

godot64 commented 2 years ago

Everytime you ran Xemu, the Windows 10 night shift is turned off. You can only re-start the computer to get rid of this setting, (which I think is) invoked by Xemu.

This occurs on any version of Xemu and any version of Mega65 ROM.

lgblgblgb commented 2 years ago

Thanks for the report. Xemu alone does nothing to turn any feature like this on/off, so I have the suspect that it's something done by SDL2 itself what Xemu uses, as Xemu is basically an SDL2 application. Honestly I am not even aware of that feature as my whole Windows experience is because of porting and supporting Xemu for Windows users, I never use Windows otherwise. But I'll try to google for some solution what SDL2 exactly does internally which can cause this ...

godot64 commented 2 years ago

I see! You probably use this Flag: SDL_SetWindowGammaRamp and set it to max values?

Arndt

lgblgblgb commented 2 years ago

@godot64

Isn't this a Windows bug? I mean an application of any OS should not have ever any impact on the OS after the program terminates and no longer running. However you wrote, that you need to re-start your computer to get back this functionality regardless (?) you have quitted Xemu already. In my eye, it is a serious windows problem, Microsoft should fix. Surely I am all with fixing Xemu bugs, so I don't write these so I don't need to do anything here ... just it sounds very strange for me ... So for sure I can start to do experiments with workarounds but somehow I feel it's like I want to fix Windows from Xemu ;)

But ok, let it be. back to the main topic: I am not really sure what I can do with that SDL2 function. It expects a 256 element Uint16 array for the R, G and B channels. So I suppose I should create some gradient table or so. But in any way, trying to set it myself seems to defeat the purpose since if I try to set some default gamma mapping table is the opposite of these kind of night modes which intended not to use the default mapping, but some other kind to shift colours to the yellow-kind spectrum and reduce blue ... Maybe I can try to use the "Get" variant of the mentioned function and store result and re-apply before exit? But not sure when SDL2 decides (and how it does that!) to mess Windows' idea on this night mode - also windows pointer is already needed thus it may not help anything already. Unfortunately I haven't found too much relevant info with trying to google for similar problems with Windows & SDL2. Since I think, this is kind of SDL2 issue on Windows then (since I don't set any Windows specific thing myself in Xemu which can cause this, I guess, thus must be SDL2 itself) . But as far as I can see, if it's really an SDL2 level problem, there should be other software using SDL2 showing similar behaviour with Windows.

Also, while trying to google for the problem, I've encountered many posts which is about windows night mode problems and how to fix it, some even suggests that it's totally broken, you need reinstall Windows (or using better third party apps instead of the functionality from Windows), and so on. So it really tells me, there is some fundamental problem here, hard to fix from an application. But let it be clear, I have marginal knowledge on Windows, so I can't judge too much here, just mentioning. For example:

https://pureinfotech.com/fix-night-light-windows-10/

And texts in it like:

If you want to give F.lux a try, at least until Microsoft fixes its own feature, you can learn how to get F.lux and set it up using this guide.

Or articles like this:

https://www.technipages.com/fix-windows-10-night-light-greyed-out

It seems it's a common point in these kind of posts/articles that windows 10 night light mode is totally broken and/or brakes after OS updates and/or needs GPU drives updated/reinstalled, etc.

However I just write these since you are being a Windows user may be able to get some information from these, unlike me, since I am not even a Windows user.

godot64 commented 2 years ago

Maybe I can try to use the "Get" variant of the mentioned function and store result and re-apply before exit?

This was my idea. I assume that a windows application gets this array on startup and rebuilds it when exiting. Not sure if that assumption matches the win10 guidelines.

Anyway, I just stumbled upon this behavior, so I thought I'll report it.

lgblgblgb commented 2 years ago

To be honest with you, I wouldn't assume that a program should have any effect after you exit from the program ... It would be crazy, endanger the whole OS security if a regular process just sets something and remained that way after you exited that program (again, if the process does not have any admin privileges and so on).

Also I can feel "chicken&egg" problem here, for the "get" function to work, I need an SDL window object already exists. Which is already modified gamma ramping (probably, if this is really the problem ...). I cannot use the function earlier as it depends on SDL and window initialization already done, which potentially the problem here?

Can you compile Xemu yourself? The problem here, that I wouldn't start to "play" with these in official release too much, but somehow it could be tested if it does anything for you in this scenario, or useless ...

Other suggestion: if you have any idea on software using SDL2, you can try if it has similar effect, besides Xemu.

godot64 commented 2 years ago

Also I can feel "chicken&egg" problem here

Hehe... :-) In the meantime I googled about that problem, and it seems that there's a known problem with the nightshift function. So, I'm sorry to have reported an Xemu issue at all since the thing has seemingly nothing at all to do with Xemu. Sorry again. Please close this issue. Thank you for your patience! And thank you for the good work on Xemu! :-)

Arndt

lgblgblgb commented 2 years ago

@godot64 Yes, I've quoted some findings above already that it seems there are issues with nightshift according to google, that was the main reason I was a bit sceptical that I can help with that, if it's more an OS issue than Xemu's ...

No problem, every report can be important, and we cannot know at the beginning what kind of issue it is. So it's better to report and investigate at least to some degree than ignoring reports right at the beginning! So please feel free in the future to report issues/ideas, and do not feel bad about that. Thanks.