I have an LG DualUp (28MQ780-B) display which I use with a MacBook Pro 14″ (M2 Pro) over direct USB-C connection. Since updating to macOS Sequoia, the display no longer activates, though it will occasionally “thrash” between a single-display layout and the extended display layout, or if it is kept plugged in for an extended period of time, the system (display controller?) will eventually “partially” activate the extended desktop on a temporary basis. When this occurs, the extended desktop is visible in display settings and remote desktop, (and windows can be moved to it) but the physical display is still in sleep mode. If I touch the physical display’s buttons to wake it during this state, the display disappears from the system immediately.
I believe this to be a bug in macOS Sequoia since this update (from 14.current to 15.0.1) is the only variable between this part of my setup working or not. AppleCare is coming around, though not without first trying to convince me that USB-C or DisplayPort aren’t actually “backwards compatible” in the way that we all know they are meant to be. Anyway, my question is what are the most likely root causes given an assessment of the following evidence:
- The DualUp is an atypical display format; basically two 1440p displays stacked on top of one another (presented as one 2560×2880 display).
- Using a CalDigit TS4 dock to provide my Mac with a full-size DisplayPort port, I can successfully drive either this DualUp display or a widescreen LG display of a different model (the alternate model does not have a USB-C interface).
- The DualUp on Sequoia does not function over USB-C (DisplayPort over USB-C?), though it is recognized by the system as a USB device and provides USB-PD to the MacBook.
- Troubleshooting steps taken to isolate the issue: powering the MBP via direct power adapter, restarting, switching user accounts to a standard test user, removing the CalDigit TS4 dock when testing the DualUp over USB-C, swapping the USB-C cable I usually use with the DualUp ($70 CableMatters 3m USB4) for the OEM included USB-C cable. Not tested (yet): safe boot, other host machines
- When plugging in the DualUp via USB-C, I observe activity in Console.app from the WindowServer process including the message
Failed to plug display— sample included here:
default 00:09:20.735805-0400 WindowServer IOMFBDisplay::update_power_state display_id=3 current_power_state=0 target_power_state=0 new_target_power_state=1 sync=0 raw_power_state=1 power_assertions=0
default 00:09:20.735837-0400 WindowServer Display 3 set power state 1
default 00:09:20.736635-0400 WindowServer kern_CopyProperty key : VirtualDisplayMode not found
default 00:09:20.736694-0400 WindowServer Display 3 uuid set
default 00:09:20.736731-0400 WindowServer kern_CopyProperty key : DisplayContainerID not found
default 00:09:20.738495-0400 WindowServer Display 3 hotplug-state 1 updating digital modes: color 0x600001e0c9c0; timing 0x600001f5a1f0
default 00:09:20.738531-0400 WindowServer Display 3 34 timing modes, 18 color modes
default 00:09:20.738934-0400 WindowServer Display 3 current mode (0 x 0) [0 0], preferred mode (0 x 0) [0 0]
default 00:09:20.738990-0400 WindowServer [ Display:Hotplug ] Inserting hotplug event for state "in", display id: 3
default 00:09:20.739046-0400 WindowServer [ Display:Hotplug ] Processing hotplug "in" for display id: 3 (CA)
default 00:09:20.739145-0400 WindowServer IOMFBDisplay::set_enabled=1
default 00:09:20.739265-0400 WindowServer IOMFBDisplay::update_power_state display_id=3 current_power_state=0 target_power_state=1 new_target_power_state=1 sync=0 raw_power_state=1 power_assertions=0
default 00:09:20.739290-0400 WindowServer IOMFBDisplay::set_enabled_ display_id=3, current_state=on
default 00:09:20.739414-0400 WindowServer [ Display:Config ] Display 3 failed to return any CA modes
default 00:09:20.739460-0400 WindowServer IOMFBDisplay::set_enabled=0
default 00:09:20.747443-0400 WindowServer IOMFBDisplay::update_power_state display_id=3 current_power_state=0 target_power_state=1 new_target_power_state=0 sync=0 raw_power_state=0 power_assertions=0
default 00:09:20.747484-0400 WindowServer Display 3 set power state 0
default 00:09:20.747524-0400 WindowServer kern_CopyProperty key : Time not found
default 00:09:20.747982-0400 WindowServer IOMFBDisplay::set_enabled_ display_id=3, current_state=off
error 00:09:20.748058-0400 WindowServer Failed to plug display 3
default 00:09:20.748459-0400 WindowServer [ Display:Power ] Work (D/C/W/S/P/R): 0/0/0/0/0/0
default 00:09:20.751070-0400 WindowServer [ Display:Config ] Detected match in persistent store.
default 00:09:20.751282-0400 WindowServer [ Display:Config ] Desired config set is valid.
default 00:09:20.751475-0400 WindowServer [ Display:Config ] No change between prior and requested configuration.
default 00:09:20.752139-0400 WindowServer [ Display:Persist ] Saving configuration: session, permanent store.
error 00:09:20.753386-0400 WindowServer Source was stale because shmem was null: CFPrefsPlistSource<0x600002286760> (Domain: com.apple.windowserver.displays, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes)
default 00:09:20.755749-0400 WindowServer Display 3 hot plug 0
default 00:09:20.755830-0400 WindowServer kern_CopyProperty key : DisplayAttributes not found
default 00:09:20.755857-0400 WindowServer kern_CopyProperty key : Transport not found
default 00:09:20.755888-0400 WindowServer kern_CopyProperty key : VirtualDisplayMode not found
default 00:09:20.755902-0400 WindowServer Display 3 uuid cleared
default 00:09:20.755932-0400 WindowServer kern_CopyProperty key : IOMFBUUID not found
default 00:09:20.755951-0400 WindowServer kern_CopyProperty key : DisplayContainerID not found
default 00:09:20.756124-0400 WindowServer Display 3 hotplug-state 0 updating digital modes: color 0x0; timing 0x0
default 00:09:20.756149-0400 WindowServer Display 3 current mode (0 x 0) [0 0], preferred mode (0 x 0) [0 0]
default 00:09:20.756166-0400 WindowServer [ Display:Hotplug ] Inserting hotplug event for state "out", display id: 3
default 00:09:20.756194-0400 WindowServer IOMFBDisplay::update_power_state display_id=3 current_power_state=0 target_power_state=0 new_target_power_state=0 sync=0 raw_power_state=0 power_assertions=0
error 00:09:20.757697-0400 WindowServer Not updating lastKnownShmemState in CFPrefsPlistSource<0x600002286760> (Domain: com.apple.windowserver.displays, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): 0 -> 548
default 00:09:20.757889-0400 WindowServer [ Display:HDR ] Not populating capabilities for external display 3 set to sdr mode and brightness slider support is enabled.
default 00:09:20.757982-0400 WindowServer [ Display:Hotplug ] Processing hotplug "out" for display id: 3 (CA)
default 00:09:20.758143-0400 WindowServer [ Display:Power ] Work (D/C/W/S/P/R): 0/0/0/0/0/0
default 00:09:20.758953-0400 WindowServer [ Display:Config ] Detected match in persistent store.
default 00:09:20.759052-0400 WindowServer [ Display:Config ] Desired config set is valid.
default 00:09:20.759128-0400 WindowServer [ Display:Config ] No change between prior and requested configuration.
default 00:09:20.759499-0400 WindowServer [ Display:Persist ] Saving configuration: session, permanent store.
error 00:09:20.760174-0400 WindowServer Source was stale because shmem was null: CFPrefsPlistSource<0x600002286760> (Domain: com.apple.windowserver.displays, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes)
error 00:09:20.763209-0400 WindowServer Not updating lastKnownShmemState in CFPrefsPlistSource<0x600002286760> (Domain: com.apple.windowserver.displays, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): 0 -> 552
default 00:09:22.773394-0400 WindowServer [0x13605e3a0] activating connection: mach=true listener=false peer=false name=com.apple.storagekitd.dm
default 00:09:22.790874-0400 WindowServer [0x13605e3a0] invalidated because the current process cancelled the connection by calling xpc_connection_cancel()
My understanding of the interplay between Thunderbolt, USB-C, and DisplayPort is that it is complex to say the least. My best interpretation of the evidence is that we observe the TS4 dock doing a good job of demuxing a display signal to its DisplayPort port, and this makes for a much simpler connection to whatever display it is plugged in to. In contrast, when the DualUp is connected to the Mac via USB-C (directly or via a USB-C port on the TS4) the connection is doing double- or triple-duty as USB (for the DualUp’s internal speakers and hub), USB-PD, and DisplayPort over USB-C. The macOS display controller tries to boot the display, and occasionally partially does so, but ultimately fails to coerce the physical display into activating.
The conclusion I draw from this is that there are two possible root causes:
- Less likely: the LG DualUp’s USB-C implementation has a latent bug that was not evident under macOS 14, but is now causing an incompatibility with macOS 15.
- More likely: macOS 15.0.1 has a software bug that is preventing the display controller from properly activating the DualUp over USB-C under these specific hardware conditions.