From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pekka Paalanen Subject: Re: [RFC][PATCH 0/2] drm: PATH prop for all connectors? Date: Thu, 27 Jun 2019 10:35:47 +0300 Message-ID: <20190627103547.67cd8868@eldfell.localdomain> References: <20190613184335.7970-1-ville.syrjala@linux.intel.com> <20190613204208.GR23020@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1524304225==" Return-path: In-Reply-To: <20190613204208.GR23020@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org, Ilia Mirkin , dri-devel@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============1524304225== Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/wGF4miNzbv/L0CFmuwxXMfZ"; protocol="application/pgp-signature" --Sig_/wGF4miNzbv/L0CFmuwxXMfZ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 13 Jun 2019 22:42:08 +0200 Daniel Vetter wrote: > On Thu, Jun 13, 2019 at 09:43:33PM +0300, Ville Syrjala wrote: > > From: Ville Syrj=C3=A4l=C3=A4 > >=20 > > 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?). > >=20 > > I suppose one alternative would to make the connector=20 > > type_id stable. Currently that is being populated by drm=20 > > 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? =20 >=20 > 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. >=20 > 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 --Sig_/wGF4miNzbv/L0CFmuwxXMfZ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAl0UcdMACgkQI1/ltBGq qqd0/Q//RlTC3ZUhYvLszKWH+MxGXbG1y917+H4YacqZBa1Dt+v4n5l87A0atOjD UnFqzvWJ3X/94NviRSOj1pQ4c82sCf8jXV49vaKlDLpU64PzRr6B/YJnTmcbL74T UdG97nYXU79Himl44OJdEjbHiaiGdbvA0+l45LIKZ6h8brTmkUNnMcpO3o6WQ+Yk Lsf9jvvz4wLfEotqbGdc5pbyHJz+vgRZfWIKuHHCCHgx2zjhdG+X1FK81gxXaA29 otDUD6/yY39zsW+ZESo3ZBFSlH9QNXq7eCNH36YlYqjXtXY0QJ7mZ56/FP0RgAap kHs/X8BBaEGL3dWY8YLKgIZKSSqU77SHWYhTbAhcaPSz07xSgXrWvfYyYev1EIbe K8BlP7Hf6K9G4rI6drOuwe5Ue9gD7ImCC0NGKiJPCAml1/nEDuJF5uIF+FyIXZeS +isIdPUjGzqGtM1TlqUr938odITyL2YrMITQjHBjy+LhFN2mamyA3aUX5ilYQXUB x8DRzvp1yrinakJgC3y8ya76+px2/qSoDDORkhrvzODod7gGWIlyDiePaCwxMY8M Ln8NFsUmuc+/MV8AbtHDSRVzwKTMQJCFc0vZNu6CdW70u1VXbi6bvDklZ7fErIhd u1IKHI3ghQooT1Nu3PJyKNdbzMwi3UU5zHD/insp4Cq6VWzOGAM= =QjzZ -----END PGP SIGNATURE----- --Sig_/wGF4miNzbv/L0CFmuwxXMfZ-- --===============1524304225== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4 --===============1524304225==--