Samsung Odyssey G9 suddenly not detected with DP 1.4

[sebb3]

Samsung Odyssey G95C (49") — DP 1.4 fails on Apple Silicon (M5), DP 1.1 works

Environment

• MacBook Pro with Apple M5, macOS Tahoe 26.3.1 (25D2128)
• Samsung Odyssey G95C (LS49CG954E), firmware M-C9549GGPA-1003.0
• USB-C to DisplayPort 1.4 cable (Cable Matters, Realtek RTL5452)
• CalDigit Element Hub (firmware 45.1) — issue also reproduces with direct connection

Problem

DP 1.4 stopped working after a routine reboot. DP 1.1 works fine (3840x1080@60Hz). At DP 1.4, the display is not detected at all — the cable shows as a Billboard USB device and macOS never initializes the display.

This was working immediately before the reboot. No macOS update was installed before the issue started (26.3.1 was installed the day after).

What we've tried (all failed)

• Brand new USB-C to DP 1.4 cable (same Billboard behavior)
• All 3 USB-C ports on the Mac (different Thunderbolt buses)
• Direct connection bypassing the CalDigit hub
• Safe Mode boot
• Full shutdown (30+ second power drain)
• Monitor factory reset
• Monitor firmware update (1000.2 → 1003.0)
• macOS display preferences cache deletion (com.apple.windowserver.displays plist)
• Disabling Adaptive Sync / FreeSync on the monitor
• Lid-close sleep/wake cycle
• CGBeginDisplayConfiguration/CGCompleteDisplayConfiguration to force re-probe
• Attempted kext unload/reload of AppleDPTX (refused — in use)

Root cause analysis via IORegistry

At DP 1.1 (working):
The DPTX controller powers up, reads DPCD (HBR3 capable, 2 lanes), reads EDID successfully, and the display initializes at 3840x1080.

At DP 1.4 (failing):
The DPTX controller EventLog shows this sequence:

1. Set Power → On ✓
2. Hot Plug detected (HPDState=1) ✓
3. Add Child → IODPDevice(dptx0-aux-core) ✓
4. Remove Child → IODPDevice(dptx0-aux-core) ✗ (immediately removed)
5. Set Power → Off

The AUX log reveals the full I2C transaction sequence during the failed DP 1.4 attempt:

• DPCD read at addr 0x0: 12 14 c4 81 01 00 01 00 02 00 06 00 00 00 85 00 → DP 1.4, HBR3, 4 lanes ✓
• EDID block 0 read from I2C addr 0x50 (80): success ✓
• EDID block 1 (CEA-861) read from I2C addr 0x50: success ✓
• EDID block 2 (DisplayID, tag 0x70) read from I2C addr 0x50 via segment pointer (addr 0x30=0x01): success ✓
• I2C writes to addr 0x52 (82): NACK (error 0x004011e0), repeated 12+ times ✗
• macOS then tears down the display

The monitor is NACKing all DDC/CI requests at I2C addr 0x52 when in DP 1.4 mode. macOS treats this as fatal and removes the display. At DP 1.1, macOS never attempts addr 0x52 reads, so it works.

After the initial failure, subsequent connection attempts often don't even trigger DP Alt Mode — the Thunderbolt controller firmware stops granting it, and the cable only appears as a Billboard device with no DPTX EventLog activity at all.

DP 1.4 EDID (from AUX log)

Block 0 (base):

00ffffffffffff004c2daf743746533033210104b57722783a1245ac5248a727
10505425cf00714f810081c08180a9c0b3009500d1c074d600a0f03840403020
3a00a9504100001a000000fd083cf01e66c2000a202020202020000000fc004f
64797373657920473935430a000000ff00484e54574330303536370a202002a9

Block 1 (CEA-861):

020322f04410043f032309070783010000e305c000e60605018b7302e5018b84
90791a6800a0f0381f4030203a00a9504100001a565e00a0a0a0295030203500
a9504100001a6fc200a0a0a0555030203500a9504100001a2dd6807870382940
1c203a00a9504100001a00000000000000000000000000000000000000000027

Block 2 (DisplayID):

70127903000301649cf50288ff133f017f801f009f052e0002000900b9710108
ff139f002f801f009f053500020009003b70008ff139f002f801f009f052800
020009007c910128ff093f017f801f009f052e00020009000daf0108ff0e1701
6b801f00370423000200090000000000000000000000000000000000ee90

DP 1.1 EDID (exported via BetterDisplay)

00ffffffffffff004c2db0743746533033210104b57722783a1245ac5248a727
10505425cf00714f810081c08180a9c0b3009500d1c01a6800a0f0381f403020
3a00a9504100001a000000fd001e781e8720000a202020202020000000fc004f
64797373657920473935430a000000ff00484e54574330303536370a202001b1
020311f1449004033f2309070783010000565e00a0a0a0295030203500a95041
00001a773300a0f038134030203a00a9504100001a023a801871382d40582c45
00a9504100001e000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000008d

Questions

1. Is there any way to suppress or override the I2C addr 0x52 (DDC/CI) probe that macOS performs during DP 1.4 display initialization?
2. Could a BetterDisplay EDID override help if the display never fully connects? (The Mac reads the EDID successfully but fails at the DDC/CI step afterward)
3. Is there a known workaround for Apple Silicon's DPTX controller refusing to re-attempt Alt Mode after initial failures (requiring reboot)?
4. Any other diagnostic steps we might have missed?

[waydabber]

Hmm. Standard EDID/DDC traffic is 0x50 for EDID, 0x30 for the segment pointer, and DDC/CI is associated with 0x37 / 0x6E-0x6F, not 0x52. So this looks like a link training, Alt Mode, cable-converter or monitor issue. The fact that the cable is showing up as a Billboard device (which advertises things like Alt Mode capability) when it fails is a clear indication: https://www.reddit.com/r/UsbCHardware/comments/smi06q/just_got_a_new_monitor_what_is_billboard_device/

Did you try these to isolate the issue?

• Try a different cable (different vendor if possible)
• Another Mac or PC with the same cable
• A different monitor with the same cable and Mac

BetterDisplay can only help with an EDID override once macOS has a usable display object to work with, which is not the case here. The link/handshake problem is not something BetterDisplay can meaningfully interfere with. :(