On Fri, 26 Jan 2024 10:30:10 +0000 "Albert, Joerg (TT-U)" <Joerg.Albert@xxxxxx> 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:
pgpm46rksH_Zr.pgp
Description: OpenPGP digital signature
