[Bug]: Can't use DDC with identical monitors

[maximbaz]

[Bug]: Can't use DDC with identical monitors

[maximbaz]

Hello, thanks for the report. Do you know if the path is preserved between reboots, or its getting a random value assigned on every boot?

[CorvetteCole]

the paths for my monitors are always /dev/ic2-6 and /dev/i2c-7. However I'm not sure if they are implementation defined as persistent

[maximbaz]

First, a disclaimer: Personally I don't use external screens and ddc feature, I trust and rely on community to guide the best implementation for it. Your feedback is very appreciated!

I just confirmed with @cyrinux who implemented support for ddcutil, that the reason the code didn't use paths in the first place was because those paths were not stable, at least on his setup, and changed with every reboot. That's why we had to go for something that is stable, like model and serial number.

In any case, I was thinking it could be a good idea to actually switch to https://gitlab.com/ddcci-driver-linux/ddcci-driver-linux - not only should it let us remove custom code for using ddc in the first place, but it should (hopefully) also get rid of all those DDC/CI error: that you see in your logs, and make it more robust to adjust brightness on external screens.

What do you think about this idea? Would you be interested to try to install that driver, and see if after that you are able to control brightness using /sys/class/backlight/, i.e. using tools like light, or even using wluma and [[output.backlight]] for those external displays?

We don't have to remove support for [[output.ddcutil]], especially if installing or configuring that driver turns out to be not trivial, but we could at least recommend it to folks, if it truly provides a better experience!

But back to the existing implementation of ddcutil, because the paths are not stable (at least not for everyone), I'm not sure including support for paths is a good idea, because it would provide a false sense that you should be able to rely on those, when in fact you are not...

[CorvetteCole]

I have actually been using the ddcci-driver-linux and then just native Linux backlight interface (for months now), it has worked great. However after updating to kernel 6.2 the DKMS module no longer enumerates displays for me and I don't have time to figure it out right now + the driver is unmaintained.

[CorvetteCole]

I do actually agree with you on the paths thing, I was trying to switch to ddcutil on here as a quick and dirty workaround to the driver not working

[CorvetteCole]

For the record, I've gotten around this by overriding the EDID on the monitors using kernel parameters. Each monitor now has a unique serial number which fixes this (although the EDID's are of course linked to display outputs instead of physical devices... this is a workaround). I think I will close this issue as not planned