On 6 December 2016 at 05:12, Jonathan Gray <jsg@xxxxxxxxx> wrote: > On Mon, Dec 05, 2016 at 05:56:40PM +0000, Emil Velikov wrote: >> On 1 December 2016 at 04:18, Jonathan Gray <jsg@xxxxxxxxx> wrote: >> > DRI devices on OpenBSD are not in their own directory. They reside in >> > /dev with a large number of statically generated /dev nodes. >> > >> > Avoid stat'ing all of /dev on OpenBSD by implementing this custom path. >> > >> > v2: >> > - use drmGetMinorType to get node type >> > - adapt to drmProcessPciDevice changes >> > - verify drmParseSubsystemType type is PCI >> > - add a comment describing why this was added >> > >> Thanks for the update Jonathan. >> >> I've pulled v2 in master, >> Emil > > Thanks, going over what went in I see drmGetMinorNameForFD and > the OpenBSD drmGetDevice2 paths need to be adjusted to have the correct > minor for the control/render nodes. > > ie > > base = drmGetMinorBase(type); > if (min < base) > return error; > > min -= base; > > I'll send another patch for this. > > And the common code could be split into a shared function? > I don't have a strong preference either way, bth. > drmGetDeviceNameFromFd2 would do the same thing as > drmGetDeviceNameFromFd on OpenBSD as far as I can tell so that could be > another shared function instead of the current "missing implementation" > warning. Or should drmGetDeviceNameFromFd purposefully not handle > render/control nodes? drmGetDeviceNameFromFd has historically handled only card nodes, so I'd keep that as-is. The "2" should handle any node imaginable. Please, spin the patches when you can and give the OpenBSD implementations a test. I'd like to get those in for the next release - in the next week or so. This way we can use the less annoying drmGetDevice[s]2 in Mesa :-) Thanks Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
