Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I strongly suspect that this is not the full picture.

I had this exact same issue, two displays, always connected to the same TB3 Dock, and they would randomly get re-assigned after wake-up. Which in my case was doubly irritating, since one of those is in portrait mode, so "fixing it" required tilting my head to be able to navigate the mouse correctly.

There's a small CLI utility called `displayplacer`[1], that basically fixed this for me. I don't... really know what exact EDID fields or whatever metadata it's reading, but after I used it once to "save" the correct orientation/placement, I could reset it to the "correct" one every time after that. Highly recommended if that's something you're struggling with.

[1]: https://github.com/jakehilborn/displayplacer



Looks like displayplacer uses the standard `CGDisplayCreateUUIDFromDisplayID` which the system also uses internally: https://github.com/jakehilborn/displayplacer/blob/master/dis...

This should be prone to the same issue.

Your problem might actually be caused by a timing bug, where the EDID is not fully available in the first few milliseconds of the reconnection, and the system doesn't reconcile after it becomes available.

displayplacer will get the full picture because it's always run a long time after the connection has stabilized.

I can't be certain, but I noticed some slow monitors/hubs do have that timing issue by observing the zero/null values for UUID in The Monitor Database: https://db.lunar.fyi


It’s crazy how many aspects of the electronics in monitors are seemingly phoned in, even on models exceeding $1000 in price. Problems like non-unique IDs and EDID not being available right away are such trivial issues to solve and probably wouldn’t even cost that much in the long run and yet here we are.

I wish a company like Framework or system76 would get into monitors and open source their monitors’ electronics and firmware so at the very least, these issues could be fixed by the community.


Another bit that is phoned in is macOS handling of the displays, which makes certain things like KVM switches problematic...


It also seems like it's getting worse? Apple's new high-end screens are a travesty, and $1000 Samsungs are no better.


Huh, thanks for elaborating!

I'm surprised that the OS doesn't have a safeguards for this and isn't retrying the read the EDID after it sees a "blank" one after wake-up, but the display controllers in Mx chips are stupid complicated already it seems.


I’m sure there must be a retry with a backoff somewhere. But most of the times I noticed that the EDID is incomplete, not blank.

I don’t think there’s any way for the OS to know that there’s a more complete EDID if it tries again later.

That’s also my theory on why the Intel/AMD/NVidia GPUs feel more stable than the Apple Silicon ones: they had years of dealing with these edge cases and probably adding all the workarounds they could think of, while Apple is still catching up.


I had a TB3 dock with dual displays that was causing my 2019 16" MBP to KP sometimes*. I replaced that with individual separate DP adapters. Then I realized, if I always connect the screens in the same order with a few seconds' delay in between, I get the correct screen arrangement, I think. Not 100% sure because sometimes I forgot the ordering, haha.

* Which btw is the kind of rabbit hole that belongs in this article. That was a high-end CalDigit dock, so seeing KPs was surprising. These monitors even had USB-C inputs, but connecting both at once wouldn't work with this MBP model in particular due to a known incompatibility with its dedicated GPU. Older, newer, or lower-end MBPs were fine. Hence the dock adapting to DP. Another funny quirk is I was able to connect my Mac twice to the same screen (via USB-C and DP), and it thought they were separate screens.


I get kernel panics with my CalDigit dock too! Only since the most recent OS update though. Your post is inspiring me to unplug one monitor when I’m not using it and see if it helps. Thanks for the unintended suggestion!


You're welcome. This inspired me to write an HN post, "Treating USB-C as technical debt rather than a feature."




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: