Jani, Thanks for your quick and detailed response. You wrote: > The single DP link is divided to several logical links to sink devices. Suppose the dock has a DVI and/or HDMI connector. Are those connectors logical sinks to a master DisplayPort connection, or do they have their own connection through the dock to the laptop? If the former, then telling people to use a DVI or HDMI connection on the dock would not be a workaround. ddcutil looks for displays by examining all non-SMBus /dev/i2c devices on the system. If checks for the presence of slave address x50 and x37. If they exist it tries to read the EDID on x50 and a Virtual Control Panel feature value on x37. Looking at one of the user logs, I see that a couple /dev/i2c-n devices have udev sysattr name DPMST. When ddcutil probes those /dev/i2c devices, slave addresses x50 and x37 appear active, but reading the EDID fails. So it would seem that the i2c-dev driver is not properly handling DP-MST. Does that interpretation seem correct? If so, I'll bounce the issue over to the I2C folks. Alternatively, do the DP-MST devices present as some other userspace device that I can program to? I imagine that searching udev for sysattr name DPMST would find any place in the /dev tree besides /dev/i2c where the devices are surfaced. Would this be a bit-banging interface, or something at a higher level? Or would I need to write a device driver? Thanks again, Sanford On 05/05/2017 05:59 AM, Jani Nikula wrote: > On Fri, 05 May 2017, Sanford Rockowitz <rockowitz@xxxxxxxxxxx> wrote: >> I am the author of ddcutil (www.ddcutil.com), a Linux utility that >> manages monitor settings using DDC/CI. I am seeing a pattern of user >> error reports in which I2C communication is not working when a system >> with a recent Intel chip, using the i915 driver, is plugged into a >> docking station. Communication works when the video cable is plugged >> directly into the laptop. There also seems to be a correlation with >> whether a DisplayPort cable is being used (i.e. the I2C-over-aux path is >> being executed), though this correlation is not as clear. >> >> I'm not sure how best to go about reporting these issues. The usual bug >> reporting mechanism asks for detailed information about a specific >> system, which I don't have. What I do have is the ability to see a >> pattern. >> >> Because I2C communication is so fragile (dependencies on hardware >> quirks, drivers, etc), ddcutil (which is written in C) has an extensive >> subsystem devoted to remotely diagnosing user configurations. It >> already reports DDC (i.e. I2C) communication errors, and has interfaces >> to udev, libdrm, and x11 libraries. If there is some i915 specific code >> I could add to refine the diagnosis, I would be happy to add that. >> (Note: ddcutil is entirely a user space program, using the i2c-dev >> interface.) >> >> Suggestions on how to proceed appreciated. > The issues are related to DP MST (Multi-Stream Transport) that the docks > use nowadays. The single DP link is divided to several logical links to > sink devices. The I2C communication needs to be encapsulated to remote > I2C-over-AUX reads and writes, with the logical DP MST addresses, to > route them to the correct sinks. In kernel, this is handled by the MST > topology manager. > > Instead of using the I2C device directly for, say, card0-DP-1 or > DPDDC-A, you need to be using the dynamically created and removed DP MST > I2C devices that wrap the communications to remote I2C-over-AUX. Frankly > I am not sure if the naming or parent/child relationships of the devices > are quite right (based on looking at the code), but you should find the > sysfs name attribute will be DPMST. I'm also not sure how you can > associate those with the physical devices you have. > > If you have an option to tell your tool which I2C device to use, that > should get you started and debugging. If there are issues with that, > please let us know. > > In the long run, we should probably do something to make the discovery > of the DP MST I2C devices easier, with naming and/or better parent/child > relationships of the devices. It's just that the userspace I2C interface > was probably pretty far down on the list of priorities when writing DP > MST. > > > BR, > Jani. > > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
