On 6 December 2016 at 05:12, Jonathan Gray jsg@jsg.id.au wrote:
On Mon, Dec 05, 2016 at 05:56:40PM +0000, Emil Velikov wrote:
On 1 December 2016 at 04:18, Jonathan Gray jsg@jsg.id.au 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