I’ve an LG DualUp (28MQ780-B) show which I exploit with a MacBook Professional 14″ (M2 Professional) over direct USB-C connection. Since updating to macOS Sequoia, the show now not prompts, although it’ll sometimes “thrash” between a single-display format and the prolonged show format, or whether it is saved plugged in for an prolonged time frame, the system (show controller?) will ultimately “partially” activate the prolonged desktop on a brief foundation. When this happens, the prolonged desktop is seen in show settings and distant desktop, (and home windows will be moved to it) however the bodily show remains to be in sleep mode. If I contact the bodily show’s buttons to wake it throughout this state, the show disappears from the system instantly.
I imagine this to be a bug in macOS Sequoia since this replace (from 14.present to fifteen.0.1) is the one variable between this a part of my setup working or not. AppleCare is coming round, although not with out first attempting to persuade me that USB-C or DisplayPort aren’t really “backwards suitable” in the way in which that everyone knows they’re meant to be. Anyway, my query is what are the almost certainly root causes given an evaluation of the next proof:
- The DualUp is an atypical show format; principally two 1440p shows stacked on high of each other (introduced as one 2560×2880 show).
- Utilizing a CalDigit TS4 dock to supply my Mac with a full-size DisplayPort port, I can efficiently drive both this DualUp show or a widescreen LG show of a special mannequin (the alternate mannequin doesn’t have a USB-C interface).
- The DualUp on Sequoia doesn’t operate over USB-C (DisplayPort over USB-C?), although it’s acknowledged by the system as a USB gadget and offers USB-PD to the MacBook.
- Troubleshooting steps taken to isolate the difficulty: powering the MBP through direct energy adapter, restarting, switching person accounts to a regular take a look at person, eradicating the CalDigit TS4 dock when testing the DualUp over USB-C, swapping the USB-C cable I often use with the DualUp ($70 CableMatters 3m USB4) for the OEM included USB-C cable. Not examined (but): protected boot, different host machines
- When plugging within the DualUp through USB-C, I observe exercise in Console.app from the WindowServer course of together with the message
Didn't plug show— pattern included right 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 Show 3 set energy state 1
default 00:09:20.736635-0400 WindowServer kern_CopyProperty key : VirtualDisplayMode not discovered
default 00:09:20.736694-0400 WindowServer Show 3 uuid set
default 00:09:20.736731-0400 WindowServer kern_CopyProperty key : DisplayContainerID not discovered
default 00:09:20.738495-0400 WindowServer Show 3 hotplug-state 1 updating digital modes: coloration 0x600001e0c9c0; timing 0x600001f5a1f0
default 00:09:20.738531-0400 WindowServer Show 3 34 timing modes, 18 coloration modes
default 00:09:20.738934-0400 WindowServer Show 3 present mode (0 x 0) [0 0], most well-liked mode (0 x 0) [0 0]
default 00:09:20.738990-0400 WindowServer [ Display:Hotplug ] Inserting hotplug occasion for state "in", show id: 3
default 00:09:20.739046-0400 WindowServer [ Display:Hotplug ] Processing hotplug "in" for show 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 ] Show 3 didn't 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 Show 3 set energy state 0
default 00:09:20.747524-0400 WindowServer kern_CopyProperty key : Time not discovered
default 00:09:20.747982-0400 WindowServer IOMFBDisplay::set_enabled_ display_id=3, current_state=off
error 00:09:20.748058-0400 WindowServer Didn't plug show 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 retailer.
default 00:09:20.751282-0400 WindowServer [ Display:Config ] Desired config set is legitimate.
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, everlasting retailer.
error 00:09:20.753386-0400 WindowServer Supply was stale as a result of shmem was null: CFPrefsPlistSource<0x600002286760> (Area: com.apple.windowserver.shows, Person: kCFPreferencesAnyUser, ByHost: Sure, Container: (null), Contents Want Refresh: Sure)
default 00:09:20.755749-0400 WindowServer Show 3 sizzling plug 0
default 00:09:20.755830-0400 WindowServer kern_CopyProperty key : DisplayAttributes not discovered
default 00:09:20.755857-0400 WindowServer kern_CopyProperty key : Transport not discovered
default 00:09:20.755888-0400 WindowServer kern_CopyProperty key : VirtualDisplayMode not discovered
default 00:09:20.755902-0400 WindowServer Show 3 uuid cleared
default 00:09:20.755932-0400 WindowServer kern_CopyProperty key : IOMFBUUID not discovered
default 00:09:20.755951-0400 WindowServer kern_CopyProperty key : DisplayContainerID not discovered
default 00:09:20.756124-0400 WindowServer Show 3 hotplug-state 0 updating digital modes: coloration 0x0; timing 0x0
default 00:09:20.756149-0400 WindowServer Show 3 present mode (0 x 0) [0 0], most well-liked mode (0 x 0) [0 0]
default 00:09:20.756166-0400 WindowServer [ Display:Hotplug ] Inserting hotplug occasion for state "out", show 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> (Area: com.apple.windowserver.shows, Person: kCFPreferencesAnyUser, ByHost: Sure, Container: (null), Contents Want Refresh: Sure): 0 -> 548
default 00:09:20.757889-0400 WindowServer [ Display:HDR ] Not populating capabilities for exterior show 3 set to sdr mode and brightness slider assist is enabled.
default 00:09:20.757982-0400 WindowServer [ Display:Hotplug ] Processing hotplug "out" for show 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 retailer.
default 00:09:20.759052-0400 WindowServer [ Display:Config ] Desired config set is legitimate.
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, everlasting retailer.
error 00:09:20.760174-0400 WindowServer Supply was stale as a result of shmem was null: CFPrefsPlistSource<0x600002286760> (Area: com.apple.windowserver.shows, Person: kCFPreferencesAnyUser, ByHost: Sure, Container: (null), Contents Want Refresh: Sure)
error 00:09:20.763209-0400 WindowServer Not updating lastKnownShmemState in CFPrefsPlistSource<0x600002286760> (Area: com.apple.windowserver.shows, Person: kCFPreferencesAnyUser, ByHost: Sure, Container: (null), Contents Want Refresh: Sure): 0 -> 552
default 00:09:22.773394-0400 WindowServer [0x13605e3a0] activating connection: mach=true listener=false peer=false title=com.apple.storagekitd.dm
default 00:09:22.790874-0400 WindowServer [0x13605e3a0] invalidated as a result of the present course of cancelled the connection by calling xpc_connection_cancel()
My understanding of the interaction between Thunderbolt, USB-C, and DisplayPort is that it’s complicated to say the least. My greatest interpretation of the proof is that we observe the TS4 dock doing a great job of demuxing a show sign to its DisplayPort port, and this makes for a a lot less complicated connection to no matter show it’s plugged in to. In distinction, when the DualUp is related to the Mac through USB-C (instantly or through a USB-C port on the TS4) the connection is doing double- or triple-duty as USB (for the DualUp’s inside audio system and hub), USB-PD, and DisplayPort over USB-C. The macOS show controller tries besides the show, and infrequently partially does so, however finally fails to coerce the bodily show into activating.
The conclusion I draw from that is that there are two doable root causes:
- Much less possible: the LG DualUp’s USB-C implementation has a latent bug that was not evident below macOS 14, however is now inflicting an incompatibility with macOS 15.
- Extra possible: macOS 15.0.1 has a software program bug that’s stopping the show controller from correctly activating the DualUp over USB-C below these particular {hardware} circumstances.
