For me it got so bad, I just stopped using my two external monitors, I don't even bother anymore.
1000% It's frustrating to not know whether I should expect that it be fixed on my up-to-date Ventura installation. It's definitely not, it happened yesterday. Maybe that was just a fluke?It would be nice if Apple provided some release notes of what they fix, and bug reference numbers...
Ok, I'm game to try again! I'm on 13.5 and just switched my cables. I'll let you know if it fails or works for me in the next few days.My original fix post was 4/13/23
Still fixed - no issues since that day. Fixed in Ventura 13.3.1 (22E261)
My monitors, if I haven't made it clear already P) exhibit the same symptoms you just described on latest Ventura and experienced a flip yesterday. Can't remember whether there was one today or not.Ok, I'm game to try again! I'm on 13.5 and just switched my cables. I'll let you know if it fails or works for me in the next few days.
Added - I can tell you already that when I use SwitchResX to read the EDID of my 2 monitors with both connected to their HDMI inputs it reads EXACTLY the same EDID, with exactly the same ASCII serial numbers, for both monitors. When I switch one monitor to use its DVI input, SwitchResX reads the correct unique serial numbers for both monitors. So this is not looking like a fix, but I will use it for a few days and see if the monitors get swapped on a boot up.
Would it be possible for them to fix it in such a way that it resolves the native macOS display arrangement screwing up, but does nothing to improve performance of SwitchResX?So this is not looking like a fix
Alternatively, run this in a terminal window and post the output:I would love for somebody that previously had the issue who now thinks it's fixed to download Displayplacer, run a "displayplacer list" command, and post the output. @EssentialGadget?
ioreg -lw0 | grep -i "DisplayAttributes"
system_profiler -json SPDisplaysDataType
The problem still exists between the 2 HP monitors unless one is run in DVI input mode.
Lol I'd love to see somebody try the conversion method to ultimately end at the same place but with, presumably, the required EDID blocks stripped.My displays don't have DVI ports either. But since converting to DVI promises a definitive solution, do you think it will be idiotic (or possible) to convert the signal from HDMI to DVI and back using two converters? Does DVI even support a 4K+ signal?
Hope this helps.Alternatively, run this in a terminal window and post the output:
Bash:ioreg -lw0 | grep -i "DisplayAttributes"
Also it'd be nice to see a system_profiler output next to the other outputs as well:
Bash:system_profiler -json SPDisplaysDataType
@lasyos - Lol you're gonna love what I'm about to try. I assume this will fail spectacularly.
View attachment 2241578
Aaaand cancelled. I was under the impression that jamming the signal through a DVI port would strip it of some info. I misunderstood.Those conversion cables just change signal (wire) to pin assignments, they will do nothing to change the EDID. DVI carries all the same HDMI signals except CEC and HEC, which have nothing to do with this issue.
ioreg
still sees the data and has both SerialNumber
and AlphanumericSerialNumber
. Of which SerialNumber
is identical for all three of your monitors with AlphanumericSerialNumber
being unique for each.system_profiler
sees _spdisplays_display-serial-number
the same for all three of your monitors: 1010101
.ioreg
data makes sense. It contains both fields with no interpretation. But the system_profiler
serial-number-equivalent field is all confused about what the actual serial numbers are just like on my system.AlphanumericSerialNumber
out and utilizing it. Maybe my swap was just a fluke the other day? But I've been on new Ventura for a while and have experienced the issue multiple times per day over the last several weeks.system_profiler sees _spdisplays_display-serial-number the same for all three of your monitors 01010101
I looked through the release notes for SwitchResX from 4.12->4.13.1 and there are references to things in there that could be relevant but aren't definitively so.Here's some news.
I used SwitchResX version 4.12.0 (Apple Silicon) (I've used that version for some time) with Ventura 13.5 - it read both HDMI connected monitors with the exact same EDID. i.e. both with the SAME ASCII serial number
I just uploaded SwitchResX 4.13.1 (Apple Silicon), the latest version, with the same Ventura 13.5 - It read the 2 HDMI connected montors each with their CORRECT, UNIQUE ASCII serial numbers. (As a check, I then switched back to version 4.12.0 and got the incorrect results again.)
I also tried ioreg -lw0 | grep -i "DisplayAttributes" and it read the 2 HDMI connected monitors with their CORRECT, UNIQUE ASCII serial numbers.
Conclusion - One of two things has happened. Either
1) SwitchResX has had a bug for MANY years (dating back to older non-Apple Silicon versions) and reported the EDID wrong, and the bug was fixed so it now reads the monitor serial numbers correctly
OR
2) Apple has supplied a new API to read the ASCII serial number and SwitchResX is using it in version 4.13.1
Unfotunately I have no recollection of previous results using ioreg -lw0 | grep -i "DisplayAttributes" to know if those results have changed with Ventura (which would mean Apple fixed it). I'll try to see if I documented that anywhere.
As of today, with only 4-5 reboots I have not seen the displays switch (now connected with HDMI inputs on both monitors).
CGDisplaySerialNumber
function. I have seen no other "gimme the display serial number" function mentioned when researching this, and I'd expect @alinpanaitiu to know those APIs better than any of us. Is it possible SwitchResX goes after the "actual" serial number directly via ioreg
?Reading a DVI port gets a different EDID because the DVI EDID does not have the same extensions as HDMI ports. But using conversion cables do nothing but move the same signal lines to different pins on the different connector.Aaaand cancelled. I was under the impression that jamming the signal through a DVI port would strip it of some info. I misunderstood.
I looked through the release notes for SwitchResX from 4.12->4.13.1 and there are references to things in there that could be relevant but aren't definitively so.
As @alinpanaitiu pointed out, it's certainly not something they did in theCGDisplaySerialNumber
function. I have seen no other "gimme the display serial number" function mentioned when researching this, and I'd expect @alinpanaitiu to know those APIs better than any of us. Is it possible SwitchResX goes after the "actual" serial number directly viaioreg
?
Yeah... they're definitely still swapping. Just did it.All this aside... if I don't have an unexplained swap happen to me in the next few days/weeks, I'm prepared to call it fixed without being able to explain why I have been having to fix it nearly every day for the past few months.
And they have flipped twice since.Yeah... they're definitely still swapping. Just did it.
I don't know about daisy chaining, but I can report that my 3 monitors (2 identical HP) have not flipped since I changed back to all HDMI connections (2 with TB to HDMI converters) last Thursday. This was absolutely NOT working with the Monterey Mac OS when I got my Mac Studio Ultra March 2022.And they have flipped twice since.
Would somebody that knows better than me be able to say whether it is likely that me having my monitors connected in a daisy chain fashion via the Thunderbolt 3 ports would make any difference? I could get a longer TB cable and make sure they have their own dedicated port on the computer, but I fail to see how that would matter.
@mattlorimor thanks for the reply, your eagerness to try my stupid experiment, and sorry for the late reply. I had to step out for a bit 😅@lasyos - Lol you're gonna love what I'm about to try. I assume this will fail spectacularly.
View attachment 2241578