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. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
