I'm searching for some sort of scheme that will let my DRI master query the set of available connectors and select the one carrying a prearranged designation. The problem I'm trying to solve is to allow deploying one standardized userspace component across a fleet of devices that have varying numbers of displays, with the use cases not always driven on the same connector topologically.
I had a look around the properties available on my system's DRI connectors, and nothing immediate jumped out at me. Is there a standard connector property that (assuming I can find the right place in DeviceTree or similar to) that would be a good fit for this?
-Matt
On Wednesday, April 1, 2020 9:38 PM, Matt Hoosier matt.hoosier@gmail.com wrote:
I'm searching for some sort of scheme that will let my DRI master query the set of available connectors and select the one carrying a prearranged designation. The problem I'm trying to solve is to allow deploying one standardized userspace component across a fleet of devices that have varying numbers of displays, with the use cases not always driven on the same connector topologically.
I had a look around the properties available on my system's DRI connectors, and nothing immediate jumped out at me. Is there a standard connector property that (assuming I can find the right place in DeviceTree or similar to) that would be a good fit for this?
Maybe information in the EDID would help? You'll find the manufacturer, the model number and the serial number.
On Wed, Apr 1, 2020 at 3:17 PM Simon Ser contact@emersion.fr wrote:
On Wednesday, April 1, 2020 9:38 PM, Matt Hoosier matt.hoosier@gmail.com wrote:
I'm searching for some sort of scheme that will let my DRI master query
the set of available connectors and select the one carrying a prearranged designation. The problem I'm trying to solve is to allow deploying one standardized userspace component across a fleet of devices that have varying numbers of displays, with the use cases not always driven on the same connector topologically.
I had a look around the properties available on my system's DRI
connectors, and nothing immediate jumped out at me. Is there a standard connector property that (assuming I can find the right place in DeviceTree or similar to) that would be a good fit for this?
Maybe information in the EDID would help? You'll find the manufacturer, the model number and the serial number.
That might be a possibility. The trouble there is that there can be more than one instance of the same display model connected to the system, so the EDID blob wouldn't be particularly helpful to distinguish them. The connectors in question are generally something like LVDS or DSI that don't typically expose EDID properties, too.
On Wed, 1 Apr 2020 14:38:37 -0500 Matt Hoosier matt.hoosier@gmail.com wrote:
I'm searching for some sort of scheme that will let my DRI master query the set of available connectors and select the one carrying a prearranged designation. The problem I'm trying to solve is to allow deploying one standardized userspace component across a fleet of devices that have varying numbers of displays, with the use cases not always driven on the same connector topologically.
I had a look around the properties available on my system's DRI connectors, and nothing immediate jumped out at me. Is there a standard connector property that (assuming I can find the right place in DeviceTree or similar to) that would be a good fit for this?
Hi,
I've never heard of a thing that could accomplish that. DRM connector names are not even actually communicated to userspace. What userspace sees is connector type (enum) and some counter numbers (which are not persistent, so not reliable if you have e.g. multiple DRM drivers racing to initialize), and then userspace manufactures a connector name from those. This has been most painful with Xorg, where the different video DDX drivers used to use different conventions in making up the names, meaning that if you switched DDXes (e.g. between driver-specific driver and modesetting driver), the connector names changed invalidating your xorg.conf.
However, the problem of non-persistent connector names has been thought of, see e.g.: https://lists.freedesktop.org/archives/dri-devel/2019-June/221902.html The thread has messages also in July and August.
If you had reliable, persistent connector names (and used e.g. device path from udev to reliably identify DRM devices), maybe you could build something on top of that?
Though I doubt if maintainers would like your config to be in DT or kernel, maybe it needs to be handled in userspace?
Thanks, pq
Hi Pekka,
El vie., 3 abr. 2020 a las 10:14, Pekka Paalanen (ppaalanen@gmail.com) escribió:
On Wed, 1 Apr 2020 14:38:37 -0500 Matt Hoosier matt.hoosier@gmail.com wrote:
I'm searching for some sort of scheme that will let my DRI master query the set of available connectors and select the one carrying a prearranged designation. The problem I'm trying to solve is to allow deploying one standardized userspace component across a fleet of devices that have varying numbers of displays, with the use cases not always driven on the same connector topologically.
I had a look around the properties available on my system's DRI connectors, and nothing immediate jumped out at me. Is there a standard connector property that (assuming I can find the right place in DeviceTree or similar to) that would be a good fit for this?
Hi,
I've never heard of a thing that could accomplish that. DRM connector names are not even actually communicated to userspace. What userspace sees is connector type (enum) and some counter numbers (which are not persistent, so not reliable if you have e.g. multiple DRM drivers racing to initialize),
I may be misreading you, but does this mean that the connector names used in the [output] section of the weston.ini configuration file are not reliable? Then what is the proper way to configure one specific (physical) output in Weston?
BR,
Guillermo
and then userspace manufactures a connector name from those. This has been most painful with Xorg, where the different video DDX drivers used to use different conventions in making up the names, meaning that if you switched DDXes (e.g. between driver-specific driver and modesetting driver), the connector names changed invalidating your xorg.conf.
However, the problem of non-persistent connector names has been thought of, see e.g.: https://lists.freedesktop.org/archives/dri-devel/2019-June/221902.html The thread has messages also in July and August.
If you had reliable, persistent connector names (and used e.g. device path from udev to reliably identify DRM devices), maybe you could build something on top of that?
Though I doubt if maintainers would like your config to be in DT or kernel, maybe it needs to be handled in userspace?
Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Fri, 3 Apr 2020 10:28:52 +0200 Guillermo Rodriguez guillerodriguez.dev@gmail.com wrote:
Hi Pekka,
El vie., 3 abr. 2020 a las 10:14, Pekka Paalanen (ppaalanen@gmail.com) escribió:
On Wed, 1 Apr 2020 14:38:37 -0500 Matt Hoosier matt.hoosier@gmail.com wrote:
I'm searching for some sort of scheme that will let my DRI master query the set of available connectors and select the one carrying a prearranged designation. The problem I'm trying to solve is to allow deploying one standardized userspace component across a fleet of devices that have varying numbers of displays, with the use cases not always driven on the same connector topologically.
I had a look around the properties available on my system's DRI connectors, and nothing immediate jumped out at me. Is there a standard connector property that (assuming I can find the right place in DeviceTree or similar to) that would be a good fit for this?
Hi,
I've never heard of a thing that could accomplish that. DRM connector names are not even actually communicated to userspace. What userspace sees is connector type (enum) and some counter numbers (which are not persistent, so not reliable if you have e.g. multiple DRM drivers racing to initialize),
I may be misreading you, but does this mean that the connector names used in the [output] section of the weston.ini configuration file are not reliable?
Yes, they are not generally reliable. They are reliable enough in most cases, particularly if you have only one DRM device with connectors. DRM drivers themselves often manage to not race internally, so they are fairly consistent in what order they create their connectors per device.
Xorg has the exact same problem IIRC, as has probably any display server on Linux. This means that to find a case where the reliability actually breaks down you have to try quite hard or be very unlucky, since it has gone unfixed for so long.
Likewise you cannot rely that /dev/dri/card0 is always the same device if you have multiple. That issue is showing up a little more than the connector naming issue. Hence /dev/dri/by-path/ aliases exist. Network devices have hit the same naming problem a long time ago already, hence we nowadays have "Predictable Network Interface Names".
Then what is the proper way to configure one specific (physical) output in Weston?
There is no better way yet. I've had some ideas, but no time to look into them.
MST connectors have a KMS property for the hardware path, but Weston does not look at that, and the other connectors don't even have it.
Thanks, pq
Hi Pekka,
El vie., 3 abr. 2020 a las 12:03, Pekka Paalanen (ppaalanen@gmail.com) escribió:
On Fri, 3 Apr 2020 10:28:52 +0200 Guillermo Rodriguez guillerodriguez.dev@gmail.com wrote:
Hi Pekka,
El vie., 3 abr. 2020 a las 10:14, Pekka Paalanen (ppaalanen@gmail.com) escribió:
On Wed, 1 Apr 2020 14:38:37 -0500 Matt Hoosier matt.hoosier@gmail.com wrote:
I'm searching for some sort of scheme that will let my DRI master query the set of available connectors and select the one carrying a prearranged designation. The problem I'm trying to solve is to allow deploying one standardized userspace component across a fleet of devices that have varying numbers of displays, with the use cases not always driven on the same connector topologically.
I had a look around the properties available on my system's DRI connectors, and nothing immediate jumped out at me. Is there a standard connector property that (assuming I can find the right place in DeviceTree or similar to) that would be a good fit for this?
Hi,
I've never heard of a thing that could accomplish that. DRM connector names are not even actually communicated to userspace. What userspace sees is connector type (enum) and some counter numbers (which are not persistent, so not reliable if you have e.g. multiple DRM drivers racing to initialize),
I may be misreading you, but does this mean that the connector names used in the [output] section of the weston.ini configuration file are not reliable?
Yes, they are not generally reliable. They are reliable enough in most cases, particularly if you have only one DRM device with connectors. DRM drivers themselves often manage to not race internally, so they are fairly consistent in what order they create their connectors per device.
Xorg has the exact same problem IIRC, as has probably any display server on Linux. This means that to find a case where the reliability actually breaks down you have to try quite hard or be very unlucky, since it has gone unfixed for so long.
Likewise you cannot rely that /dev/dri/card0 is always the same device if you have multiple. That issue is showing up a little more than the connector naming issue. Hence /dev/dri/by-path/ aliases exist. Network devices have hit the same naming problem a long time ago already, hence we nowadays have "Predictable Network Interface Names".
Then what is the proper way to configure one specific (physical) output in Weston?
There is no better way yet. I've had some ideas, but no time to look into them.
MST connectors have a KMS property for the hardware path, but Weston does not look at that, and the other connectors don't even have it.
Ok so this is a known "problem" which has never been fixed, probably because in most cases (single DRM device) the current solution is good enough.
Thank you for the clarification.
BR,
Guillermo Rodriguez Garcia guille.rodriguez@gmail.com
dri-devel@lists.freedesktop.org
-
Guillermo Rodriguez -
Matt Hoosier -
Pekka Paalanen -
Simon Ser