[GH-ISSUE #767] Remapping DDC brightness control to contrast on external display? #498

New issue

Closed

opened 2026-05-05 06:08:34 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-05-05 06:08:34 -06:00

Owner

Originally created by @waydabber on GitHub (Nov 4, 2021).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/767

Originally assigned to: @waydabber on GitHub.

Discussed in https://github.com/MonitorControl/MonitorControl/discussions/764

^{Originally posted by renaudguerin November 3, 2021}

Before opening the issue, have you...?

Searched for existing issues

My work setup is an Intel MBP -> CalDigit Thunderbolt hub -> USB-C to Displayport cable -> BenQ BL3201PT

This monitor doesn't respond to brightness controls at all with MonitorControl 3.1.1
It does respond to volume and contrast though, and the contrast menu slider works fine.
This means the brightness keys do nothing, and I have to reach for the menu instead.

Describe the solution you'd like

A preference checkbox to enable permanent remapping of Brightness keyboard controls to Contrast instead.
Or (probably cleaner) don't hardcode the mapping of keys -> feature name -> ID at all but make it configurable, with sane defaults out of the box.

Describe alternatives you've considered

As I was writing this I've discovered that 4.0.0 introduces a keyboard shortcut for contrast (Ctrl-Add-Cmd + brightness key)

This is an improvement, but it mostly benefits people who are already able to control brightness using the unmodified keys. In my case, the brightness keys are useless without this complex modifier, so I would much prefer direct access.

I appreciate the concerns around not cluttering the preferences UI, but IMHO some of the current settings are even more niche than this one (e.g. "Further lower brightness via software dimming")

Maybe a "batteries included but optional" approach would work here ? i.e. don't hardcode brightness/contrast/volume controls per se, make the brightness keys-> feature name ->IDs mapping configurable for advanced users, and ship with sane defaults that work for most people.

Anything else?

No response

Originally created by @waydabber on GitHub (Nov 4, 2021). Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/767 Originally assigned to: @waydabber on GitHub. ### Discussed in https://github.com/MonitorControl/MonitorControl/discussions/764 <div type='discussions-op-text'> <sup>Originally posted by **renaudguerin** November 3, 2021</sup> ### Before opening the issue, have you...? - [X] Searched for existing issues ### Is your feature request related to a problem? Please describe My work setup is an Intel MBP -> CalDigit Thunderbolt hub -> USB-C to Displayport cable -> BenQ BL3201PT This monitor doesn't respond to brightness controls at all with MonitorControl 3.1.1 It does respond to volume and contrast though, and the contrast menu slider works fine. This means the brightness keys do nothing, and I have to reach for the menu instead. ### Describe the solution you'd like A preference checkbox to enable permanent remapping of Brightness keyboard controls to Contrast instead. Or (probably cleaner) don't hardcode the mapping of keys -> feature name -> ID at all but make it configurable, with sane defaults out of the box. ### Describe alternatives you've considered As I was writing this I've discovered that 4.0.0 introduces a keyboard shortcut for contrast (Ctrl-Add-Cmd + brightness key) This is an improvement, but it mostly benefits people who are already able to control brightness using the unmodified keys. In my case, the brightness keys are useless without this complex modifier, so I would much prefer direct access. I appreciate the concerns around not cluttering the preferences UI, but IMHO some of the current settings are even more niche than this one (e.g. "Further lower brightness via software dimming") Maybe a "batteries included but optional" approach would work here ? i.e. don't hardcode brightness/contrast/volume controls per se, make the brightness keys-> feature name ->IDs mapping configurable for advanced users, and ship with sane defaults that work for most people. ### Anything else? _No response_</div>

gitea-mirror

2026-05-05 06:08:34 -06:00

closed this issue
added the
bug

done
labels

gitea-mirror commented

2026-05-05 06:08:38 -06:00

Author

Owner

@waydabber commented on GitHub (Nov 4, 2021):

On the Intel codepath the control code override does not work indeed in v4.0.0. Thanks @renaudguerin

This is now fixed, it will work in v4.0.1.

@waydabber commented on GitHub (Nov 4, 2021): On the Intel codepath the control code override does not work indeed in v4.0.0. Thanks @renaudguerin This is now fixed, it will work in v4.0.1.