mirror of
https://github.com/MonitorControl/MonitorControl.git
synced 2026-05-15 06:05:52 -06:00
[GH-ISSUE #777] Brightness Control lock-out on MacBook screen wake #499
Labels
No labels
Status: Abandoned
arm64
beta
beta
bug
done
duplicate
enhancement
feedback needed from reporter
in progress
invalid
investigating
known Issue
monitor Issue
pull-request
translation
unable to reproduce
unreleased
x86
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/MonitorControl#499
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Muirium on GitHub (Nov 9, 2021).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/777
Originally assigned to: @waydabber on GitHub.
About half the time I wake my M1 MacBook Air running Monterey 12.0.1, using it in laptop mode with no other displays connected, when I press the brightness keys, I see this:
When I brought this up, I was told the behaviour is intended. But being locked out of your laptop's own brightness keys for a while when you open the lid is not a good experience. It makes MonitorControl a nuisance instead of the must-have utility it is whenever I'm hooked up to a desktop display.
Can we handle this smarter? Automatically dropping the time-out when there is no external display connected seems the right approach to me, certainly on quick-waking M1. I find immediate Brightness control on opening a laptop to be essential.
Originally posted by @Muirium in https://github.com/MonitorControl/MonitorControl/discussions/773#discussioncomment-1609136
@waydabber commented on GitHub (Nov 9, 2021):
We can as well disengage from listening to the brightness keys in this state and let them work as default. This will not show the lock sign however even when a display is connected. We could also shorten the wake-up and configuration delays in general.
@pqhf5kd commented on GitHub (Nov 11, 2021):
I also noticed this issue this morning
@waydabber commented on GitHub (Nov 11, 2021):
All right, I'll tweak this in the next update. :)
@waydabber commented on GitHub (Nov 12, 2021):
Ok, I added this in the 4.0.2 update. I can make an interim build if you'd like to test it or you can wait for 4.0.2. :) Let me know.
@Muirium commented on GitHub (Nov 12, 2021):
Nice! I can test if you like.
@waydabber commented on GitHub (Nov 14, 2021):
Hi, sorry for the delay. The problem is that we have a mess around signatures and I can't sign with the same ID as @JoniVR does who usually manages releases (the app is still notarized though). MacOS might ask you to re-add the app to the accessibility list.
Please test it and let me know if it works.
(link removed)
Thank you!
@JoniVR commented on GitHub (Nov 14, 2021):
Hi, I'll do a 4.0.2 release once the issue is confirmed as resolved 🙂
@Muirium commented on GitHub (Nov 14, 2021):
Testing 4.0.2 just now: nope, still getting the brightness lock on waking up my M1 Air with no external display connected. Works fine from sleep with the 4K plugged in, though (which is a bit slower, naturally). The internal display control time-out does eventually end, but seems similar to before.
And yes, I did quit the previous version of MonitorControl and put it in the trash before installing the new one. Perhaps I need to restart the Mac? I'll try that when I can.
@waydabber commented on GitHub (Nov 14, 2021):
Is the about tab showing 4.0.2?
@Muirium commented on GitHub (Nov 14, 2021):
Yes it is. Build 6957.
Restarted Monterey and the misbehaviour's still there. If I close the lid, wait a bit and open back up again… I get the lock icon when pressing Brightness up or down for several seconds. Eventually, normal control is restored. Can be as little as 2 seconds locked out, but is often up to 5 or 6.
Same applies without TouchID / Apple Watch unlock, if I just select the Sleep command from the Apple menu and then press a key to wake it back up again. (If you sleep a laptop Mac by that method and wake it back up after a second or two, it skips authentication, powering the internal display back up and putting you where you just left off.) Even very short sleeps without authentication trigger the Brightness lock out.
These modern Macs are clearly too fast!
@waydabber commented on GitHub (Nov 15, 2021):
Hmm. Interesting. I'll look at it again then. :)
@waydabber commented on GitHub (Nov 15, 2021):
@Muirium - are you using the Apple keyboard or custom shortcuts?
To be honest, I am yet unable to reproduce the issue with 4.0.2 and I don't clearly see from the code how it is possible. Did you not maybe use MonitorControl with the icon turned off with autostart and the old version is somehow starting up still and takes precedence?
@waydabber commented on GitHub (Nov 15, 2021):
Ok, I updated the build and removed even the function that could possibly display an OSD with a lock. Its just not there anymore, an empty void occupies its place. :) But I still don't understand how could the previous version possibly display an OSD with a lock.
https://www.dropbox.com/s/w6vcr3ui55sbnah/MonitorControl-v4.0.2b6963.zip?dl=1
Thanks a lot for testing!
@Muirium commented on GitHub (Nov 16, 2021):
You're right: the new build (6963) never shows the lock icon. Doing my lid wake / keyboard wake tests, what happens now is a brief pause (where F1 and F2 are just ignored) before brightness control returns. This feels faster! Don't know if it's just a psychological effect, but I much prefer never seeing the lock blocking my way! In my tests just now, the lockout is consistently 5 seconds or less with this build.
As for mysterious causes: I'm a heavy Karabiner user with lots of keyboard customisation in place. That may well be in the mix. Technically, those two brightness keys on my MacBook Air's own keyboard are routed via a virtual keyboard device, as that's how Karabiner works (all connected keyboards are merged into this single device as well). I have F1 and F2 on all keyboards mapped to the keycodes Apple uses for those two keys: "key_code": "display_brightness_decrement" and "key_code": "display_brightness_increment" in Karabiner terminology.
Testing with Karabiner quit: the lock out remains the same. Namely: no lock icon now, but still a brief lockout period on wake. Sound volume keys are not affected, with or without Karabiner. They're always still instantly responsive. (Note: I don't use MonitorControl for audio control. I use my Thunderbolt dock's audio not my Dell display's.)
@waydabber commented on GitHub (Nov 16, 2021):
Ahh, you are using Karabiner then. That messes things up it seems a bit. In reality there should be no wait time over what the OS needs at all if the standard Apple media keys are used. What matters is that its ok then now.
@waydabber commented on GitHub (Nov 16, 2021):
(i closed the issue but let me know if there is any additional issues! :))