What happens
I am having a hard time getting my MacBook Pro M2 Pro (running Omarchy) to connect to an external monitor. I have an INNOCN external monitor and I am trying to connect via HDMI (USB-C is not supported on this setup at the moment). Every time I connect via HDMI the MacBook just freezes up. When I disconnect it, it goes back to normal.
While debugging I found the key clue: when I was plugged into a different second monitor, the MacBook worked fine and that monitor showed signal output. I tried to plug back into the INNOCN and it did not work again (the MacBook froze). So I think the source is the INNOCN specifically.
I also tried forcing the INNOCN to 1920x1080@60 (the exact mode the working monitor uses) and it froze again.
Reproduction
- MacBook Pro 16" M2 Pro (j416s) on linux-asahi 7.1.13.asahi3.
- Connect the INNOCN (EDID model 49C1G, a 49" 3840x1080 ultrawide) to the built-in HDMI port.
- The desktop freezes within a few seconds; unplugging the cable recovers it every time. No kernel panic.
- A Dell E2318HX (1080p) on the same cable and port works normally.
- Forcing the INNOCN to 1920x1080@60 also freezes, so it is not resolution/pixel-clock dependent.
System
- Machine: Apple MacBook Pro (16-inch, M2 Pro, 2023) — apple,j416s / apple,t6020
- Kernel: linux-asahi 7.1.13.asahi3-1 (uname 7.1.13-3-1-ARCH, aarch64)
- Distro: Arch Linux ARM (Omarchy 4.0.3); mesa 26.1.8
- Compositor: Hyprland 0.56.2 (aquamarine)
- External display path: dcp@289c00000 (dcpext), connector HDMI-A-1, via a Parade PS190 DP-to-HDMI bridge (
[AFK]matched PS190: OUI 00.10.FA, DeviceID pHDMIg)
Monitors tested
- Fails: INNOCN 49" ultrawide, EDID model
49C1G, native 3840x1080@60.
- Works on the same port and cable: Dell E2318HX (1920x1080@60).
dmesg during the freeze (INNOCN forced to 1920x1080@60)
apple-dcp 289c00000.dcp: set_digital_out_mode(color:68 timing:45) "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x0
apple-dcp 289c00000.dcp: set_digital_out_mode() color mode depth:8 format:0 colorimetry:16 eotf:0 range:0 vrr:0
apple-dcp 289c00000.dcp: RTKit: syslog message: nifiedPipeline.cpp:7356: IOMFBStatus UnifiedPipeline::mode_set_gated(uint32_t, uint32_t): 1920x1080@60 Hz link: 1
apple-dcp 289c00000.dcp: set_digital_out_mode finished:8272
apple-dcp 289c00000.dcp: RTKit: syslog message: FramebufferDCP.cpp: IOMFB: swap_submit_dcp: swallowed swap ID 523 as fControllerPowerState is 0 for External Display
apple-dcp 289c00000.dcp: DPTXPort: acking unhandled call 20
apple-dcp 289c00000.dcp: RTKit: syslog message: FramebufferDCP.cpp: IOMFB: swap_submit_dcp: swallowed swap ID 524 as fControllerPowerState is 0 for External Display
apple-drm soc:display-subsystem: [drm] *ERROR* flip_done timed out
apple-drm soc:display-subsystem: [drm] *ERROR* [CRTC:68:crtc-1] commit wait timed out
apple-dcp 289c00000.dcp: DPTXPort: acking unhandled call 20
With the Dell on the same port and cable, the 1920x1080@60 modeset completes and keeps running: no "swallowed swap", no "fControllerPowerState is 0", and no flip_done timeout. I can attach a full dmesg and the INNOCN's EDID if useful.
What happens
I am having a hard time getting my MacBook Pro M2 Pro (running Omarchy) to connect to an external monitor. I have an INNOCN external monitor and I am trying to connect via HDMI (USB-C is not supported on this setup at the moment). Every time I connect via HDMI the MacBook just freezes up. When I disconnect it, it goes back to normal.
While debugging I found the key clue: when I was plugged into a different second monitor, the MacBook worked fine and that monitor showed signal output. I tried to plug back into the INNOCN and it did not work again (the MacBook froze). So I think the source is the INNOCN specifically.
I also tried forcing the INNOCN to 1920x1080@60 (the exact mode the working monitor uses) and it froze again.
Reproduction
System
[AFK]matched PS190: OUI 00.10.FA, DeviceID pHDMIg)Monitors tested
49C1G, native 3840x1080@60.dmesg during the freeze (INNOCN forced to 1920x1080@60)
With the Dell on the same port and cable, the 1920x1080@60 modeset completes and keeps running: no "swallowed swap", no "fControllerPowerState is 0", and no flip_done timeout. I can attach a full dmesg and the INNOCN's EDID if useful.