--match-edid matches different edids to same name

[BronzeDeer]

Context

I'm currently trying to make my NixOS setup more resilient to xrandr/nvidia arbitrary name shuffling. Technically autorandr and it's edid based matching should be perfect, however after replugging monitors my setup is now broken. If I call autorandr with --match-edid manually, it maps two screens with very similar (but different) edids to the same name, breaking detection. The edid similarity is to be expected since they are the same model of monitor, bought at the same time.

Version

autorandr 1.15 (installed via nixpkgs#ccc0c2126893dd20963580b6478d1a10a4512185)

What am I doing

calling autorandr --match-edid

What should happen

Different edids are match to their correct name

What actually happens

Two similar Edids are mapped to the same name (which is one of the names for the similar monitors and which it is is random every boot)

Reproduction

Here's my setup file

left 00ffffffffffff0004722b019d1170142f15010380341d782aeed5a555489b26125054bfef80714f810081809500950fb300d1c00101023a801871382d40582c450009252100001e000000fd00384b1e5311000a202020202020000000fc0041636572204732343548510a20000000ff004c4b4b3057303134343334300a0111020321324f010203040590111213149f060715166c030c00100080a5c000000000023a80d072382d40102c9680092521000018011d8018711c1620582c250009252100009e011d80d0721c1620102c258009252100009e023a80d072382d40102c258009251200001e00000000000000000000000000000000000000000000dc
middle 00ffffffffffff001e6d095b3d2902000c1b0104b53c22789e3035a7554ea3260f50542108007140818081c0a9c0d1c08100010101014dd000a0f0703e803020650c58542100001a286800a0f0703e800890650c58542100001a000000fd00383d1e8738000a202020202020000000fc004c4720556c7472612048440a20012c0203117144900403012309070783010000023a801871382d40582c450058542100001e565e00a0a0a029503020350058542100001a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c8
right 00ffffffffffff0004722b01481470142f15010380341d782aeed5a555489b26125054bfef80714f810081809500950fb300d1c00101023a801871382d40582c450009252100001e000000fd00384b1e5311000a202020202020000000fc0041636572204732343548510a20000000ff004c4b4b3057303134343334300a0163020321324f010203040590111213149f060715166c030c00100080a5c000000000023a80d072382d40102c9680092521000018011d8018711c1620582c250009252100009e011d80d0721c1620102c258009252100009e023a80d072382d40102c258009251200001e00000000000000000000000000000000000000000000dc

Obviously the human readable position names don't align with the default xrandr names. But invoking autorandr --match-edid gives me the following

#See both left and right getting mapped to the same name
default: renaming display left to DP-3  
default: renaming display right to DP-3
default: renaming display middle to DP-4
default

I first thought I typoed in my config because the edids looked extremely similar, so I diffed them

# Ignore out the middle monitor whose edid ends on c8
autorandr --fingerprint | grep -v 'c8$' | cut -d' ' -f2 > /tmp/edids
# Diff line1 and line2
git diff --word-diff-regex='.' <(cat /tmp/edids | tail -n+2) <(cat /tmp/edids | head -n1)

This gives me the following output, showing that the two screens differ slightly in edid

--- a/proc/self/fd/15
+++ b/proc/self/fd/17
@@ -1 +1 @@
00ffffffffffff0004722b01[-48-]{+9d1+}1[-4-]70142f15010380341d782aeed5a555489b26125054bfef80714f810081809500950fb300d1c00101023a801871382d40582c450009252100001e000000fd00384b1e5311000a202020202020000000fc0041636572204732343548510a20000000ff004c4b4b3057303134343334300a01[-63-]{+11+}020321324f010203040590111213149f060715166c030c00100080a5c000000000023a80d072382d40102c9680092521000018011d8018711c1620582c250009252100009e011d80d0721c1620102c258009252100009e023a80d072382d40102c258009251200001e00000000000000000000000000000000000000000000dc

I took a quick look at the source, but haven't stepped through with a debugger yet. I also don't know anything about the format of EDIDs so I don't know if autorandr does something more fancy than byte-for-byte comparison. Any Idea where I should start my investigation?

[BronzeDeer]

Update: I've looked into the code a little and see that autorandr does not match on edid but on a fingerprint, which is the same for both monitors, I'll look into how the fingerprint is calculated later

Update2: Apparently the edids have the same serial encoded and the fingerprinting process prefers serial over edid (also the fingerprints are directly compared which will collidle with similar short edids if serials are not present/readable, the fingerprint_equals function should likely be used here)

Update3: This seems to be an Acer "feature" https://community.acer.com/en/discussion/689648/correct-serial-number-from-edid-how-i-could-get-the-serial-number-from-the-edid-data

[BronzeDeer]

Looking way deeper into the code, I actually found an inconsistency in how the fingerprints are calculated. The current fingerprinting behaviour is introduced in this commit:

d9b1953#diff-1e1a4777675c9d76e4f08f4a1ecfd24016758e0639d451af4d505004c33ee618R323

Based on the commit message, serial no is the gold standard and will be used if available, and only otherwise edid information (here timing) will be used. The case introduced actually reverses this, preferring timing information when available.

Using edid parsers I actually found out that my acer screen do correctly list separate serial numbers, so the fingerprinting does not seem to do what we want and describe as desired behaviour (on screens of the same model, produced close to another, I'd always expect timing to match, but serials to differ)