4 ms·
It is up to the OS, you understood correctly. But the EDID spec tells that you can only rely on the standard EDID fields to be present. Someone implementing the
by alin23 4y ago
It is up to the OS, you understood correctly. But the EDID spec tells that you can only rely on the standard EDID fields to be present. Someone implementing the spec would be right to do what Apple engineers did in their UUID logic.
All the rest are workarounds that they need to add on a case by case basis when new data appears like 10% of the monitors since 2017 only have an alphanumeric serial number or like some very popular Dell models need a 1.5 second warmup time before reading the EDID to get a complete structure.
You might say, why don’t they just stick every available data in the UUID and call it a day?. The issue is that outside the standard EDID fields, you have no guarantee that the extension data will be persistent. If even a byte of that data changes when adjusting monitor settings, or when reconnecting the monitor, then you’ll break the persistent storage even more for setups where it worked before.
I’m trying to say that it’s not Apple’s fault here. If monitor vendors would follow the incredibly simple standard for those fields, we wouldn’t have any “bug” to talk about right now.
But of course, people will only care if their setup works or not, assigning blame to the right party doesn’t change a thing. So Apple must now try to fix those edge cases, because monitors won’t go back and reflash correct EDIDs in their EEPROMs.
- gernb 4y agosounds like I need a tool to flash my EEPROMs. Just change one bit.
- alin23 4y agoThere are free tools that can do that on Windows and Linux. For example on Windows you can dump and write EDID using https://www.monitortests.com/forum/Thread-EDID-DisplayID-Writer https://www.monitortests.com/forum/Thread-EDID-DisplayID-Wri... And you can edit it using https://ez.analog.com/video/w/documents/750/advantiv-edid-editor https://ez.analog.com/video/w/documents/750/advantiv-edid-ed... Simply incrementing the serial number or the week of manufacture bit will be enough. But you also have to be lucky to have a monitor that hasn’t already locked the write pin of the EEPROM. On macOS it’s a lot harder to write the EDID, especially on Apple Silicon. I’m not sure why, but the WriteI2C method doesn’t always work so you might end up breaking the monitor with an incomplete write.
- gernb 4y agoI'm going to suggest again that Apple still has stuff to do here. For example, on another setup I have 2 very different monitors, 38 inch wide 3840x1600 LG and a BenQ 32" 3840x2160. They don't have the swap problem but MacOS just screwed up and even though I have the BenQ set to Scaled at 2560x1440, MacOS just put it at 3840x2160, and, when I went to go fix it, System Prefs showed it set to 2560x1440. To fix it I had to pick another resolution and then set it back. There's clearly work to be done on Apple's part here. Another common problem I have is switching from no external monitor to external monitors. Usually the process is I'm on my laptop on battery. Close the lid. Come home. With lid closed plug in monitors one via USB-C, the other via a Thunderbolt dock, tap an external keyboard to wake it up. Quite often (once a week?), MacOS never switches on. Often I open the laptop and MacOS flickers all 3 monitors and never recovers (have given it several minutes). Unplug the monitors and there's an 80% change the laptop monitor will come on. Re-plugin the external monitors, wait for them to come on, then close the laptop. The other 20% of the time the Mac never comes on and I have to hold the power button to hard rebooth. This happens on both a 2019 Intel/AMD MBP and an M1 Max MBP. This situation also happens with the 2 identical monitors but the swap probably happens multiple times a day where as the "it can't get itself started" problem happens once a week.
- alin23 4y agomacOS definitely has its own bugs, I’m not siding with Apple because I like them or anything like that. I waste countless hours each week just responding to emails and explaining to people how what’s happening with their colors and brightness is caused by buggy Gamma implementation in a macOS framework, or how BlackOut (https://lunar.fyi/#blackout https://lunar.fyi/#blackout) is so unstable sometimes because of unreliable mirroring APIs, and of course I bump into the resolution and wake/reconnection problems you mentioned as well. Especially on Apple Silicon where the Display Coprocessor is still in its infancy, they still have a lot of work to do.