Hi Tomi, On Fri, 18 Jan 2019 at 08:29, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > > On 18/01/19 00:04, Rob Herring wrote: > > > Mesa/libdrm already has lots of code to open the correct devices and > > not care about minor numbers. What's the problem here? > > Well, maybe the problem is that I don't know how to do this =). > > So, if we have multiple DRM devices, how does one manage those? > Iterating over them and looking for kms-capable ones is easy enough. But > if there are multiple kms-capable ones, how should the userspace choose > between those? > > I see that udev creates /dev/dri/by-path/ links to the cards, should the > userspace use those to have a persistent link to the card? E.g. first > time the app is ran, it'll collect all the kms-capable cards, and store > the by-path names somewhere, and in subsequent runs it will instead use > the by-path names to keep the order the same. > > If I have a product with two display controllers, and one of them has > the main display connected, how does my custom app know which card to > use? Hardcoding the by-path in the app? > > If udev/systemd is not available, how does the userspace do this? I > tried to see if one can get enough information from the card device with > ioctls to figure these things out, but I didn't figure this out. Should > the drmGetBusid() return something for platform devices too? Maybe I've > got something missing from the display driver, and drmGetBusid() should > return something similar as what is in the by-path name. > Have you looked at the libdrm drmDevice2 (yes use the second version) API? It provides various information about the different devices, yet if it's missing anything do send us a patch ;-) It was introduced explicitly w/o depending on udev/systemd, since they are not always available. On the topic of drmGetBusid() - I would stay away from it, since it's more or less a legacy artefact. HTH Emil
