Re: [Intel-gfx] [RFC][PATCH 0/2] drm: PATH prop for all connectors?
On 2019-08-01 5:51 a.m., Pekka Paalanen wrote: > On Tue, 16 Jul 2019 14:59:58 + > "Li, Sun peng (Leo)" wrote: > >> On 2019-07-11 3:29 a.m., Pekka Paalanen wrote: >>> Wait, one can write udev rules for connectors and stuff? >>> How? What can they do? >> >> I was using it to generate user-friendly device names for the mst aux >> implementation: >> https://patchwork.freedesktop.org/patch/315900/?series=63237=2 > > Hi, > > what is that device node used for? > > Are the "by-path" symlinks to help a display server associate the > right device node with the right DRM KMS connector resource? I intended it to be something more descriptive than the '/dev/drm_dp_aux0, drm_dp_aux1, drm_dp_aux2, ...' names, to help users identify the connector they're addressing in the mst topology. I guess it could also be used for the purpose you mention as well. Of course, we'd need more reliable and persistent PATH props first. The patch was dropped until this happens. Leo > > The patch commit message did not explain what the names are > actually used for. > > > Thanks, > pq > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC][PATCH 0/2] drm: PATH prop for all connectors?
On Tue, 16 Jul 2019 14:59:58 + "Li, Sun peng (Leo)" wrote: > On 2019-07-11 3:29 a.m., Pekka Paalanen wrote: > > Wait, one can write udev rules for connectors and stuff? > > How? What can they do? > > I was using it to generate user-friendly device names for the mst aux > implementation: > https://patchwork.freedesktop.org/patch/315900/?series=63237=2 Hi, what is that device node used for? Are the "by-path" symlinks to help a display server associate the right device node with the right DRM KMS connector resource? The patch commit message did not explain what the names are actually used for. Thanks, pq pgpMRCp39eQQ1.pgp Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC][PATCH 0/2] drm: PATH prop for all connectors?
On 2019-07-11 3:29 a.m., Pekka Paalanen wrote: > Wait, one can write udev rules for connectors and stuff? > How? What can they do? I was using it to generate user-friendly device names for the mst aux implementation: https://patchwork.freedesktop.org/patch/315900/?series=63237=2 Leo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC][PATCH 0/2] drm: PATH prop for all connectors?
On Wed, 10 Jul 2019 18:43:53 -0400
Lyude Paul wrote:
> (adding sunpeng...@amd.com to the thread here, since this is relevant to the
> DP
> aux device work)
>
> I mentioned this in IRC, but figured I should mention it on the ML as well so
> it
> can be discussed further. Honestly: I don't like the way we implement the path
> prop for MST. Mainly because
>
> * It looks ugly: mst:-- is ambiguous looking. I
> didn't
>even realize the first number was actually supposed to be the object ID
> until
>I looked at the code
> * I strongly doubt object IDs are consistent enough for the path prop to
>actually be as meaningful as it looks
> *
> Obviously we can't just remove the path property, since it's being used in
> userspace. This has me somewhat convinced that I think it might be a better
> idea
> to just make a whole new path_v2 prop, and document that the path prop was a
> bad
> idea and is now deprecated (but still functional). If we did this, we could
> come
> up with a much nicer MST naming scheme as well! Consider:
>
> For a connector with the RAD 0.1 living on the topology on DP-1 on card0:
>
> mst:DP-1:0.1
>
> I see multiple benefits to this:
> * Look how easy it is to read!
> * DP-1 isn't guaranteed to be consistent, but it is certainly far more likely
>to be consistent than an object ID.
Hi,
please, do not go with "more consistent but not fully". If the name is
not all the way persistent, then it's useless because it will break
things in rare cases. We already have a 80% or a 95% solutions, adding
one more <100% solution does not help.
> * This seems a lot easier to write udev rules for, imho
Wait, one can write udev rules for connectors and stuff?
How? What can they do?
> The only thing I'm not sure about whether or not we should also prepend the
> connector name with the device (e.g. card0, card1, etc.). I thought this might
> be necessary at first, but thinking about it - it shouldn't be hard to figure
> out the device in question from looking at sysfs since any userspace
> application
> will know which DRM fd the connector comes from.
From a display server perspective using the libdrm KMS API, yes, we
always know from which device a connector comes from, and can make up a
persistent name for the device ("card0" is not a persistent name).
Thanks,
pq
>
> Does this sound like a good idea? If so, I'd be happy to write up some patches
> for this
>
> On Thu, 2019-06-13 at 21:43 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > 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?
> >
> > Cc: Daniel Vetter
> > Cc: Pekka Paalanen
> > Cc: Ilia Mirkin
> >
> > Ville Syrjälä (2):
> > drm: Improve PATH prop docs
> > drm/i915: Populate PATH prop for every connector
> >
> > drivers/gpu/drm/drm_connector.c| 13 --
> > drivers/gpu/drm/i915/icl_dsi.c | 3 +++
> > drivers/gpu/drm/i915/intel_connector.c | 20 +++
> > drivers/gpu/drm/i915/intel_connector.h | 3 +++
> > drivers/gpu/drm/i915/intel_crt.c | 2 ++
> > drivers/gpu/drm/i915/intel_dp.c| 6 -
> > drivers/gpu/drm/i915/intel_dp_mst.c| 3 +--
> > drivers/gpu/drm/i915/intel_dvo.c | 3 +++
> > drivers/gpu/drm/i915/intel_hdmi.c | 4 +++
> > drivers/gpu/drm/i915/intel_lvds.c | 2 ++
> > drivers/gpu/drm/i915/intel_sdvo.c | 35 ++
> > drivers/gpu/drm/i915/intel_tv.c| 2 ++
> > drivers/gpu/drm/i915/vlv_dsi.c | 3 +++
> > 13 files changed, 83 insertions(+), 16 deletions(-)
> >
>
pgpUQQMOLuWRf.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC][PATCH 0/2] drm: PATH prop for all connectors?
On Wed, Jul 10, 2019 at 06:43:53PM -0400, Lyude Paul wrote: > (adding sunpeng...@amd.com to the thread here, since this is relevant to the > DP > aux device work) > > I mentioned this in IRC, but figured I should mention it on the ML as well so > it > can be discussed further. Honestly: I don't like the way we implement the path > prop for MST. Mainly because > > * It looks ugly: mst:-- is ambiguous looking. I > didn't >even realize the first number was actually supposed to be the object ID > until >I looked at the code > * I strongly doubt object IDs are consistent enough for the path prop to >actually be as meaningful as it looks > * > Obviously we can't just remove the path property, since it's being used in > userspace. This has me somewhat convinced that I think it might be a better > idea > to just make a whole new path_v2 prop, and document that the path prop was a > bad > idea and is now deprecated (but still functional). If we did this, we could > come > up with a much nicer MST naming scheme as well! Consider: > > For a connector with the RAD 0.1 living on the topology on DP-1 on card0: > > mst:DP-1:0.1 > > I see multiple benefits to this: > * Look how easy it is to read! > * DP-1 isn't guaranteed to be consistent, but it is certainly far more likely >to be consistent than an object ID. > * This seems a lot easier to write udev rules for, imho We just had an epic discussion on irc about how connector names are _also_ not stable. At least not if you have more than drm_device (they're allocated from a global idr, because lolz and it's apparently uapi, xrandr will die if they're not globally unique). So actually worse than the object id, which at least on a given machine, and for any driver not doing something real funny with undefined load ordering, should be stable. So maybe not so stable for soc drivers with lots of EPROBE_DEFER. > The only thing I'm not sure about whether or not we should also prepend the > connector name with the device (e.g. card0, card1, etc.). I thought this might > be necessary at first, but thinking about it - it shouldn't be hard to figure > out the device in question from looking at sysfs since any userspace > application > will know which DRM fd the connector comes from. > > Does this sound like a good idea? If so, I'd be happy to write up some patches > for this Stable naming is offiically hard. I think the most reasonable approach, and the one every DE implements, is to look at the serial/vendor in edid and just assume that cables/connectors/cards are fungible. Anyway I'm not sure how useful any of this is ... There's also the hilarity that on older i915 cards, there's both hdmi and dp "connectors" for DP++ ports. -Daniel > > On Thu, 2019-06-13 at 21:43 +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > 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? > > > > Cc: Daniel Vetter > > Cc: Pekka Paalanen > > Cc: Ilia Mirkin > > > > Ville Syrjälä (2): > > drm: Improve PATH prop docs > > drm/i915: Populate PATH prop for every connector > > > > drivers/gpu/drm/drm_connector.c| 13 -- > > drivers/gpu/drm/i915/icl_dsi.c | 3 +++ > > drivers/gpu/drm/i915/intel_connector.c | 20 +++ > > drivers/gpu/drm/i915/intel_connector.h | 3 +++ > > drivers/gpu/drm/i915/intel_crt.c | 2 ++ > > drivers/gpu/drm/i915/intel_dp.c| 6 - > > drivers/gpu/drm/i915/intel_dp_mst.c| 3 +-- > > drivers/gpu/drm/i915/intel_dvo.c | 3 +++ > > drivers/gpu/drm/i915/intel_hdmi.c | 4 +++ > > drivers/gpu/drm/i915/intel_lvds.c | 2 ++ > > drivers/gpu/drm/i915/intel_sdvo.c | 35 ++ > > drivers/gpu/drm/i915/intel_tv.c| 2 ++ > > drivers/gpu/drm/i915/vlv_dsi.c | 3 +++ > > 13 files changed, 83 insertions(+), 16 deletions(-) > > > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx
Re: [Intel-gfx] [RFC][PATCH 0/2] drm: PATH prop for all connectors?
(adding sunpeng...@amd.com to the thread here, since this is relevant to the DP aux device work) I mentioned this in IRC, but figured I should mention it on the ML as well so it can be discussed further. Honestly: I don't like the way we implement the path prop for MST. Mainly because * It looks ugly: mst:-- is ambiguous looking. I didn't even realize the first number was actually supposed to be the object ID until I looked at the code * I strongly doubt object IDs are consistent enough for the path prop to actually be as meaningful as it looks * Obviously we can't just remove the path property, since it's being used in userspace. This has me somewhat convinced that I think it might be a better idea to just make a whole new path_v2 prop, and document that the path prop was a bad idea and is now deprecated (but still functional). If we did this, we could come up with a much nicer MST naming scheme as well! Consider: For a connector with the RAD 0.1 living on the topology on DP-1 on card0: mst:DP-1:0.1 I see multiple benefits to this: * Look how easy it is to read! * DP-1 isn't guaranteed to be consistent, but it is certainly far more likely to be consistent than an object ID. * This seems a lot easier to write udev rules for, imho The only thing I'm not sure about whether or not we should also prepend the connector name with the device (e.g. card0, card1, etc.). I thought this might be necessary at first, but thinking about it - it shouldn't be hard to figure out the device in question from looking at sysfs since any userspace application will know which DRM fd the connector comes from. Does this sound like a good idea? If so, I'd be happy to write up some patches for this On Thu, 2019-06-13 at 21:43 +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > 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? > > Cc: Daniel Vetter > Cc: Pekka Paalanen > Cc: Ilia Mirkin > > Ville Syrjälä (2): > drm: Improve PATH prop docs > drm/i915: Populate PATH prop for every connector > > drivers/gpu/drm/drm_connector.c| 13 -- > drivers/gpu/drm/i915/icl_dsi.c | 3 +++ > drivers/gpu/drm/i915/intel_connector.c | 20 +++ > drivers/gpu/drm/i915/intel_connector.h | 3 +++ > drivers/gpu/drm/i915/intel_crt.c | 2 ++ > drivers/gpu/drm/i915/intel_dp.c| 6 - > drivers/gpu/drm/i915/intel_dp_mst.c| 3 +-- > drivers/gpu/drm/i915/intel_dvo.c | 3 +++ > drivers/gpu/drm/i915/intel_hdmi.c | 4 +++ > drivers/gpu/drm/i915/intel_lvds.c | 2 ++ > drivers/gpu/drm/i915/intel_sdvo.c | 35 ++ > drivers/gpu/drm/i915/intel_tv.c| 2 ++ > drivers/gpu/drm/i915/vlv_dsi.c | 3 +++ > 13 files changed, 83 insertions(+), 16 deletions(-) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC][PATCH 0/2] drm: PATH prop for all connectors?
On 2019-06-27 9:35 a.m., Pekka Paalanen wrote: > > Are connector names in xrandr still using type_id in their names? Yes, they are. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC][PATCH 0/2] drm: PATH prop for all connectors?
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älä > > > > 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 pgp1BW_Qjos31.pgp Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC][PATCH 0/2] drm: PATH prop for all connectors?
On Thu, Jun 13, 2019 at 09:43:33PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > 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. -Daniel > > Cc: Daniel Vetter > Cc: Pekka Paalanen > Cc: Ilia Mirkin > > Ville Syrjälä (2): > drm: Improve PATH prop docs > drm/i915: Populate PATH prop for every connector > > drivers/gpu/drm/drm_connector.c| 13 -- > drivers/gpu/drm/i915/icl_dsi.c | 3 +++ > drivers/gpu/drm/i915/intel_connector.c | 20 +++ > drivers/gpu/drm/i915/intel_connector.h | 3 +++ > drivers/gpu/drm/i915/intel_crt.c | 2 ++ > drivers/gpu/drm/i915/intel_dp.c| 6 - > drivers/gpu/drm/i915/intel_dp_mst.c| 3 +-- > drivers/gpu/drm/i915/intel_dvo.c | 3 +++ > drivers/gpu/drm/i915/intel_hdmi.c | 4 +++ > drivers/gpu/drm/i915/intel_lvds.c | 2 ++ > drivers/gpu/drm/i915/intel_sdvo.c | 35 ++ > drivers/gpu/drm/i915/intel_tv.c| 2 ++ > drivers/gpu/drm/i915/vlv_dsi.c | 3 +++ > 13 files changed, 83 insertions(+), 16 deletions(-) > > -- > 2.21.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC][PATCH 0/2] drm: PATH prop for all connectors?
From: Ville Syrjälä 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? Cc: Daniel Vetter Cc: Pekka Paalanen Cc: Ilia Mirkin Ville Syrjälä (2): drm: Improve PATH prop docs drm/i915: Populate PATH prop for every connector drivers/gpu/drm/drm_connector.c| 13 -- drivers/gpu/drm/i915/icl_dsi.c | 3 +++ drivers/gpu/drm/i915/intel_connector.c | 20 +++ drivers/gpu/drm/i915/intel_connector.h | 3 +++ drivers/gpu/drm/i915/intel_crt.c | 2 ++ drivers/gpu/drm/i915/intel_dp.c| 6 - drivers/gpu/drm/i915/intel_dp_mst.c| 3 +-- drivers/gpu/drm/i915/intel_dvo.c | 3 +++ drivers/gpu/drm/i915/intel_hdmi.c | 4 +++ drivers/gpu/drm/i915/intel_lvds.c | 2 ++ drivers/gpu/drm/i915/intel_sdvo.c | 35 ++ drivers/gpu/drm/i915/intel_tv.c| 2 ++ drivers/gpu/drm/i915/vlv_dsi.c | 3 +++ 13 files changed, 83 insertions(+), 16 deletions(-) -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
