Hacker News Reader

Comment by mort96 | Hacker News Reader

The first issue, where multiple monitors have the same vendor/model/manufacture date/serial number, couldn't that be solved by also storing which port it's connected to? That way, if you have two HDMI ports, if both monitors have the same UUID, you store settings based on port rather than UUID. I don't know if this is possible with this new USB-C world, but at least with traditional hardware, it seems like the OS knows which port a monitor is connected to.

Anyways, interesting post. It's always fun to discover how much hardware is just broken and doesn't actually correctly implement the protocols or features it's supposed to implement.

View on HN

If it detects a UUID collision, it should automatically drive to the manufacturer, kick in the door and keep punching faces until they start assigning proper serial numbers.

There’s no such thing as manufacturers assigning colliding UUIDs.

If that happens, then they’re just assigning “ID”s.

> If that happens, then they’re just assigning “ID”s.

Or "serial numbers," as it were.

The concoction of UUIDs that are neither universal nor unique happens in software, but the cause is the serial numbers colliding.

> Or "serial numbers," as it were.

Or in this case, a constant number…

I’ve seen similar problems with inexpensive Chinese wifi modules all shipping with an identical MAC address. Mostly you can Google up the method required to reflash them (or worst case, I’ve been out a dollar or two because it usually the ultra cheap things this happens on).

The manufacturer isn't assigning UUIDs, we're talking about what macOS considers a display UUID. MacOS will generate a UUID based on the manufacturer, the model, the manufacturing date and the serial number, and the intent is truly that these UUIDs uniquely identify the display. It just doesn't work when multiple monitors have the same serial number, which isn't supposed to happen.

It does in a roundabout way:

Annoy a thousand developers / power users.

Leading to:

Util developer gets 100 emails.

Leading to:

HN post gets 100k views.

Leading to:

One of the readers proverbially punch some faces.

See: good design!

PitFAAS. It's the hot new tech of 2023.

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.

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

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

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."

FTA: In standby, the monitor is actually disconnected and disappears from the I/O Registry

I think the common case of “multiple HDMI ports” is one where users plug in USB-C dongles to magically create them.

In that case, do the HDMI ports disappear from the registry, too, so that you can’t identify ports across standby?

Even distinguishing a built-in HDMI port from one in a USB-C dongle may be difficult if the built-in one secretly is connected over USB-C.

The USB is a bus. All controllers and devices connected to it have a unique port assignment as well.

My question is whether that assignment survives standby of the PC. Reading https://unix.stackexchange.com/questions/336037/mapping-of-u..., I’m not sure it does.

Certainly, a bus scan has to happen to detect whether devices (including USB hubs) got unplugged or plugged in during standby, so if that scanning isn’t guaranteed to always produce the same result (e.g. because of jitter in the timing when various devices come online), I doubt that’s guaranteed to produce 100% identical information.

It’s a question, though. I don’t know enough of how this work to definitely answer that.

That answer is talking about the kernel assigned device names, not the port identifiers which should be stable across reboots.

Back when I had two monitors, I got the same cables for both and I indiscriminately plugged them into my computer (I had a laptop, so plugging/unplugging happened ~daily). So the mapping between computer port and monitor definitely wasn't going to stay the same.

Yeah, it would be a workaround for some cases but not all. It would work in the case of a desktop system where the monitors are always plugged in, and it would work for the case where the monitors go through some kind of USB-C dock (assuming it's possible), but not in your case.

Not as convenient but you could label them, if the port was actually factored in.

You wouldn't use the "which port was it in last" fallback option unless you already had multiple saved entries where every other bit of data matched.

This should be at least theoretically possible -- in Windows, for instance, device file paths are based on connection topology, including port address.

I'm guessing this is caused by the monitors waking up in different orders. The computer tries to set em up as soon as possible even if they're in different ports. It would be nice if it detects when the collision happens and then put them in another list for monitors associated with their port. Or just have an option.

That's what I thought. I found some of these devices myself over the years and usually, they had serial numbers of 0 or 1. Could even Special-Case these and proactively include the port, in case the user indeed has another one and just has is unplugged currently.

Reply on news.ycombinator.com