github-starred/MonitorControl

Fork 0

mirror of https://github.com/MonitorControl/MonitorControl.git synced 2026-05-15 14:15:55 -06:00

[GH-ISSUE #839] SW dimming: conflict with flux even with "avoid gamma manipulation" #531

New issue

Closed

opened 2026-05-05 06:11:33 -06:00 by gitea-mirror · 8 comments

gitea-mirror commented

2026-05-05 06:11:33 -06:00

Owner

Originally created by @krackers on GitHub (Dec 9, 2021).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/839

Originally assigned to: @waydabber on GitHub.

Before opening the issue, have you...?

Searched for existing issues
Looked through the wiki
Updated MonitorControl to the latest version (if applicable)

Describe the bug

(I'm using a lenovo p27-h, but since this issue only occurs when the software dimming option is enabled I'm not sure if it's a monitor specific issue.). Basically, even though I have "ticked the avoid gamma table manipulation" option, I'm still seeing an issue where whenever flux changes the white-point (or it's changed manually via flux), the software dimming resets for a few seconds.

Note that this is different from the behavior that would occur if the "avoid gamma table manipulation" is not enabled. If gamma table manipulation is used, then the software dimming will always reset immediately after being applied. But when shades is used, for some reason software dimming only momentarily resets whenever the white-point is changed by flux.

Steps to reproduce

Tick "avoid gamma table manipulation"
Have flux enabled
Dim the monitor low enough so the SW dimming kicks in
Manually change the white point in flux (or wait for dusk for it to adjust automatically)
Every time it adjusts, software dimming turns off for a few seconds before turning back on.

Expected behavior

Display brightness remains constant even when flux manipulates white point.

Anything else?

Not sure if there's any log files I can attach. Let me know and I'd be happy to do so.

Environment Information (please complete the following information)

- macOS version: 11.6.1
- Mac model: MacBook Pro (16-inch, 2019)
- MonitorControl version:  4.0.1
- Monitor(s): Lenovo p27-h
- Apple Silicon/M1 (yes or no): no

Originally created by @krackers on GitHub (Dec 9, 2021). Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/839 Originally assigned to: @waydabber on GitHub. ### Before opening the issue, have you...? - [X] Searched for existing issues - [X] Looked through [the wiki](https://github.com/MonitorControl/MonitorControl/wiki) - [x] Updated MonitorControl to the latest version (if applicable) ### Describe the bug (I'm using a lenovo p27-h, but since this issue only occurs when the software dimming option is enabled I'm not sure if it's a monitor specific issue.). Basically, even though I have "ticked the avoid gamma table manipulation" option, I'm still seeing an issue where whenever flux changes the white-point (or it's changed manually via flux), the software dimming resets for a few seconds. Note that this is different from the behavior that would occur if the "avoid gamma table manipulation" is _not_ enabled. If gamma table manipulation is used, then the software dimming will always reset immediately after being applied. But when shades is used, for some reason software dimming only momentarily resets whenever the white-point is changed by flux. ### Steps to reproduce 1. Tick "avoid gamma table manipulation" 2. Have flux enabled 3. Dim the monitor low enough so the SW dimming kicks in 3. Manually change the white point in flux (or wait for dusk for it to adjust automatically) 4. Every time it adjusts, software dimming turns off for a few seconds before turning back on. ### Expected behavior Display brightness remains constant even when flux manipulates white point. ### Anything else? Not sure if there's any log files I can attach. Let me know and I'd be happy to do so. ### Environment Information (please complete the following information) ```markdown - macOS version: 11.6.1 - Mac model: MacBook Pro (16-inch, 2019) - MonitorControl version: 4.0.1 - Monitor(s): Lenovo p27-h - Apple Silicon/M1 (yes or no): no ```

gitea-mirror

2026-05-05 06:11:33 -06:00

closed this issue
added the
investigating
label

gitea-mirror commented

2026-05-05 06:11:39 -06:00

Author

Owner

@waydabber commented on GitHub (Dec 14, 2021):

Hey @krackers,

can you post a video (made via your phone) about the issue so I might better understand what is happening? Thank you for your help!

@waydabber commented on GitHub (Dec 14, 2021): Hey @krackers, can you post a video (made via your phone) about the issue so I might better understand what is happening? Thank you for your help!

gitea-mirror commented

2026-05-05 06:11:41 -06:00

Author

Owner

@krackers commented on GitHub (Dec 15, 2021):

Hi, thank you for the quick response. I'm a bit paranoid to take a video since this is a company-issued laptop that has a watermark. However, I was able to narrow down the issue to ICC profile changes.

In particular, I can reliably replicate the issue on my end (even without flux) by just changing the icc profile (via system preferences > displays), which causes the software dimming to reset for a few seconds before turning back on. Flux is known to explicitly modify the ICC profile every time it does the white-point change (see https://justgetflux.com/news/2014/10/28/profile.html), which is probably what caused the issue.

As a workaround for me, I was able to use the linked command to disable flux's ICC profile modification. Feel free to close this issue if you are not able to replicate the ICC profile change induced software dimming issue.

@krackers commented on GitHub (Dec 15, 2021): Hi, thank you for the quick response. I'm a bit paranoid to take a video since this is a company-issued laptop that has a watermark. However, I was able to narrow down the issue to ICC profile changes. In particular, I can reliably replicate the issue on my end (even without flux) by just changing the icc profile (via system preferences > displays), which causes the software dimming to reset for a few seconds before turning back on. Flux is known to explicitly modify the ICC profile every time it does the white-point change (see https://justgetflux.com/news/2014/10/28/profile.html), which is probably what caused the issue. As a workaround for me, I was able to use the linked command to disable flux's ICC profile modification. Feel free to close this issue if you are not able to replicate the ICC profile change induced software dimming issue.

gitea-mirror commented

2026-05-05 06:11:43 -06:00

Author

Owner

@waydabber commented on GitHub (Dec 15, 2021):

Uhh. A watermark? On the screen? That's draconian. I'll try the ICC profile thing. MonitorControl does alter the profile (which actually defines the gammatable) but that should not happen when "avoid gamma table manipulation" is not engaged.

@waydabber commented on GitHub (Dec 15, 2021): Uhh. A watermark? On the screen? That's draconian. I'll try the ICC profile thing. MonitorControl does alter the profile (which actually defines the gammatable) but that should not happen when "avoid gamma table manipulation" is not engaged.

gitea-mirror commented

2026-05-05 06:11:44 -06:00

Author

Owner

@waydabber commented on GitHub (Dec 21, 2021):

Hi @krackers - I am unable to reproduce this issue. I did the following:

enable Avoid gamma table manipulation.
Disable Hardware DDC control (so software control kicks in).
Dim the display somewhat.
Changed the whitepoint by moving the topmost slider in f.lux preferences.

It seems to work as expected. I am running f.lux 41.5. I tried the same with combined HW/SW control as well.

When the color profile profile is changed in System Preferences, it initiates a full display reconfiguration - this removes the shade briefly - but this is normal and expected.

@waydabber commented on GitHub (Dec 21, 2021): Hi @krackers - I am unable to reproduce this issue. I did the following: - enable `Avoid gamma table manipulation`. - Disable `Hardware DDC control` (so software control kicks in). - Dim the display somewhat. - Changed the whitepoint by moving the topmost slider in f.lux preferences. It seems to work as expected. I am running f.lux 41.5. I tried the same with combined HW/SW control as well. When the color profile profile is changed in System Preferences, it initiates a full display reconfiguration - this removes the shade briefly - but this is normal and expected.

gitea-mirror commented

2026-05-05 06:11:45 -06:00

Author

Owner

@waydabber commented on GitHub (Dec 21, 2021):

Is there maybe some other trick to reproduce this issue? I know that f.lux had issues with some Macs on Monterey and there were some workarounds for it, maybe they do a full color profile reset somehow and that's what triggers a display reconfiguration.

You could check the console logs and see if there is a reconfiguration every time the issue happens: https://github.com/MonitorControl/MonitorControl/discussions/851

@waydabber commented on GitHub (Dec 21, 2021): Is there maybe some other trick to reproduce this issue? I know that f.lux had issues with some Macs on Monterey and there were some workarounds for it, maybe they do a full color profile reset somehow and that's what triggers a display reconfiguration. You could check the console logs and see if there is a reconfiguration every time the issue happens: https://github.com/MonitorControl/MonitorControl/discussions/851

gitea-mirror commented

2026-05-05 06:11:47 -06:00

Author

Owner

@krackers commented on GitHub (Dec 22, 2021):

Thanks for the investigation. Those repro steps seem correct to me. I do indeed see the following logged

monitor control job died because of sleep or reconfiguration

whenever the dimming gets disrupted due to f.lux's whitepoint changes.
We can close and move to the discussions section if you want, since it seems whatever particular combination that causes this is rare enough, it seems to be an issue on f.lux end (since you stated shade disruption on display reconfiguration is expected behavior), and there exists a workaround (albeit at the cost of color temperature disruptions when switching between internal & external monitor)..

@krackers commented on GitHub (Dec 22, 2021): Thanks for the investigation. Those repro steps seem correct to me. I do indeed see the following logged ``` monitor control job died because of sleep or reconfiguration ``` whenever the dimming gets disrupted due to f.lux's whitepoint changes. We can close and move to the discussions section if you want, since it seems whatever particular combination that causes this is rare enough, it seems to be an issue on f.lux end (since you stated shade disruption on display reconfiguration is expected behavior), and there exists a workaround (albeit at the cost of color temperature disruptions when switching between internal & external monitor)..

gitea-mirror commented

2026-05-05 06:11:47 -06:00

Author

Owner

@waydabber commented on GitHub (Dec 22, 2021):

Yes, it seems f.lux does something on your setup which is not happening on mine and it causes a full display reconfiguration which triggers the destruction and recreation of the shade overlays (the alternate for gamma dimming). I think the problem here is with f.lux.

Thanks for the confirmtion, I'll close this issue now.

@waydabber commented on GitHub (Dec 22, 2021): Yes, it seems f.lux does something on your setup which is not happening on mine and it causes a full display reconfiguration which triggers the destruction and recreation of the shade overlays (the alternate for gamma dimming). I think the problem here is with f.lux. Thanks for the confirmtion, I'll close this issue now.

gitea-mirror commented

2026-05-05 06:11:49 -06:00

Author

Owner

@waydabber commented on GitHub (Dec 22, 2021):

Or even better, I'll convert this to a discussion so others with this issue might be able to figure out what is happening.

@waydabber commented on GitHub (Dec 22, 2021): Or even better, I'll convert this to a discussion so others with this issue might be able to figure out what is happening.

gitea-mirror referenced this issue

2026-05-05 07:04:58 -06:00

[PR #531] [MERGED] Update German translation #1114