i2c address and kernel 6.17 (kubuntu 25.10) no longer reliable

[Canuma]

Not sure if this is the right project to raise an issue, but in the end I have a problem with dccutil and I hope someone here can help me.

My Setup: 3 Dell Monitors, daisy-chained via displayport, are connected to 2 gfx cards, 1 amd, 1 nvidia. Reason: AMD Card is for daily lowpower usage, nvidia is a) for demanding tasks and b) passed through for windows virtualization
The connection of the first Monitor in chain is a bit special, as it has a additional hdmi connection to the amdgpu, which basically acts as a control wire.

OS is Kubuntu 25.10, just upgraded and still fixing problems...

Problem:
To switch easily between amd and nvidia input, I came up with this little script, which worked now for years:

#!/bin/bash current=$(ddcutil --bus=5 getvcp 0x60 | sed -n "s/.*(sl=\(.*\))/\1/p") if [[ -z "$current" ]] then ddcutil --bus=2 setvcp 0x60 0x0f > /dev/null else ddcutil --bus=2 setvcp 0x60 0x10 > /dev/null fi

Now, with Kernel 6.17, things have changed, badly
At first, i thought i2c addresses just have changed. id 2 became id 3, id5 became 6. No Problem. However, the problem arises, when starting the windows vm. Nvidia card is "removed" from the host, and at some point (Not sure when) the i2c addresses are different again, partly. while id3 (it is monitor 1 which is connected also via hdmi on amd) stays the same, id 6 (Monitor 1, connected via dp on amd, visible to the system and via nvidia, invisible to the system) becomes id 14...

ddcutil detect before vm start
Display 1
I2C bus: /dev/i2c-3
DRM_connector: card1-HDMI-A-1
EDID synopsis:
Mfg id: DEL - Dell Inc.
Model: DELL U2414H
Product code: 41138 (0xa0b2)
Serial number: X4J7183Q04FL
Binary serial number: 808732236 (0x3034464c)
Manufacture year: 2018, Week: 13
VCP version: 2.1

Display 2
I2C bus: /dev/i2c-6
DRM_connector: card1-DP-3
EDID synopsis:
Mfg id: DEL - Dell Inc.
Model: DELL U2414H
Product code: 41122 (0xa0a2)
Serial number: X4J7183Q04FL
Binary serial number: 808732236 (0x3034464c)
Manufacture year: 2018, Week: 13
VCP version: 2.1

Display 3
I2C bus: /dev/i2c-7
DRM_connector: card1-DP-7
EDID synopsis:
Mfg id: DEL - Dell Inc.
Model: DELL U2414H
Product code: 41122 (0xa0a2)
Serial number: X4J7183Q0LNL
Binary serial number: 810307148 (0x304c4e4c)
Manufacture year: 2018, Week: 13
VCP version: 2.1

Display 4
I2C bus: /dev/i2c-8
DRM_connector: card1-DP-8
EDID synopsis:
Mfg id: DEL - Dell Inc.
Model: DELL P2414H
Product code: 41114 (0xa09a)
Serial number: 36WJX3BG1T6L
Binary serial number: 827602508 (0x3154364c)
Manufacture year: 2013, Week: 46
VCP version: 2.1

ddcutil detect after vm start
Display 1
I2C bus: /dev/i2c-3
DRM_connector: card1-HDMI-A-1
EDID synopsis:
Mfg id: DEL - Dell Inc.
Model: DELL U2414H
Product code: 41138 (0xa0b2)
Serial number: X4J7183Q04FL
Binary serial number: 808732236 (0x3034464c)
Manufacture year: 2018, Week: 13
VCP version: 2.1

Display 2
I2C bus: /dev/i2c-14
DRM_connector: card1-DP-3
EDID synopsis:
Mfg id: DEL - Dell Inc.
Model: DELL U2414H
Product code: 41122 (0xa0a2)
Serial number: X4J7183Q04FL
Binary serial number: 808732236 (0x3034464c)
Manufacture year: 2018, Week: 13
VCP version: 2.1

Display 3
I2C bus: /dev/i2c-15
DRM_connector: card1-DP-7
EDID synopsis:
Mfg id: DEL - Dell Inc.
Model: DELL U2414H
Product code: 41122 (0xa0a2)
Serial number: X4J7183Q0LNL
Binary serial number: 810307148 (0x304c4e4c)
Manufacture year: 2018, Week: 13
VCP version: 2.1

Display 4
I2C bus: /dev/i2c-16
DRM_connector: card1-DP-8
EDID synopsis:
Mfg id: DEL - Dell Inc.
Model: DELL P2414H
Product code: 41114 (0xa09a)
Serial number: 36WJX3BG1T6L
Binary serial number: 827602508 (0x3154364c)
Manufacture year: 2013, Week: 46
VCP version: 2.1

