Regression: DDC I2C Display Freezing for internal displays

[Alex Deucher]

On Sat, Jul 19, 2025 at 1:38 PM Felix Richter <judge at felixrichter.tech> wrote:
>
> 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.
>

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.

Alex

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

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

> >
> >> 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 ;)