3 ms·

On Apple Silicon Macs you can see the computed EDID UUID through the I/O registry: ioreg -r -c AppleCLCD2 | egrep 'ProductAttributes|EDID UUID' I couldn’t

by alin23 4y ago

On Apple Silicon Macs you can see the computed EDID UUID through the I/O registry: ioreg -r -c AppleCLCD2 | egrep 'ProductAttributes|EDID UUID' I couldn’t see the EDID UUID on Intel Macs, but you could at least dump the EDID on those and see if the bytes are identical. The Lunar CLI (https://lunar.fyi/#cli https://lunar.fyi/#cli) has a way of dumping that: lunar displays --edid If you’re using Linux, you can take a look at ddcutil for dumping the EDID, and on Windows you have NirSoft’s DumpEDID.

gernb 4y ago
Interestingly ioreg reports the same UUID for both monitors but Apple Menu->About Mac->System Report->Graphics/Displays on Intel Mac shows different serial numbers (not UUID) for both monitors. So,.... this sounmds like a bug in MacOS, not the monitors. Whatever they are using for UUID they should be taking into account the serial numbers reported by System Report. Strange though, the M1 Mac shows no serial numbers. Both Macs have the swap problem. Maybe you should add an update to your article. This is clearly an Apple bug, not a monitor manufacture bug. At least in my case. -- update --- Here is the output from ioreg on an M1 Max Mac ioreg -r -c AppleCLCD2 | egrep 'ProductAttributes|EDID UUID' | "DisplayAttributes" = {"SupportsSuspend"=No,"MaximumRefreshRate"=60,"SupportsActiveOff"=No,"PortID"=16,"ProductAttributes"={"ManufacturerID"="HPN","YearOfManufacture"=2021,"SerialNumber"=0,"ProductName"="HP E27u G4","AlphanumericSerialNumber"="CN41201PZ4","LegacyManufacturerID"=8718,"ProductID"=14060,"WeekOfManufacture"=20},"MaxVerticalImageSize"=34,"MaxHorizontalImageSize"=60,"HasHDMILegacyEDID"=No,"Chromaticity"={"Red"={"X"=42816,"Y"=21824},"Green"={"X"=19200,"Y"=41216},"Blue"={"X"=9728,"Y"=4160}},"DefaultColorSpaceIsSRGB"=No,"NativeFormatHorizontalPixels"=2560,"DefaultWhitePoint"={"X"=20544,"Y"=21568,"Gamma"=144179},"SupportsVariableRefreshRate"=No,"AspectRatio"=15,"MinimumRefreshRate"=50,"WhitePoints"=({"X"=20544,"Y"=21568,"Gamma"=144179}),"PreciseAspectRatio"=115652,"ContinuousFrequencySupport"="None","SupportsStandby"=Yes,"NativeFormatVerticalPixels"=1440} | "EDID UUID" = "220EEC36-0000-0000-141F-0104A53C2278" | "DisplayAttributes" = {"SupportsSuspend"=No,"MaximumRefreshRate"=60,"SupportsActiveOff"=No,"PortID"=0,"ProductAttributes"={"ManufacturerID"="HPN","YearOfManufacture"=2021,"SerialNumber"=0,"ProductName"="HP E27u G4","AlphanumericSerialNumber"="CN41201PZN","LegacyManufacturerID"=8718,"ProductID"=14060,"WeekOfManufacture"=20},"MaxVerticalImageSize"=34,"MaxHorizontalImageSize"=60,"HasHDMILegacyEDID"=No,"Chromaticity"={"Red"={"X"=42816,"Y"=21824},"Green"={"X"=19200,"Y"=41216},"Blue"={"X"=9728,"Y"=4160}},"DefaultColorSpaceIsSRGB"=No,"NativeFormatHorizontalPixels"=2560,"DefaultWhitePoint"={"X"=20544,"Y"=21568,"Gamma"=144179},"SupportsVariableRefreshRate"=No,"AspectRatio"=15,"MinimumRefreshRate"=50,"WhitePoints"=({"X"=20544,"Y"=21568,"Gamma"=144179}),"PreciseAspectRatio"=115652,"ContinuousFrequencySupport"="None","SupportsStandby"=Yes,"NativeFormatVerticalPixels"=1440} | "EDID UUID" = "220EEC36-0000-0000-141F-0104A53C2278" Even though the UUIDs are the same you can clearly see the "AlphanumericSerialNumber"s are not "AlphanumericSerialNumber"="CN41201PZ4" "AlphanumericSerialNumber"="CN41201PZN" So this seems clearly a bug with how ever the UUID is created. The Mac has enough into to distinguish the 2 monitors
- alin23 4y ago
  The Alphanumeric Serial Number is not a standard EDID field, but a custom extension of it. MacOS definitely has a way to distinguish between monitors here, and in other cases too, but they would still have to go through every edge case and try to make sure they don't break previous working setups when including more data for the UUID. Only a small percentage of the monitors implement those EDID extensions so it's hard to rely on them. At best you can use them as a fallback, but that needs field data which they might not have had when the M1 firmware was written. The standard serial number field is 0 as you can see, so it's still a monitor bug. Incrementing an integer and compiling it into the firmware is not that hard.
  - gernb 4y ago
    > the Alphanumeric Serial Number is not a standard EDID field, Maybe I mis-understood your article. I thought it was up to the computer to decide what to add/sum/checksum into an UUID and therefore the fact that Mac is not using all the data is arguably a poor choice by Apple. > But they would still have to go through every edge case and try to make sure they don't break previous working setups when including more data for the UUID. They break those things all the time and people have to re-setup how their monitors are arranged. Doing yet another time doesn't seem like a big deal. If they really wanted to solve that problem they'd just compute a UUID the old and new ways and then remap the old to the new way. The only people this wouldn't work for is the people who they're fixing the bug for and those people already experience the bug.
    - 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.

by alin23 4y ago

gernb 4y ago

Interestingly ioreg reports the same UUID for both monitors but Apple Menu->About Mac->System Report->Graphics/Displays on Intel Mac shows different serial numbers (not UUID) for both monitors. So,.... this sounmds like a bug in MacOS, not the monitors. Whatever they are using for UUID they should be taking into account the serial numbers reported by System Report. Strange though, the M1 Mac shows no serial numbers. Both Macs have the swap problem. Maybe you should add an update to your article. This is clearly an Apple bug, not a monitor manufacture bug. At least in my case. -- update --- Here is the output from ioreg on an M1 Max Mac ioreg -r -c AppleCLCD2 | egrep 'ProductAttributes|EDID UUID' | "DisplayAttributes" = {"SupportsSuspend"=No,"MaximumRefreshRate"=60,"SupportsActiveOff"=No,"PortID"=16,"ProductAttributes"={"ManufacturerID"="HPN","YearOfManufacture"=2021,"SerialNumber"=0,"ProductName"="HP E27u G4","AlphanumericSerialNumber"="CN41201PZ4","LegacyManufacturerID"=8718,"ProductID"=14060,"WeekOfManufacture"=20},"MaxVerticalImageSize"=34,"MaxHorizontalImageSize"=60,"HasHDMILegacyEDID"=No,"Chromaticity"={"Red"={"X"=42816,"Y"=21824},"Green"={"X"=19200,"Y"=41216},"Blue"={"X"=9728,"Y"=4160}},"DefaultColorSpaceIsSRGB"=No,"NativeFormatHorizontalPixels"=2560,"DefaultWhitePoint"={"X"=20544,"Y"=21568,"Gamma"=144179},"SupportsVariableRefreshRate"=No,"AspectRatio"=15,"MinimumRefreshRate"=50,"WhitePoints"=({"X"=20544,"Y"=21568,"Gamma"=144179}),"PreciseAspectRatio"=115652,"ContinuousFrequencySupport"="None","SupportsStandby"=Yes,"NativeFormatVerticalPixels"=1440} | "EDID UUID" = "220EEC36-0000-0000-141F-0104A53C2278" | "DisplayAttributes" = {"SupportsSuspend"=No,"MaximumRefreshRate"=60,"SupportsActiveOff"=No,"PortID"=0,"ProductAttributes"={"ManufacturerID"="HPN","YearOfManufacture"=2021,"SerialNumber"=0,"ProductName"="HP E27u G4","AlphanumericSerialNumber"="CN41201PZN","LegacyManufacturerID"=8718,"ProductID"=14060,"WeekOfManufacture"=20},"MaxVerticalImageSize"=34,"MaxHorizontalImageSize"=60,"HasHDMILegacyEDID"=No,"Chromaticity"={"Red"={"X"=42816,"Y"=21824},"Green"={"X"=19200,"Y"=41216},"Blue"={"X"=9728,"Y"=4160}},"DefaultColorSpaceIsSRGB"=No,"NativeFormatHorizontalPixels"=2560,"DefaultWhitePoint"={"X"=20544,"Y"=21568,"Gamma"=144179},"SupportsVariableRefreshRate"=No,"AspectRatio"=15,"MinimumRefreshRate"=50,"WhitePoints"=({"X"=20544,"Y"=21568,"Gamma"=144179}),"PreciseAspectRatio"=115652,"ContinuousFrequencySupport"="None","SupportsStandby"=Yes,"NativeFormatVerticalPixels"=1440} | "EDID UUID" = "220EEC36-0000-0000-141F-0104A53C2278" Even though the UUIDs are the same you can clearly see the "AlphanumericSerialNumber"s are not "AlphanumericSerialNumber"="CN41201PZ4" "AlphanumericSerialNumber"="CN41201PZN" So this seems clearly a bug with how ever the UUID is created. The Mac has enough into to distinguish the 2 monitors

alin23 4y ago
The Alphanumeric Serial Number is not a standard EDID field, but a custom extension of it. MacOS definitely has a way to distinguish between monitors here, and in other cases too, but they would still have to go through every edge case and try to make sure they don't break previous working setups when including more data for the UUID. Only a small percentage of the monitors implement those EDID extensions so it's hard to rely on them. At best you can use them as a fallback, but that needs field data which they might not have had when the M1 firmware was written. The standard serial number field is 0 as you can see, so it's still a monitor bug. Incrementing an integer and compiling it into the firmware is not that hard.
- gernb 4y ago
  > the Alphanumeric Serial Number is not a standard EDID field, Maybe I mis-understood your article. I thought it was up to the computer to decide what to add/sum/checksum into an UUID and therefore the fact that Mac is not using all the data is arguably a poor choice by Apple. > But they would still have to go through every edge case and try to make sure they don't break previous working setups when including more data for the UUID. They break those things all the time and people have to re-setup how their monitors are arranged. Doing yet another time doesn't seem like a big deal. If they really wanted to solve that problem they'd just compute a UUID the old and new ways and then remap the old to the new way. The only people this wouldn't work for is the people who they're fixing the bug for and those people already experience the bug.
  - 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.