From: Pekka Paalanen <ppaalanen@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org,
Ilia Mirkin <imirkin@alum.mit.edu>,
dri-devel@lists.freedesktop.org
Subject: Re: [RFC][PATCH 0/2] drm: PATH prop for all connectors?
Date: Thu, 27 Jun 2019 10:35:47 +0300 [thread overview]
Message-ID: <20190627103547.67cd8868@eldfell.localdomain> (raw)
In-Reply-To: <20190613204208.GR23020@phenom.ffwll.local>
[-- Attachment #1.1: Type: text/plain, Size: 2395 bytes --]
On Thu, 13 Jun 2019 22:42:08 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Jun 13, 2019 at 09:43:33PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Here's a possible apporoach for providing userspace with
> > some stable connector identifiers. Combine with the bus
> > name of the GPU and you should have some kind of real
> > physical path description. Unfortunately the ship has
> > sailed for MST connectors because userspace is already
> > parsing the property and expects to find certain things
> > there. So if we want stable names for those we'd probably
> > have introduce another PATH prop (PHYS_PATH?).
> >
> > I suppose one alternative would to make the connector
> > type_id stable. Currently that is being populated by drm
> > core and it's just a global counter. Not sure how badly
> > things would turn out if we'd allow each driver to set
> > that. It could result in conflicting xrandr connector
> > names between different GPUs which I suppose would
> > confuse existing userspace?
>
> I think the only reason this global id stuff exists is because with
> original xrandr, that stuff was global. And then it got copypasted
> forever.
>
> Would need to do a bunch of reviewing, but I'd expect we'll get away with
> just making all these allocators per-device.
Hi,
I'm not sure I'm that optimistic... I assume most userspace uses type_id
for naming already and might rely on uniqueness. Weston uses type_id,
but does not rely on uniqueness yet, since it only handles one device
so far.
The bigger problem to me however is changing the meaning of type_id,
causing old kernels do one thing and new kernels do another thing. When
userspace uses type_id for connector naming, it may use that name in
configuration files. Weston does, but again is not affected because it
doesn't support using multiple devices yet. If someone has two gfx
cards in his machine, making type_id per-device changes the numbering,
meaning the user's configuration does not apply anymore or applies
wrong. I suppose it doesn't matter if the naming was already
unreliable, since it is reliable if the drivers/devices happened to
probe in the same order every boot.
Are connector names in xrandr still using type_id in their names? That
would be a sure blocker, I think.
Thanks,
pq
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-06-27 7:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-13 18:43 [RFC][PATCH 0/2] drm: PATH prop for all connectors? Ville Syrjala
2019-06-13 18:43 ` [RFC][PATCH 1/2] drm: Improve PATH prop docs Ville Syrjala
2019-06-27 7:36 ` Pekka Paalanen
2019-06-13 18:43 ` [RFC][PATCH 2/2] drm/i915: Populate PATH prop for every connector Ville Syrjala
2019-06-27 7:37 ` Pekka Paalanen
2019-06-13 18:50 ` ✗ Fi.CI.CHECKPATCH: warning for drm: PATH prop for all connectors? Patchwork
2019-06-13 20:42 ` [RFC][PATCH 0/2] " Daniel Vetter
2019-06-27 7:35 ` Pekka Paalanen [this message]
2019-06-27 7:44 ` Michel Dänzer
2019-06-14 11:38 ` ✓ Fi.CI.BAT: success for " Patchwork
2019-06-15 8:26 ` ✓ Fi.CI.IGT: " Patchwork
2019-07-10 22:43 ` [Intel-gfx] [RFC][PATCH 0/2] " Lyude Paul
2019-07-11 7:20 ` Daniel Vetter
[not found] ` <20190711102923.3d219640@eldfell.localdomain>
2019-07-16 14:59 ` [Intel-gfx] " Li, Sun peng (Leo)
2019-08-01 9:51 ` Pekka Paalanen
2019-08-01 18:24 ` Li, Sun peng (Leo)
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=20190627103547.67cd8868@eldfell.localdomain \
--to=ppaalanen@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=imirkin@alum.mit.edu \
--cc=intel-gfx@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