Regression: DDC I2C Display Freezing for internal displays

[Felix Richter]

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.

Ultimately I don't think that me accessing the bus should be the issue 
here … This issue did not happen with kernel 6.6, so it definitely 
qualifies as a regression. In my mind it is the job of the driver to 
handle resource allocation, so if the bus is in use by somebody else it 
is the kernels job to handle who uses it. It is not the users job to 
have to worry about some sort of synchronization issue. That is the 
operating systems job.

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.


On 7/18/25 20:02, Mario Limonciello wrote:
>
> At least to me, this issue sounds like a case that multiple entities 
> are trying to communicate with the panel at the same time.
>
> By setting dcdebugmask=0x10 what you're essentially doing is stopping 
> the display hardware from trying to put the panel into PSR.  So there 
> is "less" I2C traffic to fight with.
>
> *Why* are you using I2C to read the EDID like this?  Could you instead 
> use /sys/class/drm/cardX-inputY/edid?  Or even better - can you use 
> the information from drm_info to make decisions?
>
> I think the less I2C traffic done directly from userspace the better 
> when it comes to synchronization issues..
>