MacBook Pro m5 can’t recognize two external monitors with same EDID binary serial (only one works at a time)

App & System Services Hardware

Created 3w

Replies 16

Boosts 0

Participants 3

My MacBook Pro M5 running MacOS Tahoe 26.3 beta fails to detect two identical ASUS ROG Swift OLED PG32UCDM monitors simultaneously. Only one display is recognized at a time.

One potential root cause might be that both monitors report identical binary EDID serial numbers (0x01010101), and the MacBook Pro M5 appears to use this value exclusively for display identity rather than combining it with other more detailed information (e.g., port, or alphanumeric serial number).

I've verified that the monitor EDID binary serial numbers are in fact identical -- however the alphanumerical serial numbers are not identical.

NOTE: This behavior is specific to the MacBook Pro M5 — when connecting both monitors via usb-c to a Mac Mini M4 Pro running the same MacOS Tahoe 26.3 beta, the monitors work fine. The OS detects both and assigns different names to them (PG32UCDM (1) and PG32UCDM (2)).

NOTE: I could be wrong about this root cause, I don't have a way to disprove it, though the fact the monitors work fine on a Mac Mini is suspicious.

What I have tried:

Connecting the two monitors using different monitor ports (one on DisplayPort, another on HDMI, etc.), and different MacBook ports (one on HDMI, another on USB-C, etc.)
Bumping down the resolution on the monitors to "1920x1080 (low resolution)" and 30Hz to rule out bandwidth issues.
Connecting one, or both, monitors to CalDigit TS5 Plus dock. Neither alternate configuration yields the device recognizing both screens.
Using BetterDisplay to import a manually-edited EDID for the screen, with a different binary EDID value, manufacturer name, etc.

I've also verified that if I plug in my Apple Studio Display as one of the monitors, then the MacBook recognizes both one of the PG32UCDM monitors and the Studio Display at the same time. The issue seems to occur only when both monitors plugged into it are the same PG32UCDM model.

When I have both monitors plugged into my MacBook, each time I disconnect the cable to whichever monitor is currently recognized, it immediately recognizes the other monitor. Plugging the cable for the disconnected monitor back in has no effect.

I'm at a loss.

Has anyone run into this issue and found a successful workaround that is not one of the approaches I've described above?

Boost

DTS Engineer OP

Apple

I don't think this answer actually holds up. Here is how I understand it:

I plug in a monitor. Its default resolution is 4K at 240Hz. Fine, I shouldn't be able to plug in another monitor.
I change the one monitor to 4K at 120Hz. Now the laptop has one monitor plugged in, running at 4K at 120Hz.
I plug in another monitor. Its default resolution is 4K at 240Hz. I understand this is a problem because it would require "both of the two display 'pipes'" as you described above.

That's close, except the problem here is actually at #2, as changing resolution did NOT release the "pipe". The issue here is that these "pipes" are actually tied to the low-level I/O system, not the monitor itself. Putting that in more concrete terms, driving the monitor at 4K/240Hz requires more video bandwidth than a standard "cable" should provide, so the system plugged in two cables instead. The change at #2 had no effect on that configuration. And, yes, I used refresh rate to describe what was going on above and, no, that wasn't entirely accurate.

Why isn't the MacBook Pro M5 dropping this second monitor to 4K 120Hz?

At a technical level, the problem here is that all of the configuration is currently done in the kernel at connect time. Making this work better requires having a channel to push the required configuration setting into the kernel and nothing like that currently exists.

That leads to here:

But why should this be my problem to deal with as the customer?

and here:

In other words, why do I have to buy third-party hardware (the EDID emulator) to fix this?

My focus here has been on describing what's currently going on, not what "should" be happening. Ironically, I just upgraded to an M4 MAX, which forced me to buy an HDMI CEC filter. My primary display is a 43" 4K TV and the CEC implementation in the MacBook kept forcing interface switches I didn't want to occur. That behavior can't be changed because in software because the kernel driver doesn't provide a way to do so.

Finally, on this point:

But it's disappointing to see this get answered as simply "behaving correctly."

The range of response we can provide through the bug system is somewhat limited, so in this context, "Behaves Correctly" basically means "the system is currently working the way it was designed to work". That's not quite that same as saying it SHOULD work this way. I can't comment on our future plans, but I do want to be clear that the video team is very aware of these issues and does not think the current behavior is actually the "right" solution to these issues.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware