Re: Regression: DDC I2C Display Freezing for internal displays

[Felix Richter <judge@felixrichter.tech>]

[-- Attachment #1: Type: text/plain, Size: 2156 bytes --]


On 7/20/25 17:45, Alex Deucher wrote:
> DP (and all of its variants, eDP, USB-C thunderbolt) doesn't actually
> use i2c directly.  It's aux; you can do i2c over aux, but in the case
> of MST, it's more like a network for displays so naively messing with
> i2c buses from userspace won't do what you expect.  For MST, you have
> a single set of i2c/aux pins for the connector which may have several
> monitors on the other end.
> DP is a two way communications channel.  You may have the driver
> training a link or communicating with other devices on the DP network
> (MST hubs, monitors, etc.).  You can also get requests from the
> monitor to the driver via hpd interrupts.  Many of these processes do
> not do well if interrupted.
>
> Alex
>

I get that this is a part of a very complicated protocol. I am still 
irritated that the points you mention are relevant from the perspective 
of userspace. From my perspective there is no expectation that the 
kernel should just interrupt ongoing procedures when I access an i2c 
link. I am happy to wait for the kernel to schedule the operation for 
when it is convenient. After all the point of abstraction is not having 
to worry about the layers underneath. And if the drm device exposes an 
i2c device that I access it is the job of the drm driver to handle how 
and when that transmission takes place.

Also I would like to point out that the bug I am experiencing does not 
materialize in case of any external displays attached via an MST hub. It 
happens with the internal display even when nothing is attached. The 
point about MST Hubs is only relevant because those i2c interface can 
not be matched via udev to the corresponding display. Though the can be 
matched when reading edid from the device. Those interfaces then work 
just fine when I use ddc to read/set monitor inputs. So those points do 
not seem to really be relevant in case of the screen freezing trigger.

Anyway that is just my thoughts on the matter. I'll look into writing a 
workaround to maybe avoid some i2c devices that could be problematic.

And there still might be a relation to the other screen freezing issues.

Felix

[-- Attachment #2: Type: text/html, Size: 2890 bytes --]