On 20 April 2016 at 03:27, Jonathan Gray <j...@jsg.id.au> wrote: > On Tue, Apr 19, 2016 at 07:00:18PM +0100, Emil Velikov wrote: >> On 19 April 2016 at 04:03, Jonathan Gray <j...@jsg.id.au> wrote: >> > Any objections to this? >> > >> Absolutely none. I simply missed it. >> >> > On Mon, Dec 21, 2015 at 04:39:55PM +1100, Jonathan Gray wrote: >> >> Use dev_node_from_fd() with HAVE_LIBDRM to provide an implmentation >> >> of loader_get_device_name_for_fd() for non-linux systems that >> >> use libdrm but don't have udev or sysfs. >> >> >> >> Signed-off-by: Jonathan Gray <j...@jsg.id.au> >> Reviewed-by: Emil Velikov <emil.veli...@collabora.com> >> >> Jonathan, apart from the patches that I've replied to (and the llvm >> one in a second) do you have any more, even if they're >> nasty/subjective/etc. ? Please send them over and ping me/us is >> there's no reply within a week or so. > > Well some are things like disabling drirc so we can sandbox the chromium > process with a GL context which aren't really suitable. > Ahh yes - drirc workaround might not be applicable. Although others such as the "LLVM requirement and r300" (as described in another thread) are good. So please do send the lot and don't get (too) annoyed if some things get bikeshed(ed) to death. Hopefully that won't happen but you never know.
>> >> On the topic of the loader I hope you managed to take a look at the >> libdrm drmDevice API. It does (almost) the same thing as the below >> patch, but my goal is to keep it separate so that one can reuse it >> from other places, plus we can re-spin a libdrm release as often >> and/fast as we need to. In other words - most/all of this nasty code >> will get moved from mesa to libdrm. Note current libdrm implementation >> is Linux only. Please throw in a patch when you can spare some time. > > From a quick look: > > drmGetMinorNameForFD / /dev path matching fd > drm_get_device_name_for_fd from mesa > drmParseSubsystemType / return fixed int for bus > always return DRM_BUS_PCI > drmParsePciDeviceInfo / get pci vendorid/deviceid and subids > drm_get_pci_id_for_fd from mesa > > drmParsePciBusInfo / get pci domain/bus/dev/func from only major/minor > > libpciaccess wouldn't work here, I suspect this would need a new drm > ioctl. Would it be possible to somehow reserve an ioctl number on the > linux side that linux wouldn't need to use? Surely you have some way to get such (somewhat trivial) information from another userspace, right ? Pretty much anyone can/should be able to query the 'hardware location' of a device - aka lspci style. You guys must have that one. Adding (DRM specific) IOCTLS is definitely not what we want here. If any of the split and/or implementation does not work for you guys, feel free to scrap it and plug your own version. Related: Who is responsible for creating the card/render/control/etc nodes as the hardware is detected (system goes up) ? Is it really libdrm or you guys have a some method (daemon?) that manages these kind of things. Why ? I'm really inclined on nuking the mknod and friends from libdrm. Hopefully in the near future. Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