As a workaround, I tried to use the Display ID instead of i2c, However this would sometimes lead to complete gfx crashes when addressing the Monitor which is currently not detected as connected.

For now, I have worked around by simply checking if both i2c ids produce an empty result. But this feels even more ugly as it already is.

[rockowitz]

Suggest you use an identification option such as --sn that is unaffected by bus assignment or display id assignment.

[Canuma]

But --sn (Serialnumber?) would be the same, wouldn't it? So far only i2c addressing did work, as it delivered a "unique id" per connection (2 x DP, 1 HDMI on Monitor 1)

[rockowitz]

Looking more closely, I see that both your U2414H monitor is connected both to HDMI and DP-3. (Or is it the pathological situation where there are two monitors with identical SN, etc., likely identical EDIDs.) Display numbers are assigned in order of /dev/i2c bus number, then /sys/class/usbmsic/hiddev devices number., so if I2C bus numbers change the device numbers change with it. If you want to identify displays by their connector you could parse the output of ddcutil detect --verbose and extract the DRM_ connector field. Alternatively, you could navigate /sys to associate a /dev/i2c bus number with a DRM connector, but that is non-trivlal for Nvidia drivers.

Would a *--drm-connector option for display selection, e.g. --drm-connector card1-DP-3, address your needs? That would be straightforward to implement, but not in the upcoming release.

[Canuma]

Regarding the setup, I try to explain a bit shorter, maybe it becomes clear (I am sometimes a bit bad with that)

Two U2414H Dells, +3rd older one. All three daisychained (MST). 1st U2414H (Master Monitor) is connected via (physical) DP(1) on Ati, mini DP(3) on nvidia and hdmi(1) on ati. 2 U2414H is connected with the first via DP(2), 3rd is connected with second, DP(2). The reason for also connecting hdmi is, those dell behave strange, could be because of MST, dunno.

When Input DP(1) is activated, Monitor wouldn't know that DP(2) is also connected, also DP(2) can never be addressed. This goes vice versa. HDMI otoh is always visible, but would tell, the monitor is on hdmi out (which it obviously never is) , but would be able to receive "control commands" so i can switch those DP inputs.

Regarding a --drm-connector option, this suffers the same bug (ddcutil 2.2.1). As I found out, to trigger it, it is enough to just switch inputs manually.:

ddcutil detect --verbose | grep DRM (right after first boot)
DRM_connector: card1-HDMI-A-1
DRM_connector: card1-DP-2
DRM_connector: card1-DP-4
DRM_connector: card1-DP-5

switching to next DP Port, connected to nvidia, which has no drivers attached:
DRM_connector: card1-HDMI-A-1

back to physical DP 1:
DRM_connector: card1-HDMI-A-1
DRM_connector: card1-DP-3
DRM_connector: card1-DP-7
DRM_connector: card1-DP-8

Please note that the result is somewhat misleading anyway, as I said, those monitors are MST connected, on (physical) DP1, but probably this is just the way it is.

[rockowitz]

MST connections can behave problematically. It's often the case that he same MST connected monitor will appear on two different /dev/I2c buses. What I've never seen is the card-connector identifiers for physical inputs change. The interactions of multiple cards, drivers, and MST is outside the scope of what ddcutil can cope with.

As option --sn does not distinguish between the HDMI and DP inputs on the first monitor, consider using option --edid. It's ugly, but the HDMI and DP connectors should present different EDIDs as there's different information for DVI/HDMI vs DP.

[Canuma]

Thank you so much, that did the trick. As for the reason, I am pretty sure it is something that changed with kernel 6.17. MST stuff broke several times during the 6.x kernel and while most stuff got fixed, other was not. (Still get kernel panic when I forgot to turn on my Monitor before SDDM starts)
Anyway, as using the edid hex is indeed a bit ugly, may I ask (if this makes any sense) if you could add a feature where a shorter uid is generated from this edid hex, which could then be printed when using ddcutil detect and used as an identifier --uid or something like that?

[rockowitz]

Based on our earlier exchanges, I added recognizing EDID values encoded in Base64 to the enhancement list. If you think a shorter representation, that isn't guaranteed to be unique, would be useful, edit the enhancement list.

[Canuma]

I guess, being able to simply copy the base64 field from detect --verbose would be great already. I consider this more as a workaround anyway, hoping things get fixed at some point. So just don't waste time with it, also thanks for your work with ddcutil.

[rockowitz]

@Canuma A base64 encoding of the EDID is still a very long string. Branch 2.2.4-dev contains an alternative. If the value of option --edid begins with "...", (e.g. "--edid ...001A") the following hex digits are used to match against the last digits of the EDID. The first monitor with a matching EDID is selected. In principle more than one monitor could match, as a practical matter the chances are vanishingly small, given that the last digit in the EDID is a checksum.