[Bug]: Can't use DDC with identical monitors
Closed this issue · 6 comments
Steps for reproducing the issue
- Have two monitors with identical EDIDs
- Attempt to use them with wluma
What is the buggy behavior?
Wluma "detects" two identical displays. You cannot have identical configuration blocks, but trying to initialize just one results in an error. It is impossible to initialize both
What is the expected behavior?
Both monitors can be enumerated and accessed, since they can be through ddcutil. A possible way around buggy monitor behavior may include allowing users to manually specify the path (i.e. /dev/i2c-7), or by including the path in the monitor name that is matched.
Logs
[2023-03-07T19:23:00Z DEBUG wluma::brightness::ddcutil] Discovered displays: ["ED273UR ", "ED273UR "]
[2023-03-07T19:23:00Z DEBUG wluma::brightness::ddcutil] Using display 'ED273UR ' for config 'ED273UR '
[2023-03-07T19:23:00Z INFO wluma] Continue adjusting brightness and wluma will learn your preference over time.
[2023-03-07T19:23:03Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: invalid DDC/CI length
[2023-03-07T19:23:05Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: invalid DDC/CI length
[2023-03-07T19:23:06Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: Unsupported VCP code
[2023-03-07T19:23:06Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: Expected DDC/CI length bit
[2023-03-07T19:23:07Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: Expected DDC/CI length bit
[2023-03-07T19:23:07Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: invalid DDC/CI length
[2023-03-07T19:23:08Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: Expected DDC/CI length bit
[2023-03-07T19:23:09Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: Expected DDC/CI length bit
[2023-03-07T19:23:09Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: Expected DDC/CI length bit
[2023-03-07T19:23:09Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: invalid DDC/CI length
[2023-03-07T19:23:11Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: invalid DDC/CI length
[2023-03-07T19:23:12Z DEBUG wluma::predictor::controller] [ED273UR ] Learning Entry { lux: "lighter", luma: 0, brightness: 100 }Version
4.2.0
Environment
LSB Version: n/a
Distributor ID: Arch
Description: Arch Linux
Release: rolling
Codename: n/a
Linux cole-pc 6.2.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 03 Mar 2023 15:58:31 +0000 x86_64 GNU/Linux
egrep: warning: egrep is obsolescent; using grep -E
clang 15.0.7-1
intel-opencl-clang 15.0.0-1
lib32-vulkan-icd-loader 1.3.240-1
lib32-vulkan-radeon 22.3.6-1
rocm-clang-ocl 5.4.3-1
rocthrust 5.4.3-1
rust 1:1.67.1-1
vulkan-amdgpu-pro 22.40_1538781-1
vulkan-headers 1:1.3.240-1
vulkan-icd-loader 1.3.240-1
vulkan-radeon 22.3.6-1
vulkan-tools 1.3.240-1
wlroots 0.16.2-1
egrep: warning: egrep is obsolescent; using grep -E
zsh: command not found: dpkgHello, thanks for the report. Do you know if the path is preserved between reboots, or its getting a random value assigned on every boot?
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
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...
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.
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
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