[GH-ISSUE #424] Option to determine if window focus or mouse position determines which display to control

gitea-mirror commented

2026-05-05 05:46:13 -06:00

Owner

Originally created by @HazemAlindari on GitHub (Apr 7, 2021).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/424

Originally assigned to: @waydabber on GitHub.

Checklist

I have searched for existing issues
I have looked through the wiki
I have updated MonitorControl to the latest version

Describe the bug
Changing Volume or Brightness happens on wrong monitor

To Reproduce
Steps to reproduce the behavior:

Have 2 monitors connected, one connected with dvi (main and no audio support) and one connected with hdmi (secondary and audio output)
Have safari playing video on full screen mode on secondary display and try to change volume (and sometimes brightness) with buttons (keyboard shortcuts), the second monitor should have different app on full screen as well (my testing was preview full screen with pdf)
Change volume icon appear on correct display (secondary - hdmi) but effects wrong one (main - dvi)
This behavior can be eliminated by going to desktop on the effected monitor and then changing volume/brightness

Expected behavior
Volume/brightness should change on the focused display (last clicked on) or where the mouse is am not sure!
Volume change should be only for outputs which support volume, or at least you can disable manually in settings!

Additional context
This Behavior is happens most of the time but for unknown reason sometimes it works correctly!

Environment Information (please complete the following information):

macOS version: 10.15.7
MonitorControl version: 2.1.0 (Build 721)
Monitor(s): HP LA2306 (DVI - Main - no speakers) and Samsung S27B550 (Secondary - hdmi - Audio)

Originally created by @HazemAlindari on GitHub (Apr 7, 2021). Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/424 Originally assigned to: @waydabber on GitHub. **Checklist**  - [x] I have searched for existing issues - [x] I have looked through [the wiki](https://github.com/MonitorControl/MonitorControl/wiki) - [x] I have updated MonitorControl to the latest version **Describe the bug** Changing Volume or Brightness happens on wrong monitor **To Reproduce** Steps to reproduce the behavior: 1. Have 2 monitors connected, one connected with dvi (main and no audio support) and one connected with hdmi (secondary and audio output) 2. Have safari playing video on full screen mode on secondary display and try to change volume (and sometimes brightness) with buttons (keyboard shortcuts), the second monitor should have different app on full screen as well (my testing was preview full screen with pdf) 3. Change volume icon appear on correct display (secondary - hdmi) but effects wrong one (main - dvi) 4. This behavior can be eliminated by going to desktop on the effected monitor and then changing volume/brightness **Expected behavior** Volume/brightness should change on the focused display (last clicked on) or where the mouse is am not sure! Volume change should be only for outputs which support volume, or at least you can disable manually in settings! **Additional context** This Behavior is happens most of the time but for unknown reason sometimes it works correctly! **Environment Information (please complete the following information):** - macOS version: 10.15.7 - MonitorControl version: 2.1.0 (Build 721) - Monitor(s): HP LA2306 (DVI - Main - no speakers) and Samsung S27B550 (Secondary - hdmi - Audio)

gitea-mirror

2026-05-05 05:46:13 -06:00

closed this issue
added the
enhancement

done
labels

gitea-mirror commented

2026-05-05 05:46:20 -06:00

Author

Owner

@MikeParkinWits commented on GitHub (Aug 17, 2021):

Just writing to say I have the same problem and as convenient as this app is, this makes it very inconvenient 😪

@MikeParkinWits commented on GitHub (Aug 17, 2021): Just writing to say I have the same problem and as convenient as this app is, this makes it very inconvenient 😪

gitea-mirror commented

2026-05-05 05:46:24 -06:00

Author

Owner

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

The active display is not determined by the mouse location but by which display has the active menu bar. You have to click on a window associated with that display or the dektop or the menubar to switch. Can you please try that? Also you can try one of the new 3.0.0 betas. If the issue is resolved this way, please close this issue. Thank you!

@waydabber commented on GitHub (Aug 19, 2021): The active display is not determined by the mouse location but by which display has the active menu bar. You have to click on a window associated with that display or the dektop or the menubar to switch. Can you please try that? Also you can try one of the new 3.0.0 betas. If the issue is resolved this way, please close this issue. Thank you!

gitea-mirror commented

2026-05-05 05:46:27 -06:00

Author

Owner

@MikeParkinWits commented on GitHub (Aug 19, 2021):

The active display is not determined by the mouse location but by which display has the active menu bar. You have to click on a window associated with that display or the dektop or the menubar to switch. Can you please try that? Also you can try one of the new 3.0.0 betas. If the issue is resolved this way, please close this issue. Thank you!

Unfortunately my issue still persists in newer beta versions... Whenever a window is in fullscreen, and the active window being used (as noted by the menubar being active), using the keyboard brightness controls changes the wrong display. I have just checked and when an application is in full screen, and in use, on my second screen it then changes brightness on my main screen - and vice versa.

@MikeParkinWits commented on GitHub (Aug 19, 2021): > The active display is not determined by the mouse location but by which display has the active menu bar. You have to click on a window associated with that display or the dektop or the menubar to switch. Can you please try that? Also you can try one of the new 3.0.0 betas. If the issue is resolved this way, please close this issue. Thank you! Unfortunately my issue still persists in newer beta versions... Whenever a window is in fullscreen, and the active window being used (as noted by the menubar being active), using the keyboard brightness controls changes the wrong display. I have just checked and when an application is in full screen, and in use, on my second screen it then changes brightness on my main screen - and vice versa.

gitea-mirror commented

2026-05-05 05:46:28 -06:00

Author

Owner

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

Ohh yes, I didn't notice the title is about full screen. :) Yes, the current detection method does not work properly for that (macOS itself gives back the wrong display as active).

For future reference, this seems to be the culprit:

  func getCurrentDisplay() -> Display? {
    guard let mainDisplayID = NSScreen.main?.displayID else {
      return nil
    }
    return self.displays.first { $0.identifier == mainDisplayID }
  }

@waydabber commented on GitHub (Aug 19, 2021): Ohh yes, I didn't notice the title is about full screen. :) Yes, the current detection method does not work properly for that (macOS itself gives back the wrong display as active). For future reference, this seems to be the culprit: ``` func getCurrentDisplay() -> Display? { guard let mainDisplayID = NSScreen.main?.displayID else { return nil } return self.displays.first { $0.identifier == mainDisplayID } } ```

gitea-mirror commented

2026-05-05 05:46:31 -06:00

Author

Owner

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

Hi @MikeParkinWits

I did some changes, now the control will solely be based on where the mouse is (no need to click on the screen or anything). This should also work with full screen apps. This will be in the next 3.x release. Please let me know if it works for you + in this case you can close the issue.

Thanks!

@waydabber commented on GitHub (Aug 19, 2021): Hi @MikeParkinWits I did some changes, now the control will solely be based on where the mouse is (no need to click on the screen or anything). This should also work with full screen apps. This will be in the next 3.x release. Please let me know if it works for you + in this case you can close the issue. Thanks!

gitea-mirror commented

2026-05-05 05:46:32 -06:00

Author

Owner

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

Hi, we have relased the 3.0.0 version. Could you please test if this issue is resolved and report back? Thank you!

@waydabber commented on GitHub (Aug 21, 2021): Hi, we have relased the [3.0.0 version](https://github.com/MonitorControl/MonitorControl/releases/tag/v3.0.0-rc1). Could you please test if this issue is resolved and report back? Thank you!

gitea-mirror commented

2026-05-05 05:46:34 -06:00

Author

Owner

@MikeParkinWits commented on GitHub (Aug 23, 2021):

Hi, we have relased the 3.0.0 version. Could you please test if this issue is resolved and report back? Thank you!

Hi @waydabber

I just tested the new version and it's working perfectly now, thanks! I didn't open the issue, so I can't close it... But I would say it's safe to say that this issue has been resolved!

Thank you so much!

@MikeParkinWits commented on GitHub (Aug 23, 2021): > Hi, we have relased the [3.0.0 version](https://github.com/MonitorControl/MonitorControl/releases/tag/v3.0.0-rc1). Could you please test if this issue is resolved and report back? Thank you! Hi @waydabber I just tested the new version and it's working perfectly now, thanks! I didn't open the issue, so I can't close it... But I would say it's safe to say that this issue has been resolved! Thank you so much!

gitea-mirror commented

2026-05-05 05:46:35 -06:00

Author

Owner

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

Thanks for the response, I'll close the issue then!

@waydabber commented on GitHub (Aug 23, 2021): Thanks for the response, I'll close the issue then!

gitea-mirror commented

2026-05-05 05:46:37 -06:00

Author

Owner

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

I just found out about this issue today, it's still happening, and it wasn't before (don't remember when before, sorry about that).

A simple test, what I have:

MacBook Pro, Intel CPU, 16 inches, MacOs Big Sur latest update, lid closed;
Monitor one: LG HDR 4K Display
Monitor two: DELL S2719DC Display
I'm using a Magic Keyboard and Mouse
Monitor one is the one that holds the menu bar

Steps to reproduce:

Place the mouse/cursor on Monitor one, no need to click anywhere.
Use the keyboard F1/F2 keys to control the brightness, works like a charm for the Monitor one (that's correct).
Cmd+Tab to change focus to an application on Monitor two, for example, reply to a Slack message.
Mouse/cursor continues on Monitor one, I'm using only the keyboard
Use the keyboard F1/F2 to control the brightness, doesn't work for Monitor two, instead, keeps managing Monitor one (that's wrong).
Simply move the mouse/cursor to Monitor two, no need to click anywhere, it works now for Monitor two.

Conclusion: it seems that the app is taking into account the mouse cursor position (monitor) to choose what monitor should be controlled.

@maxacarvalho commented on GitHub (Sep 8, 2021): I just found out about this issue today, it's still happening, and it wasn't before (don't remember **when** before, sorry about that). A simple test, what I have: 1. MacBook Pro, Intel CPU, 16 inches, MacOs Big Sur latest update, **lid closed**; 2. Monitor one: LG HDR 4K Display 3. Monitor two: DELL S2719DC Display 4. I'm using a Magic Keyboard and Mouse 5. Monitor one is the one that holds the menu bar Steps to reproduce: 1. Place the mouse/cursor on **Monitor one**, **no need to click anywhere**. 2. Use the **keyboard F1/F2 keys** to control the brightness, works like a charm for the **Monitor one** (**that's correct**). 3. **Cmd+Tab** to **change focus** to an application on **Monitor two**, for example, reply to a Slack message. 4. **Mouse/cursor continues on Monitor one**, I'm using only the keyboard 5. Use the **keyboard F1/F2** to control the brightness, **doesn't work for Monitor two**, instead, keeps managing Monitor one (**that's wrong**). 6. Simply **move the mouse/cursor** to Monitor two, **no need to click anywhere**, it **works now for Monitor two**. Conclusion: it seems that the app is taking into account the mouse cursor position (monitor) to choose what monitor should be controlled.

gitea-mirror commented

2026-05-05 05:46:38 -06:00

Author

Owner

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

Hi @maxacarvalho, this is intentional, there was a change in 3.0.0 - the app always follows the mouse and does not follow app focus anymore. The old method of control was broken for full screen apps which necessitated the change. I am not aware of a simple solution that is perfect, at least this method is consistently working and easy to understand.

@waydabber commented on GitHub (Sep 8, 2021): Hi @maxacarvalho, this is intentional, there was a [change in 3.0.0](https://github.com/MonitorControl/MonitorControl/issues/424#issuecomment-901837804) - the app always follows the mouse and does not follow app focus anymore. The old method of control was broken for full screen apps which necessitated the change. I am not aware of a simple solution that is perfect, at least this method is consistently working and easy to understand.

gitea-mirror commented

2026-05-05 05:46:41 -06:00

Author

Owner

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

Hi @waydabber

I understand your point and well, that's fine, it's still an amazing project. But I can't deny that this, at least for me, is a GIGANTIC push back, messes with productivity a lot, sometimes I don't even know where my mouse is.

I'm sure you already thought about that but, would be possible to have a config for that?
I understand what you mean about the fullscreen apps but, in my case (and probably many other engineers), fullscreen apps will always receive some input, since those are the terminal, IDE, etc. I believe the issue happens with things like movie apps, etc, where the user simply switches focus and doesn't input anything.

Does that make sense?

@maxacarvalho commented on GitHub (Sep 8, 2021): Hi @waydabber I understand your point and well, that's fine, it's still an amazing project. But I can't deny that this, at least for me, is a **GIGANTIC** push back, messes with productivity a lot, sometimes I don't even know where my mouse is. I'm sure you already thought about that but, would be possible to have a config for that? I understand what you mean about the fullscreen apps but, in my case (and probably many other engineers), fullscreen apps will always receive some input, since those are the terminal, IDE, etc. I believe the issue happens with things like movie apps, etc, where the user simply switches focus and doesn't input anything. Does that make sense?

gitea-mirror commented

2026-05-05 05:46:42 -06:00

Author

Owner

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

Hi @maxacarvalho

Just chiming in here to back @waydabber up and clarify some things. I see and understand your point, but the fact of the matter was that the old method was broken and inconsistent as a result. When an app was in fullscreen and you were using that app on monitor one, then monitor two would change brightness - and vice versa if an app was being used in fullscreen on monitor two. So while this method would work if you never used fullscreen apps, it instantly became pointless with fullscreen apps (which I find myself using a lot when coding, specifically for split screen etc...).

I will agree with waydabber here and note that neither solution is perfect, but I believe that this is the more optimal solution as it is consistent, and as I'm sure you are familiar with being a developer that you would rather have something less ideal but consistent over inconsistent and buggy. Thus, and I am sorry to say, but I believe that you calling this a gigantic step back is a bit short sighted in this instance.

However, I do hear your need for this and potentially a toggled will be added for future. Otherwise, have you considered using an older version of the app? I know that the beta version, and all versions prior to the release candidate, used the other method.

Keep well!

@MikeParkinWits commented on GitHub (Sep 8, 2021): Hi @maxacarvalho Just chiming in here to back @waydabber up and clarify some things. I see and understand your point, but the fact of the matter was that the old method was broken and inconsistent as a result. When an app was in fullscreen and you were using that app on monitor one, then monitor two would change brightness - and vice versa if an app was being used in fullscreen on monitor two. So while this method would work if you never used fullscreen apps, it instantly became pointless with fullscreen apps (which I find myself using a lot when coding, specifically for split screen etc...). I will agree with waydabber here and note that neither solution is perfect, but I believe that this is the more optimal solution as it is consistent, and as I'm sure you are familiar with being a developer that you would rather have something less ideal but consistent over inconsistent and buggy. Thus, and I am sorry to say, but I believe that you calling this a gigantic step back is a bit short sighted in this instance. However, I do hear your need for this and potentially a toggled will be added for future. Otherwise, have you considered using an older version of the app? I know that the beta version, and all versions prior to the release candidate, used the other method. Keep well!

gitea-mirror commented

2026-05-05 05:46:43 -06:00

Author

Owner

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

Hi @MikeParkinWits

Thanks for your explanations, it all makes sense.

In fairness, I do use fullscreen apps, and I had never experienced the issue you mentioned, the brightness would always change correctly for the display I was on.

A quick note about myself calling it "gigantic push back", I'm talking about my own daily flow, not yours, not all the users. And as I also mentioned, sometimes I don't even know where my mouse is, so it is gigantic for me, I wish it wasn't.

I will think about your suggestion and use a previous version of the app, although not ideal, I update my apps using homebrew and, to add an exception there is not so smooth.

I'll keep an eye open for the new releases and, possibly, a toggle for this.

Once again, thank you very much for your contribution, this app is a life-saver, and although annoying, this thing with the cursor is probably something I'll be able to live with.

@maxacarvalho commented on GitHub (Sep 8, 2021): Hi @MikeParkinWits Thanks for your explanations, it all makes sense. In fairness, I do use fullscreen apps, and I had never experienced the issue you mentioned, the brightness would always change correctly for the display I was on. A quick note about myself calling it "gigantic push back", I'm talking about my own daily flow, not yours, not all the users. And as I also mentioned, sometimes I don't even know where my mouse is, so it is gigantic for me, I wish it wasn't. I will think about your suggestion and use a previous version of the app, although not ideal, I update my apps using homebrew and, to add an exception there is not so smooth. I'll keep an eye open for the new releases and, possibly, a toggle for this. Once again, thank you very much for your contribution, this app is a life-saver, and although annoying, this thing with the cursor is probably something I'll be able to live with.

gitea-mirror commented

2026-05-05 05:46:46 -06:00

Author

Owner

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

Unfortunatelly it happened with any full screen app (so if you set XCode to full screen it didn't work for some reason). But sure, there can be a configuration option to change the method. I recommend you open a new Feature Request for this and I'll add it. Also maybe we can find a workaround for the full screen issue as well. We wouldn't want a "gigantic push back", right? :)

@waydabber commented on GitHub (Sep 9, 2021): Unfortunatelly it happened with any full screen app (so if you set XCode to full screen it didn't work for some reason). But sure, there can be a configuration option to change the method. I recommend you open a new Feature Request for this and I'll add it. Also maybe we can find a workaround for the full screen issue as well. We wouldn't want a "gigantic push back", right? :)

gitea-mirror commented

2026-05-05 05:46:47 -06:00

Author

Owner

@maxacarvalho commented on GitHub (Sep 9, 2021):

Hi @waydabber, @MikeParkinWits

I see that my use of the term "gigantic push back" caused some sort of discomfort, I'm really sorry about that. But it makes me upset to see that you are kind of diminishing the way the feature impacts my workflow. I would think that nowadays people would be more respectful towards other's feelings and particularities.

Since the beginning of my report, I have made it clear that I appreciate the work being done with this project, that's open-source and very high quality.
I believe I was also respectful and stated more than once that I do understand the reasons why the new feature was set and simply suggested that a flag to turn the previous behavior on was added. Even still, I didn't say at any point that the flag "should" be added, I never even complained about the new way the app works. And still, I see this sarcasm around your comments.

Once again, thank you for your contributions, the app is paramount and works perfectly, I can adapt to the new behavior, and if it makes you more comfortable, I refrain from my previous statement and say that this is a bit of a pushback, but I can easily live with it.

@maxacarvalho commented on GitHub (Sep 9, 2021): Hi @waydabber, @MikeParkinWits I see that my use of the term "gigantic push back" caused some sort of discomfort, I'm really sorry about that. But it makes me upset to see that you are kind of diminishing the way the feature impacts my workflow. I would think that nowadays people would be more respectful towards other's feelings and particularities. Since the beginning of my report, I have made it clear that I appreciate the work being done with this project, that's open-source and very high quality. I believe I was also respectful and stated more than once that I do understand the reasons why the new feature was set and simply suggested that a flag to turn the previous behavior on was added. Even still, I didn't say at any point that the flag "should" be added, I never even complained about the new way the app works. And still, I see this sarcasm around your comments. Once again, thank you for your contributions, the app is paramount and works perfectly, I can adapt to the new behavior, and if it makes you more comfortable, I refrain from my previous statement and say that this is a bit of a pushback, but I can easily live with it.

gitea-mirror commented

2026-05-05 05:46:49 -06:00

Author

Owner

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

Hey @maxacarvalho no hard feelings, I wrote what I did in a totally relaxed way - but it did not go through it seems, sorry for that. :)

@waydabber commented on GitHub (Sep 9, 2021): Hey @maxacarvalho no hard feelings, I wrote what I did in a totally relaxed way - but it did not go through it seems, sorry for that. :)

gitea-mirror commented

2026-05-05 05:46:51 -06:00

Author

Owner

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

I added this as an option in 3.1.0.

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

Gigantic push back averted! ;)

@waydabber commented on GitHub (Sep 9, 2021): I added this as an option in 3.1.0. See screenshots of the implementation in the [v3.1.0 preliminary discussion](https://github.com/MonitorControl/MonitorControl/discussions/596). Gigantic push back averted! ;)

Rows
Columns

[GH-ISSUE #424] Option to determine if window focus or mouse position determines which display to control #338