[Mesa-dev] [PATCH libdrm v2 5/5] xf86drm: implement an OpenBSD specific drmGetDevice2

[Emil Velikov]

On 6 December 2016 at 05:12, Jonathan Gray <jsg at 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 at 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