dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Aaron Plattner <aplattner@nvidia.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [RFC] drm + i915 DP MST code preview
Date: Wed, 7 May 2014 09:46:19 -0700	[thread overview]
Message-ID: <536A635B.2050909@nvidia.com> (raw)
In-Reply-To: <20140507080734.GR5730@phenom.ffwll.local>

On 05/07/2014 01:07 AM, Daniel Vetter 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@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?

I don't have any branches that support passive adapters on downstream 
ports, so I'm not sure what happens with those.

> 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.

Yeah, the RandR output XIDs work the same way.

> And of course userspace can still check the EDID serial.
> -Daniel

  reply	other threads:[~2014-05-07 16:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-02  4:39 [RFC] drm + i915 DP MST code preview Dave Airlie
2014-05-02  4:39 ` [PATCH 1/8] drm/dp_helper: add defines for DP 1.2 and MST support Dave Airlie
2014-05-02  4:39 ` [PATCH 2/8] drm: add DP MST encoder type Dave Airlie
2014-05-02  4:39 ` [PATCH 3/8] drm/i915: add some registers need for displayport MST support Dave Airlie
2014-05-02  4:39 ` [PATCH 4/8] drm/crtc: add interface to reinitialise the legacy mode group Dave Airlie
2014-05-02  4:39 ` [PATCH 5/8] drm/helper: add Displayport multi-stream helper Dave Airlie
2014-05-02  4:39 ` [PATCH 6/8] i915: split some DP modesetting code into a separate function Dave Airlie
2014-05-02  4:39 ` [PATCH 7/8] drm/i915: check connector->encoder before using it Dave Airlie
2014-05-02  4:39 ` [PATCH 8/8] i915: add DP 1.2 MST support (v0.1) Dave Airlie
2014-05-02  4:51 ` [RFC] drm + i915 DP MST code preview Dave Airlie
2014-05-02  8:52 ` Chris Wilson
2014-05-02 21:08   ` Dave Airlie
2014-05-03  9:00     ` Chris Wilson
2014-05-07  7:16       ` Aaron Plattner
2014-05-07  8:07         ` Daniel Vetter
2014-05-07 16:46           ` Aaron Plattner [this message]
2014-05-07 22:24           ` Dave Airlie
2014-05-08  1:56             ` Dave Airlie
2014-05-08  7:24               ` Chris Wilson
2014-05-08  7:32                 ` Dave Airlie
2014-05-07  9:00         ` Dave Airlie
2014-05-07 16:42           ` Aaron Plattner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=536A635B.2050909@nvidia.com \
    --to=aplattner@nvidia.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox