[GH-ISSUE #100] Fix F14/F15 keys for native Apple Keyboards (They should not change brightness)

gitea-mirror commented

2026-05-05 04:57:48 -06:00

Owner

Originally created by @kikiwora on GitHub (Jun 2, 2019).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/100

Originally assigned to: @waydabber on GitHub.

I have an issue with F14/F15 keys. When this app is launched, F15 decreases brightness and F15 increases brightness, but that is not an action I want them to do.
If I kill MonitorControl, this issue disappears.

By default, macOS uses those keys for non-Apple devices to control display brightness, but I've disabled that already. The issue is with this app itself or one of its dependencies.

It seems like this app deliberately listens for F14/F15 keypress to change brightness.

I want to be able to disable this behavior as a user.

I know that these keys are used by hackintoshes when rerouting brightness keys (exactly to F14/F15) to work in macOS, and thus assume that this is a feature for them.
But it bothers me a lot, cause I use F14/F15 for custom actions.

Please, add an option to disable this behavior. It would be great.

Originally created by @kikiwora on GitHub (Jun 2, 2019). Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/100 Originally assigned to: @waydabber on GitHub. I have an issue with F14/F15 keys. When this app is launched, F15 decreases brightness and F15 increases brightness, but that is not an action I want them to do. If I kill MonitorControl, this issue disappears. By default, macOS uses those keys for non-Apple devices to control display brightness, but I've disabled that already. The issue is with this app itself or one of its dependencies. It seems like this app deliberately listens for F14/F15 keypress to change brightness. I want to be able to disable this behavior as a user. I know that these keys are used by hackintoshes when rerouting brightness keys (exactly to F14/F15) to work in macOS, and thus assume that this is a feature for them. But it bothers me a lot, cause I use F14/F15 for custom actions. Please, add an option to disable this behavior. It would be great.

gitea-mirror

2026-05-05 04:57:48 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 04:57:54 -06:00

Author

Owner

@JoshuaOrphir commented on GitHub (Jun 12, 2019):

I experience the small annoying behaviour with F14/F15 as well as the eject key. Unfortunately this is a dealbreaker since I have those mapped to another application. +1 for high priority.

@JoshuaOrphir commented on GitHub (Jun 12, 2019): I experience the small annoying behaviour with F14/F15 as well as the eject key. Unfortunately this is a dealbreaker since I have those mapped to another application. +1 for high priority.

gitea-mirror commented

2026-05-05 04:57:57 -06:00

Author

Owner

@ghost commented on GitHub (Apr 9, 2020):

Same here. This is currently the only downside of this wonderful tool as F14/F15 is used by me for other global shortcuts already which don't work anymore if I start MonitorControl.

@ghost commented on GitHub (Apr 9, 2020): Same here. This is currently the only downside of this wonderful tool as F14/F15 is used by me for other global shortcuts already which don't work anymore if I start MonitorControl.

gitea-mirror commented

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

Author

Owner

@tomtastic commented on GitHub (Jul 3, 2020):

Agree, it seems the un-modified key codes (at least on this Magic Keyboard with Numpad), for F14 and F15 are :

Key Down
	Characters:	
	Unicode:		63249 / 0xf711
	Keys:		F14
	Key Code:	107 / 0x6b
	Modifiers:	8388864 / 0x800100 ⓘ

Key Down
	Characters:	
	Unicode:		63250 / 0xf712
	Keys:		F15
	Key Code:	113 / 0x71
	Modifiers:	8388864 / 0x800100 ⓘ

And this projects dependancy on MediaKeyTap means that both these key codes are intercepted for Brightness events in functionKeyCodeToMediaKey() :
a1bb7490ee/MediaKeyTap/MediaKeyTap.swift (L129)

@tomtastic commented on GitHub (Jul 3, 2020): Agree, it seems the un-modified key codes (at least on this Magic Keyboard with Numpad), for F14 and F15 are : ``` Key Down Characters:  Unicode: 63249 / 0xf711 Keys: F14 Key Code: 107 / 0x6b Modifiers: 8388864 / 0x800100 ⓘ Key Down Characters:  Unicode: 63250 / 0xf712 Keys: F15 Key Code: 113 / 0x71 Modifiers: 8388864 / 0x800100 ⓘ ``` And this projects dependancy on [MediaKeyTap](https://github.com/the0neyouseek/MediaKeyTap) means that both these key codes are intercepted for Brightness events in functionKeyCodeToMediaKey() : https://github.com/the0neyouseek/MediaKeyTap/blob/a1bb7490ee66438f6c83c2c26aa35608c7d1ef0c/MediaKeyTap/MediaKeyTap.swift#L129

gitea-mirror commented

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

Author

Owner

@tomtastic commented on GitHub (Oct 7, 2020):

I'm using the recently released version 2.1.0, and the F14/F15 keys are still being intercepted by MonitorControl.

@tomtastic commented on GitHub (Oct 7, 2020): I'm using the recently released version 2.1.0, and the F14/F15 keys are still being intercepted by MonitorControl.

gitea-mirror commented

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

Author

Owner

@JoniVR commented on GitHub (Oct 7, 2020):

That's correct, this isn't implemented in MonitorControl yet, I provided a parameter in MediaKeyTap to ignore those keys but the default is still to listen for them, so we don't break existing behaviour.

I was planning on adding this as an option in preferences. Feel free to open a PR to do it yourself if you don't want to wait for me to do it soon, sorry if you were hoping 2.1.0 would already fix it.

@JoniVR commented on GitHub (Oct 7, 2020): That's correct, this isn't implemented in MonitorControl yet, I provided a parameter in MediaKeyTap to ignore those keys but the default is still to listen for them, so we don't break existing behaviour. I was planning on adding this as an option in preferences. Feel free to open a PR to do it yourself if you don't want to wait for me to do it soon, sorry if you were hoping 2.1.0 would already fix it.

gitea-mirror commented

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

Author

Owner

@tomtastic commented on GitHub (Oct 7, 2020):

My bad, I saw the merged PR above and thought the fix was in!

@tomtastic commented on GitHub (Oct 7, 2020): My bad, I saw the merged PR above and thought the fix was in!

gitea-mirror commented

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

Author

Owner

@ElhemEnohpi commented on GitHub (Jul 1, 2021):

I just started using MonitorControl, and find it very helpful, thanks.

I also experienced problems with keyboard shortcuts though, using a MacBook with a non-Apple USB keyboard and external display. It seems to me that MonitorControl doesn't interact correctly with System Preferences > Keyboard > Shortcuts. I'm not able to remap F14/F15 for other purposes, because MonitorControl takes over the keys. If I map other keys to brightness, they don't work as expected with MonitorControl.

I'm using Mojave with "Displays have separate Spaces". I've found a work-around using Karabiner Elements, see below.

@JoniVR wrote:

I provided a parameter in MediaKeyTap to ignore those keys ... I was planning on adding this as an option in preferences.

Why would this need to be a MonitorControl preferences option, rather than just following the OS settings? It seems like the solution, if possible, is not just ignoring F14/F15, but listening for "brightness" keys as set in System Preferences, which it doesn't currently do. In other words, if the computer has System Preferences > Keyboard > Shortcuts > Display set to use F14/F15 for brightness then use them, if something else (or nothing), then use that instead. I think this wouldn't break existing behaviour for users; on my system anyway, F14/F15 were set by default to be brightness.

I have a USB keyboard made for Windows, and I tried setting F1/F2 to adjust brightness in System Preferences, rather than F14/F15 (aka Scroll Lock / Pause on my keyboard). But it doesn't work as expected. With MonitorControl running, if I have the lid of my MacBook open, I expected F1/F2 on the USB keyboard to work the same as the brightness keys on the built-in keyboard, adjusting the brightness of the active display. Instead, they always adjust the internal display, rather than the external monitor, even when the external monitor is active. If the lid is closed, F1/F2 do nothing. F14/F15 still adjust the active display, which I would not expect since I've unset them in System Preferences. I'm not able to assign them to another function in System Preferences.

On the other hand, if I map F1/F2 to brightness using BetterTouchTool, then unlike with System Preferences, they do work as expected, adjusting the active screen. However, mapping F14/F15 to another purpose with BetterTouchTool is still not possible, as MonitorControl also overrides it, forcing them to be brightness.

I found that Karabiner Elements 12 allows me to re-map "Scroll Lock" and "Pause" (as opposed to F14/F15), which stops MonitorControl's takeover of those keys. For example, I can change them to F16/F17 (not present on my keyboard), then adjust my BetterTouchTool settings to use those instead of F14/F15. Probably you can also assign these to something in System Preferences, but I haven't tested it. You can also use Karabiner directly to run a shell script etc., and like BTT, mapping F1/F2 to brightness does work as expected with MonitorControl, adjusting the active display. I don't know if there's a similar work-around in Karabiner for Apple keyboards. I don't know if the latest 13.x version of Karabiner Elements still works, since I'm still on Mojave. In the end, I have it working as I'd like, but it would be nice if it could be done more simply, and the standard OS controls functioned as expected.

@ElhemEnohpi commented on GitHub (Jul 1, 2021): I just started using MonitorControl, and find it very helpful, thanks. I also experienced problems with keyboard shortcuts though, using a MacBook with a non-Apple USB keyboard and external display. It seems to me that MonitorControl doesn't interact correctly with System Preferences > Keyboard > Shortcuts. I'm not able to remap F14/F15 for other purposes, because MonitorControl takes over the keys. If I map other keys to brightness, they don't work as expected with MonitorControl. I'm using Mojave with "Displays have separate Spaces". I've found a work-around using Karabiner Elements, see below. @JoniVR wrote: > I provided a parameter in MediaKeyTap to ignore those keys ... I was planning on adding this as an option in preferences. Why would this need to be a MonitorControl preferences option, rather than just following the OS settings? It seems like the solution, if possible, is not just ignoring F14/F15, but listening for "brightness" keys as set in System Preferences, which it doesn't currently do. In other words, if the computer has System Preferences > Keyboard > Shortcuts > Display set to use F14/F15 for brightness then use them, if something else (or nothing), then use that instead. I think this wouldn't break existing behaviour for users; on my system anyway, F14/F15 were set by default to be brightness. I have a USB keyboard made for Windows, and I tried setting F1/F2 to adjust brightness in System Preferences, rather than F14/F15 (aka Scroll Lock / Pause on my keyboard). But it doesn't work as expected. With MonitorControl running, if I have the lid of my MacBook open, I expected F1/F2 on the USB keyboard to work the same as the brightness keys on the built-in keyboard, adjusting the brightness of the active display. Instead, they always adjust the internal display, rather than the external monitor, even when the external monitor is active. If the lid is closed, F1/F2 do nothing. F14/F15 still adjust the active display, which I would not expect since I've unset them in System Preferences. I'm not able to assign them to another function in System Preferences. On the other hand, if I map F1/F2 to brightness using BetterTouchTool, then unlike with System Preferences, they do work as expected, adjusting the active screen. However, mapping F14/F15 to another purpose with BetterTouchTool is still not possible, as MonitorControl also overrides it, forcing them to be brightness. I found that Karabiner Elements 12 allows me to re-map "Scroll Lock" and "Pause" (as opposed to F14/F15), which stops MonitorControl's takeover of those keys. For example, I can change them to F16/F17 (not present on my keyboard), then adjust my BetterTouchTool settings to use those instead of F14/F15. Probably you can also assign these to something in System Preferences, but I haven't tested it. You can also use Karabiner directly to run a shell script etc., and like BTT, mapping F1/F2 to brightness does work as expected with MonitorControl, adjusting the active display. I don't know if there's a similar work-around in Karabiner for Apple keyboards. I don't know if the latest 13.x version of Karabiner Elements still works, since I'm still on Mojave. In the end, I have it working as I'd like, but it would be nice if it could be done more simply, and the standard OS controls functioned as expected.

gitea-mirror commented

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

Author

Owner

@waydabber commented on GitHub (Aug 20, 2021):

I think there should be an option to customize keyboard shortcuts. I am trying to focus and consolidate all issues like this into #118. I'll close this one as a duplicate now. Thank you!

@waydabber commented on GitHub (Aug 20, 2021): I think there should be an option to customize keyboard shortcuts. I am trying to focus and consolidate all issues like this into #118. I'll close this one as a duplicate now. Thank you!

gitea-mirror commented

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

Author

Owner

@anonymousaga commented on GitHub (Oct 6, 2021):

Thanks so much for the update that fixes it!

@anonymousaga commented on GitHub (Oct 6, 2021): Thanks so much for the update that fixes it!

gitea-mirror referenced this issue

2026-05-05 07:02:33 -06:00

[PR #73] [MERGED] Add more logging information. #1027

Rows
Columns

[GH-ISSUE #100] Fix F14/F15 keys for native Apple Keyboards (They should not change brightness) #73