github-starred/MonitorControl

Fork 0

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

[GH-ISSUE #570] Option to alter the brightness & volume slider skew (mapping curve) #425

New issue

Closed

opened 2026-05-05 05:58:44 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 05:58:44 -06:00

Owner

Originally created by @waydabber on GitHub (Sep 7, 2021).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/570

Originally assigned to: @waydabber on GitHub.

Before opening the issue, have you...?

Searched for existing issues

For some displays the volume and brightness curve of the display is uneven - it is common that most of the visible changes in brightness happen between 0-10% of the curve and also the volume curve can be such that beyond 20% starts the too loud category - so the actually sensible range to deal with is the 10-20% of the slider.

Describe the solution you'd like

This problem could be solved by introducing a setting to have an upward opening parabola/exponential curve for brightness with a setting for a curve factor (combined with an upper bound setting for volume which allows the remapping of the the sensible maximum to 100% - this is already planned in https://github.com/MonitorControl/MonitorControl/issues/310).

Describe alternatives you've considered

Anything else?

No response

Originally created by @waydabber on GitHub (Sep 7, 2021). Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/570 Originally assigned to: @waydabber on GitHub. ### Before opening the issue, have you...? - [X] Searched for existing issues ### Is your feature request related to a problem? Please describe For some displays the volume and brightness curve of the display is uneven - it is common that most of the visible changes in brightness happen between 0-10% of the curve and also the volume curve can be such that beyond 20% starts the too loud category - so the actually sensible range to deal with is the 10-20% of the slider. ### Describe the solution you'd like This problem could be solved by introducing a setting to have an upward opening parabola/exponential curve for brightness with a setting for a curve factor (combined with an upper bound setting for volume which allows the remapping of the the sensible maximum to 100% - this is already planned in https://github.com/MonitorControl/MonitorControl/issues/310). ### Describe alternatives you've considered - ### Anything else? _No response_

gitea-mirror

2026-05-05 05:58:44 -06:00

closed this issue
added the
enhancement

done
labels

gitea-mirror commented

2026-05-05 05:58:49 -06:00

Author

Owner

@JoniVR commented on GitHub (Sep 7, 2021):

Wouldn't a regular min/max setting work fine here? Feel like custom curves are going to complicate things a bit? E.g. if most of the brightness happens between 1-10, just set 10 as max?

I personally don't think we can ever cover all edge cases for everyone, I also don't think we should try to do so (maintenance burden etc). There's just too many weird variations (reversed controls, weird scales, random mute behaviour, flickering,...).

Stuff like curves seems to be part of Lunar though, so perhaps we could point users who need extreme customisation to it? Seems like a thing to do after the help we received :) Just a my 2 cents though, if you disagree, let me know :)

@JoniVR commented on GitHub (Sep 7, 2021): Wouldn't a regular min/max setting work fine here? Feel like custom curves are going to complicate things a bit? E.g. if most of the brightness happens between 1-10, just set 10 as max? I personally don't think we can ever cover all edge cases for everyone, I also don't think we should try to do so (maintenance burden etc). There's just too many weird variations (reversed controls, weird scales, random mute behaviour, flickering,...). Stuff like curves seems to be part of Lunar though, so perhaps we could point users who need extreme customisation to it? Seems like a thing to do after the help we received :) Just a my 2 cents though, if you disagree, let me know :)

gitea-mirror commented

2026-05-05 05:58:51 -06:00

Author

Owner

@waydabber commented on GitHub (Sep 7, 2021):

Yes, Lunar is a great app and I completely agree that we could direct users with 'special needs' to it! @alin23 will be delighted! :)

You are right, for volume, simply setting a max is fine as beyond a specific point (everything above a subjective "loud") is not really needed by the user. A curve probably just complicates things.

