[RFC] drm + i915 DP MST code preview

[Dave Airlie]

On 7 May 2014 18:07, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Wed, May 07, 2014 at 12:16:37AM -0700, Aaron Plattner wrote:
>> On 05/03/2014 02:00 AM, Chris Wilson wrote:
>> >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:
>> >>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?
>>
>> Dunno if it helps, but for roughly similar reasons we ended up naming the
>> outputs based on their topology paths in the NVIDIA driver.  So for example
>> a port named DP-3 that has a Dell UP2414Q attached will show up as two
>> outputs named DP-3.1 and DP-3.8 since its internal bridge uses downstream
>> ports 1 and 8.  This has worked out fairly well in practice.
>>
>> Here's how I described it in the README:
>>
>>     When DisplayPort 1.2 branch devices are present, display
>>     devices will be created with type- and connector-based names
>>     that are based on how they are connected to the branch device
>>     tree. For example, if a connector named DP-2 has a branch
>>     device attached and a DisplayPort device is connected to the
>>     branch device's first downstream port, a display device named
>>     DP-2.1 might be created. If another branch device is
>>     connected between the first branch device and the display
>>     device, the name might be DP-2.1.1.
>>
>>     To avoid cluttering the output list, DisplayPort 1.2 devices
>>     can be deleted when they are no longer connected and are not
>>     named in any MetaModes. This behavior can be enabled with the
>>     DeleteUnusedDP12Displays option.
>>
>> http://us.download.nvidia.com/XFree86/Linux-x86/337.19/README/displaydevicenames.html
>
> I'm unclear how you name non-DP branch devices. Do they show up as
> DP-2.1-HDMI or something similar? Or do you just keep the DP-2.1 name but
> set the connector type to HDMI?
>
> In general I think your prosoal of adding branch downstream ports to name
> MST connectors sounds really good. The kms object ids will still be
> random, but at least if users connect the same topology to the same ports
> we should have stable names.
>
> And of course userspace can still check the EDID serial.

I'm going to just add a property with the path and the userspace
driver can reconstruct a name from that
property, seems like the best plan,

Also for non-DP outputs, you don't know what they are, at least on
dock I have I can tell if I have
a legacy or a DP device plugged in to a port, but nothing else about
it. When nothing is plugged in
the port isn't connected.

So on the dock there is a VGA port, HDMI and DP shared, DVI-D and DP
shared, I see 3 ports
in the MST protocol, until something gets plugged in to something I
get no more info.

Dave.