From: Pekka Paalanen <pekka.paalanen@haloniitty.fi>
To: "Albert, Joerg (TT-U)" <Joerg.Albert@iav.de>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: drm: Stable identification of connectors?
Date: Fri, 26 Jan 2024 15:32:31 +0200 [thread overview]
Message-ID: <20240126153231.6fd1a7f2@eldfell> (raw)
In-Reply-To: <4c03efeca8ce42beb41b2f70433e6634@iav.de>
[-- Attachment #1: Type: text/plain, Size: 3001 bytes --]
On Fri, 26 Jan 2024 10:30:10 +0000
"Albert, Joerg (TT-U)" <Joerg.Albert@iav.de> wrote:
> Hi,
>
>
> I’m pretty new to DRM/DRI and wonder if there is a way to have a
> stable identification of connectors across changes in the Linux
> kernel and/or in the devicetree?
>
> Our hardware contains an iMX8QM with two displays, each one connected
> to a MIPI-DSI channel. We use kernel 6.1.38. In the output of
> “modetest -c” the connectors are called LVDS-1 and LVDS-2. These
> names are built in modetest.c from connector_type and
> connector_type_id.
>
> connector_type_id is set in the kernel in
> drivers/gpu/drm/drm_connector.c in __drm_connector_init():
>
>
> connector<https://elixir.bootlin.com/linux/latest/C/ident/connector>->connector_type_id<https://elixir.bootlin.com/linux/latest/C/ident/connector_type_id>
> =
>
> ida_alloc_min<https://elixir.bootlin.com/linux/latest/C/ident/ida_alloc_min>(connector_ida<https://elixir.bootlin.com/linux/latest/C/ident/connector_ida>,
> 1,
> GFP_KERNEL<https://elixir.bootlin.com/linux/latest/C/ident/GFP_KERNEL>);
>
> Seems to me that this number depends on initialization order only. Is
> there any other way to identify a connector?
>
> If not, will the type_id be stable as long as we don’t change the
> kernel version and the device tree?
Hi,
the question of persistent connector and DRM device names (paths) comes
up every once in a while. Here is one take:
https://lists.freedesktop.org/archives/dri-devel/2019-June/221902.html
Yes, connector_type_id numbering depends on driver and connector
initialization order. Usually it has been a problem only for systems
with multiple display driver instances racing to initialize their
connectors.
One idea was to use the connector index in the KMS resources array UAPI
as a persistent device-private id. This does not work for MST and other
dynamically appearing and disappearing connectors though, and ISTR it
had some other problem too. It could be stable as long as a driver
registers its permanent connectors always in the same order.
There is the connector "PATH" property, but so far that only exists on
MST connectors, and I recall some doubts whether the current
implementation of even that was truly persistent.
In general, I believe the persistent naming of connectors is an
unsolved problem. Persistent naming of DRM devices at least has a
tentative solution as "device path", by e.g. PCI topology. I think that
breaks down if you happen to have multiple platform DRM KMS devices.
To me it seems some kind of "hardware path" would be the only truly
persistent device and connector naming scheme, assuming the hardware
remains the same.
I'd guess many desktops circumvent the problem by not identifying
connectors but displays based on their EDID serial number or hash.
Naturally that does not work always, either, EDID can lack a serial, be
identical, or not exist.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-01-26 14:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AdpQQouNfGqYf3uSSdGt8uzEBuaRnw==>
2024-01-26 10:30 ` drm: Stable identification of connectors? Albert, Joerg (TT-U)
2024-01-26 13:32 ` Pekka Paalanen [this message]
2024-01-26 14:18 ` Dave Stevenson
2024-01-26 15:07 ` Pekka Paalanen
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=20240126153231.6fd1a7f2@eldfell \
--to=pekka.paalanen@haloniitty.fi \
--cc=Joerg.Albert@iav.de \
--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.