[GH-ISSUE #1233] External monitor connected to closed M1 MacBook Air (Ventura) goes dark on brightness adjustment. Appears to be conflict with `AmbientDisplayAgent`. #715

New issue

Closed

opened 2026-05-05 06:34:43 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 06:34:43 -06:00

Owner

Originally created by @randallzug on GitHub (Nov 20, 2022).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/1233

Before opening the issue, have you...?

Searched for existing issues
Looked through the wiki
Updated MonitorControl to the latest version (if applicable)

Describe the bug

This problem is intermittent. About once a week after waking the computer from sleep, adjusting the brightness using MonitorControl causes the monitor to lose the graphics signal from the computer. It seems like the backlight is controllable while the monitor is "darK", but no graphics are displayed.

Unplugging the monitor and plugging it back in, then re-waking the Mac does restore the graphics signal. However using MonitorControl to attempt to adjust the brightness does continue to cause the graphics signal to completely drop out. In this state it is only possible to adjust the external monitor brightness using physical buttons on the monitor itself.

On the other hand, if I force quit com.apple.AmbientDisplayAgent in Activity Monitor, which really just restarts this agent, MonitorControl functionality is completely restored. This fix persists across sleep/awake cycles and restarting, but the problem will randomly reappear a few days later.

I have tried opening and closing the lid, running with and without monitor, but none of this replicates the buggy state. In the console, a possibly relevant error:

error   10:24:07.778050-0800    com.apple.AmbientDisplayAgent   [ERROR] - Unable to create and     lookup port "com.apple.CoreDisplay.master" => 1102   
    0          0x1941661e8  CoreDisplay::Mach::Port::Port(std::__1::basic_string<char,     std::__1::char_traits<char>, std::__1::allocator<char> >,     CoreDisplay::Mach::Port::PortLookup) + 392
    1          0x19412529c  CoreDisplay_IsCustomWhitePointSet + 100
    2          0x1a9993e90  getCustomWhitePointXYZ + 244
    3          0x1a9994380  modifyAndSetIntentionForWhitePoint + 68
    4          0x1a9994564  modifyAndSetIntentionForWhitePointOnEveryDevice + 172
    5          0x1001d80a0  main + 5256
    6          0x19230fe4c  _xpc_connection_call_event_handler + 152
    7          0x19230e84c  _xpc_connection_mach_event + 1380
    8          0x19241b5c4  _dispatch_client_callout4 + 20
    9          0x192437fe8  _dispatch_mach_msg_invoke + 468
    10         0x192422a94  _dispatch_lane_serial_drain + 376
    11         0x192438d04  _dispatch_mach_invoke + 448
    12         0x19242e34c  _dispatch_workloop_worker_thread + 652
    13         0x19259e100  _pthread_wqthread + 288
    14         0x19259ce20  start_wqthread + 8

However, when I have recorded this error, MonitorControl still works fine.

I will update if I find out how to reliably replicate, or with additional console messages the next time the buggy state resumes. In the meantime, force-quitting AmbientDisplayAgent may be a helpful workaround for any other users who experience this problem.

Steps to reproduce

During buggy state (unable to reproduce buggy state)

Press brightness up/down key, or attempt to adjust from menubar
Monitor loses graphics connection
Unplug/plug
Wake computer from sleep
goto step 1

Workaround:

Force quit com.apple.AmbientDisplayAgent
Adjust monitor brightness
Everything works like normal

Expected behavior

see above

Anything else?

No response

Environment Information (please complete the following information)

- macOS version: Ventura 13.0.1
- Mac model: MacBookAir10,1 (M1, 2020)
- MonitorControl version: 4.1.0
- Monitor(s): BenQ PD3200U
- Apple Silicon/M1 (yes or no): yes
- Connection: USB3 to HDMI 2.0 adapter
- Configuration: MacBook lid almost always closed with the monitor connected

Originally created by @randallzug on GitHub (Nov 20, 2022). Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/1233 ### Before opening the issue, have you...? - [X] Searched for existing issues - [X] Looked through [the wiki](https://github.com/MonitorControl/MonitorControl/wiki) - [X] Updated MonitorControl to the latest version (if applicable) ### Describe the bug This problem is intermittent. About once a week after waking the computer from sleep, adjusting the brightness using MonitorControl causes the monitor to lose the graphics signal from the computer. It seems like the backlight is controllable while the monitor is "darK", but no graphics are displayed. Unplugging the monitor and plugging it back in, then re-waking the Mac does restore the graphics signal. However using MonitorControl to attempt to adjust the brightness does continue to cause the graphics signal to completely drop out. In this state it is only possible to adjust the external monitor brightness using physical buttons on the monitor itself. On the other hand, if I force quit `com.apple.AmbientDisplayAgent` in Activity Monitor, which really just restarts this agent, MonitorControl functionality is completely restored. This fix persists across sleep/awake cycles and restarting, but the problem will randomly reappear a few days later. I have tried opening and closing the lid, running with and without monitor, but none of this replicates the buggy state. In the console, a possibly relevant error: error 10:24:07.778050-0800 com.apple.AmbientDisplayAgent [ERROR] - Unable to create and lookup port "com.apple.CoreDisplay.master" => 1102 0 0x1941661e8 CoreDisplay::Mach::Port::Port(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, CoreDisplay::Mach::Port::PortLookup) + 392 1 0x19412529c CoreDisplay_IsCustomWhitePointSet + 100 2 0x1a9993e90 getCustomWhitePointXYZ + 244 3 0x1a9994380 modifyAndSetIntentionForWhitePoint + 68 4 0x1a9994564 modifyAndSetIntentionForWhitePointOnEveryDevice + 172 5 0x1001d80a0 main + 5256 6 0x19230fe4c _xpc_connection_call_event_handler + 152 7 0x19230e84c _xpc_connection_mach_event + 1380 8 0x19241b5c4 _dispatch_client_callout4 + 20 9 0x192437fe8 _dispatch_mach_msg_invoke + 468 10 0x192422a94 _dispatch_lane_serial_drain + 376 11 0x192438d04 _dispatch_mach_invoke + 448 12 0x19242e34c _dispatch_workloop_worker_thread + 652 13 0x19259e100 _pthread_wqthread + 288 14 0x19259ce20 start_wqthread + 8 However, when I have recorded this error, MonitorControl still works fine. I will update if I find out how to reliably replicate, or with additional console messages the next time the buggy state resumes. In the meantime, force-quitting AmbientDisplayAgent may be a helpful workaround for any other users who experience this problem. ### Steps to reproduce During buggy state (unable to reproduce buggy state) 1. Press brightness up/down key, or attempt to adjust from menubar 2. Monitor loses graphics connection 3. Unplug/plug 4. Wake computer from sleep 5. goto step 1 Workaround: 1. Force quit `com.apple.AmbientDisplayAgent` 2. Adjust monitor brightness 3. Everything works like normal ### Expected behavior see above ### Anything else? _No response_ ### Environment Information (please complete the following information) ```markdown - macOS version: Ventura 13.0.1 - Mac model: MacBookAir10,1 (M1, 2020) - MonitorControl version: 4.1.0 - Monitor(s): BenQ PD3200U - Apple Silicon/M1 (yes or no): yes - Connection: USB3 to HDMI 2.0 adapter - Configuration: MacBook lid almost always closed with the monitor connected ```

gitea-mirror closed this issue

2026-05-05 06:34:44 -06:00

gitea-mirror commented

2026-05-05 06:34:48 -06:00

Author

Owner

@randallzug commented on GitHub (Jan 4, 2023):

I have never been able to reliably reproduce this issue, even though the behavior occurred frequently a few months ago. Whatever was causing it may have been a bug in Apple's AmbientDisplayAgent that has been corrected in recent updates to MacOS.

@randallzug commented on GitHub (Jan 4, 2023): I have never been able to reliably reproduce this issue, even though the behavior occurred frequently a few months ago. Whatever was causing it may have been a bug in Apple's AmbientDisplayAgent that has been corrected in recent updates to MacOS.

gitea-mirror commented

2026-05-05 06:34:49 -06:00

Author

Owner

@MICHELLGRONER88 commented on GitHub (Jan 5, 2023):

@MICHELLGRONER88 commented on GitHub (Jan 5, 2023): ****

gitea-mirror commented

2026-05-05 06:34:51 -06:00

Author

Owner

@waydabber commented on GitHub (Jan 20, 2023):

Since this seems to be fixed by itself, I'll close this one. :)