I’ve an LG DualUp (28MQ780-B) show which I take advantage of with a MacBook Professional 14″ (M2 Professional) over direct USB-C connection. Since updating to macOS Sequoia, the show now not prompts, although it’s going to sometimes “thrash” between a single-display format and the prolonged show format, or whether it is saved plugged in for an prolonged time period, the system (show controller?) will finally “partially” activate the prolonged desktop on a short lived foundation. When this happens, the prolonged desktop is seen in show settings and distant desktop, (and home windows might 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 consider 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 making an attempt to persuade me that USB-C or DisplayPort aren’t truly “backwards appropriate” in the best way that everyone knows they’re meant to be. Anyway, my query is what are the most probably root causes given an evaluation of the next proof:
- The DualUp is an atypical show format; mainly two 1440p shows stacked on high of each other (offered as one 2560×2880 show).
- Utilizing a CalDigit TS4 dock to offer my Mac with a full-size DisplayPort port, I can efficiently drive both this DualUp show or a widescreen LG show of a distinct mannequin (the alternate mannequin doesn’t have a USB-C interface).
- The DualUp on Sequoia doesn’t perform over USB-C (DisplayPort over USB-C?), although it’s acknowledged by the system as a USB gadget and gives USB-PD to the MacBook.
- Troubleshooting steps taken to isolate the problem: powering the MBP by way of direct energy adapter, restarting, switching consumer accounts to an ordinary check consumer, eradicating the CalDigit TS4 dock when testing the DualUp over USB-C, swapping the USB-C cable I normally use with the DualUp ($70 CableMatters 3m USB4) for the OEM included USB-C cable. Not examined (but): secure boot, different host machines
- When plugging within the DualUp by way of 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: shade 0x600001e0c9c0; timing 0x600001f5a1f0
default 00:09:20.738531-0400 WindowServer Show 3 34 timing modes, 18 shade 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: shade 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 help 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 advanced to say the least. My greatest interpretation of the proof is that we observe the TS4 dock doing an excellent job of demuxing a show sign to its DisplayPort port, and this makes for a a lot easier connection to no matter show it’s plugged in to. In distinction, when the DualUp is related to the Mac by way of USB-C (immediately or by way of a USB-C port on the TS4) the connection is doing double- or triple-duty as USB (for the DualUp’s inner 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 attainable root causes:
- Much less seemingly: the LG DualUp’s USB-C implementation has a latent bug that was not evident underneath macOS 14, however is now inflicting an incompatibility with macOS 15.
- Extra seemingly: macOS 15.0.1 has a software program bug that’s stopping the show controller from correctly activating the DualUp over USB-C underneath these particular {hardware} circumstances.