For brightness on the other hand, I am not so sure. I am afraid a simple max setting is not enough since if we set the brightness max at 10 artificially for example, we loose the ability to set the backlight to maximum. In terms of brightness the problem is that the brightness curve is non linear - a change from 0 to the value 10 might feel a 50% difference in perceived brightness, while a change from the value 10 to the max 100 accounts for the remaining 50%. The user still needs the entire scale since he definitely wants to set the brightness to maximum at some point (for example during daytime) but at night he/she wants fine control on the lower end of the spectrum, exactly where the display does not handle the brightness linearly - and is frustrated that the he can't easily achieve the desired effect (especially with the keyboard where one chiclet change in the lower end of the spectrum might feel for a sudden 20% change in perceived brightness). This is why I feel that the right solution to this problem is to provide an advanced option to adjust the brightness curve.

About the curve, I don't propose much, only a simple number (or some pre-determined sets of number with some phantasy names) for adjustment. The curve in this context means how steep the actual change is based on the slider value. The default is the following which maps 1:1 the slider/osd level to the display's brightness setting:

if we simply change p in ((x/100)^p)*100 (which we could use to calculate the curve) then we can get an adjusted curve. For p=1.5 we get:

for p=2 we get:

With this curve, if the slider is at 50%, the display's brightness will still be at about 25%.

With a simple adjustment as this we could compensate for the nonlinearity of the display brightness controls and fit the slider/OSD control to the perceived brightness.

@waydabber commented on GitHub (Sep 7, 2021): Yes, Lunar is a great app and I completely agree that we could direct users with 'special needs' to it! @alin23 will be delighted! :) You are right, for volume, simply setting a max is fine as beyond a specific point (everything above a subjective "loud") is not really needed by the user. A curve probably just complicates things. For brightness on the other hand, I am not so sure. I am afraid a simple max setting is not enough since if we set the brightness max at 10 artificially for example, we loose the ability to set the backlight to maximum. In terms of brightness the problem is that the brightness curve is non linear - a change from 0 to the value 10 might feel a 50% difference in perceived brightness, while a change from the value 10 to the max 100 accounts for the remaining 50%. The user still needs the entire scale since he definitely wants to set the brightness to maximum at some point (for example during daytime) but at night he/she wants fine control on the lower end of the spectrum, exactly where the display does not handle the brightness linearly - and is frustrated that the he can't easily achieve the desired effect (especially with the keyboard where one chiclet change in the lower end of the spectrum might feel for a sudden 20% change in perceived brightness). This is why I feel that the right solution to this problem is to provide an advanced option to adjust the brightness curve. About the curve, I don't propose much, only a simple number (or some pre-determined sets of number with some phantasy names) for adjustment. The curve in this context means how steep the actual change is based on the slider value. The default is the following which maps 1:1 the slider/osd level to the display's brightness setting: <img width="348" alt="Screen Shot 2021-09-07 at 23 46 18" src="https://user-images.githubusercontent.com/37590873/132415013-1fc66e05-c158-4f37-9fa0-a48209a8b9a9.png"> if we simply change `p` in `((x/100)^p)*100` (which we could use to calculate the curve) then we can get an adjusted curve. For `p=1.5` we get: <img width="351" alt="Screen Shot 2021-09-07 at 23 48 24" src="https://user-images.githubusercontent.com/37590873/132415242-2993087b-1666-4eee-bede-a217e936a191.png"> for `p=2` we get: <img width="349" alt="Screen Shot 2021-09-07 at 23 49 19" src="https://user-images.githubusercontent.com/37590873/132415369-8acccd3e-73fc-4912-8bcc-2f8030d18e71.png"> With this curve, if the slider is at 50%, the display's brightness will still be at about 25%. With a simple adjustment as this we could compensate for the nonlinearity of the display brightness controls and fit the slider/OSD control to the perceived brightness.

gitea-mirror commented

2026-05-05 05:58:53 -06:00

Author

Owner

@JoniVR commented on GitHub (Sep 8, 2021):

Sounds good to me, let's do it :D

@JoniVR commented on GitHub (Sep 8, 2021): Sounds good to me, let's do it :D

gitea-mirror commented

2026-05-05 05:58:56 -06:00

Author

Owner

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

See screenshots of the implementation in the v3.1.0 preliminary discussion.

@waydabber commented on GitHub (Sep 15, 2021): See screenshots of the implementation in the [v3.1.0 preliminary discussion](https://github.com/MonitorControl/MonitorControl/discussions/596).