[RFC] drm + i915 DP MST code preview

[Chris Wilson]

On Sat, May 03, 2014 at 07:08:02AM +1000, Dave Airlie wrote:
> On 2 May 2014 18:52, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > On Fri, May 02, 2014 at 02:39:37PM +1000, Dave Airlie wrote:
> >> Hi,
> >>
> >> Branch: http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-i915-mst-support
> >>
> >> Okay I've gotten this to light up some monitors using -modesetting so it
> >> must be ready for an initial posting,
> >
> > I see that connectors are added/removed dynamically based on branch
> > discovery, but I haven't spotted how that is communicated to userspace.
> > I was expecting to see a new uevent. Or do you simply want userspace to
> > update it lists of connectors on every hotplug event? Is there anyway to
> > retrieve the guid so that we can associate the same XID to each branch
> > device for the server lifetime? (Is that even a sane idea?) Can we
> > detect when a DP dongle is present splitting DVI/VGA using MST but since
> > they use different encoders they already falsely appear as unique
> > connectors to i915.ko?
> 
> I hadn't considered a new hotplug event but I suppose one makes sense
> for this actually,
> however userspace will still get old school hotplug events anyways as
> the connectors transition to connected state.
> 
> I'm not sure how much overhead userspace would have calling
> drmGetResources on every hotplug it certainly shouldn't be a common
> event,

I realised that GETRESOURCES is not too heavy later. I was thinking that
the maintainance of the X state would be more troublesome, but it
doesn't appear so. I still think having a separate event type for
branch changes will be useful, if only for the purposes of diagnostics.
 
> the GUID is only on DP 1.2 devices, so you don't get one for ever
> port, also GUIDs are wiped on powerdown on most devices, default GUID
> is 0 except where devices have USB hubs as well, so it probably
> doesn't make much sense to bother exposing them directly.

Ok. It looks like if we do attempt to maintain persistent naming, we need
to do it in the kernel anyway. That is to make sure that a downstream
device always has the same type-id upon reconnection - at least for the
lifetime of module. Or maybe the output name is irrelevant for
preserving extended desktop configurations?
 
> I'm not sure about the last question, MST is always active DP
> conversion, each port the protocol advertises will appear as a
> connector, the protocol doesn't offer much more detail, like my dock
> has a DP port and a HDMI port shared on one DP port, depending on what
> is plugged in the port is configured different, but it appears as the
> same connector.

Hmm. I think I am confused. I thought we had a recent report of a 
DP-to-VGA/DVI splitter that on Windows you could drive the VGA + DVI
separately, but on Linux they could only be cloned. That sounds like MST.
However, I am pretty sure the xrandr was reporting VGA and HDMI outputs
(behind the splitter) that the user had some control over. I am not too
sure if I have the details right though.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre