@PianoPro - Sorry for the absolute dump that is about to happen.
EDID Dumps
I took one of the monitors and plugged it into my PC across the room again. I did this last night, but I only did it to dump the EDID with
EDID/DisplayID Writer Beta 2.
Here is a link to a OneDrive share of the EDID dump from the monitor using the aforementioned tool. Password is "samsung".
Opening the EDID dump in
Deltacast E-EDID shows the following with regard to the serial number:
- "809585720" in the "Serial Number" field under "Vendor and Product ID"
- this would correspond to the early, optional serial number
- this is also the serial number that is identical between my two identical monitor models that were purchased at the same time
- "HCPR200957" in the "Display Product Serial Number" field under "Block 4 - Display Descriptor" coded as "Display"->"Serial Number"
- I believe this to be the field that shows as "AlphanumericSerialNumber" when doing an `ioreg` command on my MacBook
- This is a unique serial number (at least between my two monitors) and partially matches the sticker on the back of each respective monitor.
So that is what a EDID tool says is in the direct EDID bin dump. Ok... so what about what Windows thinks?
I quickly found a Powershell script to dump what Windows sees the monitor serial numbers to be. I
do not know whether the actual display driver installed (AMD vs. Nvidia vs. Intel vs. whatever) would affect the outcome, here. It gives the following serial number: HCPR200957. Note that that matches what is in the "AlphanumericSerialNumber" field when querying via`ioreg` on macOS. The Powershell I ran is below:
Code:
Get-WmiObject WmiMonitorID -Namespace root\wmi |
ForEach-Object {
$Manufacturer = [System.Text.Encoding]::ASCII.GetString($_.ManufacturerName).Trim(0x00)
$Name = [System.Text.Encoding]::ASCII.GetString($_.UserFriendlyName).Trim(0x00)
$Serial = [System.Text.Encoding]::ASCII.GetString($_.SerialNumberID).Trim(0x00)
echo $Manufacturer,$Name,$Serial
}
When using a simple Swift program in Xcode to call `
CGDisplaySerialNumber`, the serial number returned is the "bogus" one of "809585720". This is why I suggested in a previous post that it would appear that Apple should, at a minimum, update `CGDisplaySerialNumber` to be more intelligent and suss out the true serial number stored later in the EDID. Whether that would fix a low-level OS display issue is beyond my understanding. I'd guess not, but at least then programs like Luna and displayplacer could query useful information to help accurately place displays. I don't know what calls Luna makes, but I know for sure that displayplacer calls `CGDisplaySerialNumber` directly; I've checked the source code.
All of this was done on Thunderbolt 3, DisplayPort, or HDMI. These monitors do not have DVI, VGA, or anything "legacy" like that.
VESA EDID Standard
The
VESA EDID 1.4 standard has this to say about the early SN bytes:
3.4.3 ID Serial Number: 4 Bytes
The ID serial number is a 32-bit serial number used to differentiate between individual instances of the
same display model. Its use is optional. When used, the bit order for this field shall follow that shown
in Table 3.7. The four bytes of the serial number are listed least significant byte (LSB) first. The range
of this serial number is 0 to 4,294,967,295. This serial number is a number only --- it shall not represent
ASCII codes. If this field is not used, then enter “00h, 00h, 00h, 00h”.
...
Note for Table 3.7: The EDID structure version 1, revision 1 (and newer) offers a way to represent the
serial number of the monitor as an ASCII string in a separate descriptor block. Refer to section 3.10.3
Display Descriptors for an alternative method of defining a serial number.
So, the first SN field
is optional, though it does declare that the purpose is "to differentiate between individual instances of the same display model". It seems silly to me to have such an important function be an optional field, but I'm not the standard writer.
It goes on later to define the "second" possible serial number descriptor via a "Display Descriptor" in section 3.10.3.1:
3.10.3.1 Display Product Serial Number Descriptor Definition (tag #FFh)
Up to 13 characters (using ASCII codes) of a serial number may be stored in the Display Product Serial
Number Descriptor (tag #FFh). The data shall be sequenced such that the 1st byte (ASCII code) = the 1st
character, the 2nd byte (ASCII code) = the 2nd character, etc. If there are less than 13 characters in the
string, then terminate the serial number string with ASCII code ‘0Ah’ (line feed) and pad the unused
bytes in the field with ASCII code ‘20h’ (space). Table 3.24 defines the format. Refer to Appendix E
for ASCII Reference Tables
Given those definitions, I'm inclined to believe that Samsung has not deviated from the 1.4 spec, here, unless one wants to argue that putting identical values in the early SN field does not, in fact, help to "differentiate between individual instances of the same display model" (I do wish to argue it).
I probably just have a reading comprehension problem, but I
do not see any verbiage calling out how the two fields should interact or be preferentially treated based on presence of one or the other. The only thing I see in that regard is the early SN field definiton saying "00h, 00h, 00h, 00h" should be used if "the field is not used".
Conclusions
Unless there is some very specific language in a spec document that sways my opinion again, I'm inclined to believe that Apple, as you seem to have been preaching for a decade, is mostly at fault. Windows (at least my machine with a very new AMD card and drivers) seems to handle ripping the SN from the "Display Descriptors" section of the EDID just fine. It my macOS machine (M1 MacbookPro running Ventura 13.4.1) that seems to
entirely **** the bed with respect to querying the "actual" SN. Aside from the complaint about how Samsung
did use the early SN field juxtaposed against the VESA document that declares what it is for, the only thing that trips me up is that you claim the standard has priority based on field population that I have been unable to find. I guess that doesn't really matter if the early SN field is marked as "optional". The later field also seems to be marked as optional. So, I guess some monitor manufacturer could decide they want to see the world burn and not populate
either field.
At this point, I do feel like it is Apple that should fix their decisioning logic when decoding/parsing the EDID from a monitor.
Clearly something is being done differently if my Windows 11 machine is pulling the later field but my macOS machine is pulling the early field.
I still wish I could write over the EDID on one of the monitors; it'd likely allow me to fix the issue right now.
