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