Regression: DDC I2C Display Freezing for internal displays

[Felix Richter]

On 7/19/25 14:23, Mario Limonciello wrote:
>
> On 7/19/25 5:10 AM, Felix Richter wrote:
>> Thanks for the reply.
>>
>> I am aware that i can read and `edid` via sysfs from the drm device. 
>> I did not know about `drm_info` but from a quick look at it I don't 
>> think it provides the information I need.
>>
>> The problem is not that I need more information about the attached 
>> display. The problem is that there is not enough information about 
>> the what `i2c` device corresponds to which monitors ddc channel. 
>> Relying on udev hierarchies is not sufficient, because in many cases 
>> the relevant i2c device has no parent drm output device. So when I 
>> have no information about the i2c device I need to get more 
>> information by reading from it. Then I know more and can map the 
>> device to the correct display. I am happy to change the approach if 
>> there is a simpler way for me to get this information.
>
> ❯ ls -alh /sys/class/drm/*/ddc
Nice, I will consider adding that information to the logic for matching 
i2c devices to displays. But I do have to tell you that still is not 
sufficient in every case. It probably works for all direct interfaces 
that are always present on the device. But it fails to match i2c ddc 
channels when monitors are attached via a docking station using USB-C. 
Those monitors will not even show up in the command you provided. This 
again leads me to having to probe the i2c device directly anyway.

> I get where you're coming from, but there are cases that are 
> ultimately impossible to prevent when it comes to "long", or 
> "frequent" sequences and responding to interrupts. There are lots of 
> examples like this in the kernel that if you break what a driver is 
> doing with a device from a userspace interface you get to pick up the 
> pieces.
>
> I'll give you two examples:
>
> 1) You can access R/W PCI config data.
> /sys/bus/pci/devices/*/config
>
> You can break power management state machines, bus mastering, really 
> anything a device driver can do from a userspace application.  For 
> example if I had a userspace app that did something like this:
>
> dd if=/dev/zero of=/sys/bus/pci/devices/${BDF}/config bs=1 count=4096
>
> and it broke how can the kernel do anything about it?
>
> 2) There was a case that fwupd was doing something very similar to you 
> with a "probe" but with the DP aux character device.  It was trying to 
> detect devices with updates and would fight specifically with link 
> training.  The outcome was non-functional devices.  The workaround 
> currently employed is that fwupd will wait a few seconds (5 or 10, I 
> forget) and then do the probe to avoid that fight.  This doesn't solve 
> things though because there are pulse interrupts that could still come 
> at any time. The DP spec has response requirements for these.
>
> We talked about it at the display next hackfest this year and the 
> decision was this information that fwupd was needing should be pushed 
> into the kernel (let fwupd probe a sysfs file that gets cached data 
> the driver fetched).
>
I get that you can not protect against every case of malicious use. I am 
not sure that my example qualifies as that extreme though. I am only 
trying to read some data, that is in no way comparable to actively 
changing values.
>
>> People have been experiencing similar screen freezing issues randomly 
>> on this drm issue thread: https://gitlab.freedesktop.org/drm/amd/-/ 
>> issues/4141#note_3016182> > This example highlights an issue that can 
>> be triggered reliably with a
>> very similar effect. It may not be the same issue, but they may be 
>> related.
>
> Yeah; I'm aware of this thread and agree it's an issue with similar 
> symptoms.

At the very least I hope that my example code for triggering a similar 
issue can help figure out what is going on there ;)