Re: [RFC] drm + i915 DP MST code preview

[Aaron Plattner <aplattner@nvidia.com>]

On 05/07/2014 02:00 AM, Dave Airlie wrote:
> On 7 May 2014 17:16, Aaron Plattner <aplattner@nvidia.com> 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@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
>
> Is the cleaning up an option because it caused some problems?

> I'm seeing some gnome-settings-daemon, gnome-shell crash because the
> XIDs are gone away and they get X errors, just wondering if this is
> what you were seeing,

Yeah, this exactly.  RandR's timestamp mechanism doesn't help you avoid 
BadOutput errors, although we could probably extend the protocol to add 
that, if we decide it's necessary.

Since the topology-based IDs are relatively stable unless you get a 
whole pile of branch devices and swap them around in weird ways all day, 
it was easier to just leave them around.  They'll get reused if a device 
with that topology path ever comes back.

> Dave.