rockowitz

Your problem appears to be the inverse of that described in [this issue](https://gitlab.freedesktop.org/drm/intel/-/issues/3605) that I posted to the drm/intel issue list some time ago. In that case, a /dev/i2c device...

It's more a matter of what's not there. I would expect to see a /dev/i2c device for the port on the laptop, and two more for the ports on the...

I suggest you update the report with the specific models of each of the laptop, dock, and monitors. e.g. it's not just an Asus Dock, its an ASUS SimPro Dock...

You pretty clearly are contending with a marginal I2C implementation. Your laptop appears to be quite old - that may contribute to the problem. Some things to try: - Increase...

There's no ***--ddc*** output in your stats.txt file. If you have one available, try testing with a different monitor. There are monitors with marginal DDC implementations.

@JFingerle I apologize for having missed the ***--ddc*** output at the bottom of the file. What it shows is that response packets are corrupted. Several of them have a duplicate...

I have a similar U32H750 which, despite what the numbering suggests, appears to be a later version of your U32D970. The display controller type and firmware level (VCP features xc8...

@digitaltrails It looks like the dynamic sleep algorithm is being insufficiently conservative. After pulling the latest changes to branch 2.0.0-dev, please try running the following script, which will loop until...

@digitaltrails The log you sent is perplexing. It shows all the ddc_write_read_with_retry() calls executing with sleep-multiplier from 1.0 to 2.0, yet all fail with a DDCRC_NULL_RESPONSE. It's as if I'm...

That doesn't help me much. What happens if you run with ***--trace all***? The output will be voluminous, but should give a better idea of where the lockup occurs.