<!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On 7/20/25 17:45, Alex Deucher wrote: </div> <blockquote type="cite" cite="mid:CADnq5_Mpsd_68T3uKqdXzHSzm4dWcHamYJZMNpPNZFHBp=DORQ@mail.gmail.com"> <pre wrap="" class="moz-quote-pre"> 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.</pre> <pre wrap="" class="moz-quote-pre"> 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 </pre> </blockquote> I get that this is a part of a very complicated protocol. I am still irritated that the points you mention are relevant from the perspective of userspace. From my perspective there is no expectation that the kernel should just interrupt ongoing procedures when I access an i2c link. I am happy to wait for the kernel to schedule the operation for when it is convenient. After all the point of abstraction is not having to worry about the layers underneath. And if the drm device exposes an i2c device that I access it is the job of the drm driver to handle how and when that transmission takes place. Also I would like to point out that the bug I am experiencing does not materialize in case of any external displays attached via an MST hub. It happens with the internal display even when nothing is attached. The point about MST Hubs is only relevant because those i2c interface can not be matched via udev to the corresponding display. Though the can be matched when reading edid from the device. Those interfaces then work just fine when I use ddc to read/set monitor inputs. So those points do not seem to really be relevant in case of the screen freezing trigger. Anyway that is just my thoughts on the matter. I'll look into writing a workaround to maybe avoid some i2c devices that could be problematic. And there still might be a relation to the other screen freezing issues. Felix </body> </html>