All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.