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..
