Last question (I think). You wrote: > You'll want the DP MST I2C code fixed. Well, at least it's my *guess* that's where the problem is.
Where do I go to post this problem? Thanks, Sanford On 05/05/2017 12:49 PM, Jani Nikula wrote: > On Fri, 05 May 2017, Sanford Rockowitz <rockow...@minsoft.com> wrote: >> 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. > If I understand you right, the former. The connections look like > independent DP sinks. (Even for DVI/HDMI; the conversion is in the dock > in DP MST based docks.) > >> 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. > Seems like this should work. > >> 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. > I think it's more likely the issue is in core drm DP MST code, and > nobody ever tried the I2C interface for them. The core I2C code should > be completely ignorant about DP MST, or even DP for that matter. > >> 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? > You'll want the DP MST I2C code fixed. Well, at least it's my *guess* > that's where the problem is. > > BR, > Jani. > >> >> On 05/05/2017 05:59 AM, Jani Nikula wrote: >>> On Fri, 05 May 2017, Sanford Rockowitz <rockow...@minsoft.com> 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx