Dell UltraSharp 2209WAf: DDC communication failed #424
Comments
|
Commonly, DDC communication failures entail data corruption, i.e. malformed packets. Such errors are sometimes correctable by increasing the time between packet writes and reads (i.e. with option --sleep-multiplier). In this case, the error code returned when writing DDC requests to the monitor is ENXIO. From the i2c-dev documentation: For /dev/i2c-1 and /dev/i2c-2, this status really means that there's nothing listening at address x37. For /dev/i2c-3, we know there is something listening, but the monitor fails to properly communicate. This is a very old monitor. Sometimes the Windows video drivers can better handle a monitor having a marginal DDC/CI implementation, than do Linux drivers. Perhaps ddcci (package ddcci-dkms) will have better luck since it is implemented as driiver, but I'm afraid you're out of luck trying to use ddcutil. |
Thank you a lot for looking into the details. Despite that it seems to be a lost cause.
I know the display is very old, but newer displays also have issues. It is possible that I have some soft spot regarding UltraSharp displays from Dell. I tried echo 'ddcci 0x37' | sudo tee /sys/bus/i2c/devices/i2c-3/new_deviceIt produces following response I was also running following command multiple times while playing with the display menu Very very rarely, maybe once per 100 attempts it actually changes the brightness. Although requested 0% becomes something like 81%. It is doable only for 0%. The usual response is
How do you think, if I manage to record I2C traffic with logic analyzer (to compare between Windows and Linux), would this shed some light on the problem? Or will it be still difficult to analyze? The second question is: Aren't there any kernel module parameters that affect I2C with Intel GPUs? I only see switches related to NVidia in the documentation. |
|
I didn't close this intentionally. I must have pressed close by accident on the phone. |
|
The issue is layers below i2c-dev, i.e. the video driver. i2c-dev "just" provides a common, standard kernel interface for all i2c drivers. However, there is one quirk that you might be able to exploit. i2c-dev provides two interfaces, one using ioctl() and a more user friendly interface using read() and write(). In principle these should be the same, but it turns out they call different functions in the video driver. If the proprietary nvidia driver is built in an unusual one path through i2c-dev fails. I rather doubt that this has any relevance for you, but you could try using option --use-file-io. Are saying that you can use ddcci to change monitor brightness by writing to a /dev/bus/ddcci or just that , or just that were able to get it to install? The error message in your setvcp example apparently has a bug. The "Try errors" line should list the individual errors from each retry. Option --excp is one way to see the individual errors. However, I doubt this will tell us anything we don't already know. The output from a logic analyser might be of interest in a bug report to the driver developers. From my perspective, the value of line sniffing lies in reverse engineering the protocols used by the manufacturers' Windows applications to control advanced monitor features. There is one video driver option that doesn't exist and would be helpful, namely to use a lower bus speed than the 100kb/sec standard. This would, I believe, resolve many communication errors with monitors whose DDC implementation is marginal. Several years ago there was an experimental branch in, IIRC, the i915 driver that lowered the bus speed, but it was never incorporated in the main branch. |
|
Thank you for detailed explanation. Adding
I only managed to set it up. It was not straightforward, most likely due to a bug. The current version of Afterwards it still failed to work, although it generated some debug entries visible in my previous message.
I found your original discussion about the topic https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/37. Looking at this branch https://github.com/vsyrjala/linux/tree/i2c_bus_speed I came up with following patch diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c b/drivers/gpu/drm/i915/display/intel_gmbus.c
index e9e4dcf34..88aba021e 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -200,7 +200,7 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private *i915, unsigned int pin)
/* Intel GPIO access functions */
-#define I2C_RISEFALL_TIME 10
+#define I2C_RISEFALL_TIME 5
static inline struct intel_gmbus *
to_intel_gmbus(struct i2c_adapter *i2c)
@@ -916,7 +916,7 @@ int intel_gmbus_setup(struct drm_i915_private *i915)
bus->adapter.retries = 1;
/* By default use a conservative clock rate */
- bus->reg0 = pin | GMBUS_RATE_100KHZ;
+ bus->reg0 = pin | GMBUS_RATE_50KHZ;
/* gmbus seems to be broken on i830 */
if (IS_I830(i915))
After building of a current Ubuntu 24.04 LTS kernel (6.8.0-35) with the change
So it is all about the speed of I2C. Thank you a lot for help 😄 |
|
This is exciting! An actual example that can be referenced of DDC communication being fixed by lowering the bus speed! The devil, of course, is in the details: what other changes are needed to make lowering the bus speed robust, how the speed change is communicated to the driver, etc. I will post an issue on the i915 freedesktop.org list, then you can follow up with the details of what you've done. |
|
@w8jcik I created issue 11528 at freedesktop.org. Please comment on that issue with the details of your driver changes. I would encourage those having DDC communication errors that ddcutil cannot resolve, particularly for marginal monitors, to add themselves to the interested parties on that issue and upvote the issue. |
|
This i915 patch also fixed both ddcutil and ddccontrol for me, AOC2217. |
I have three displays connected directly to an Intel GPU.
Two displays work fine with
ddcutilbut the third Dell 2209WAf shows DDC communication failed.Failing Dell 2209WAf is capable of DDC (display, wires), based on a fact that it's DDC works after reboot to Windows.
Debug commands
Output from
ddcutil interrogate --verboseDELL-2209WAf-interrogate-report.log
(intentionally disconnected other displays for the report).
Looking at some past issues I also tried calling
Display does not get a number, so calling by a bus number
GPU
i2c-devis built into kernel, the default Ubuntu 24.04 LTS kernel.Versions of
ddcutilI tried
[email protected]shipped with Ubuntu 24.04 LTS, as well as manually built1.4.5and2.1.5-dev.Other platforms
Brightness control of all three displays works in Windows, so it is not related to wires or wrong settings of the display. The application I tried is called https://github.com/emoacht/Monitorian. Although I think that Monitorian does nothing special, just Windows API does DDC out of the box.
Past issues
I found this issue https://unix.stackexchange.com/questions/546000/adjust-backlight-via-ddc
The OP solved it by passing parameters to Nvidia kernel module, but this is an Intel GPU.
The text was updated successfully, but these errors were encountered: