On 21 June 2018 at 16:32, Jonathan Gray <jsg@xxxxxxxxx> wrote:
> On Thu, Jun 21, 2018 at 03:24:49PM +0100, Emil Velikov wrote:
>> Hi Jonathan,
>>
>> On 1 December 2016 at 04:18, Jonathan Gray <jsg@xxxxxxxxx> wrote:
>>
>> > --- a/xf86drm.c
>> > +++ b/xf86drm.c
>> > @@ -3248,6 +3248,67 @@ drm_device_validate_flags(uint32_t flags)
>> > */
>> > int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr *device)
>> > {
>> > +#ifdef __OpenBSD__
>> > + /*
>> > + * DRI device nodes on OpenBSD are not in their own directory, they reside
>> > + * in /dev along with a large number of statically generated /dev nodes.
>> > + * Avoid stat'ing all of /dev needlessly by implementing this custom path.
>> > + */
>> I was in the area, fixing the odd bug and doing some cleanups and a
>> question came to mind:
>>
>> Is there some obstacle of placing the drm nodes under /dev/dri/? It
>> would involve a check/update through the OpenBSD tree, yet no obvious
>> downsides comes to mind.
>> I think it would make things more distinct and obvious. IIRC the
>> OpenBSD xserver does some checking which /dev node opened, the
>> suggestion should help there.
>>
>> What do you think?
>> Emil
>
> There are no other devices under a sub-directory besides /dev/fd/.
> I don't think anyone is going to be onboard with changing things for
> drm nodes. Though drm device nodes names will have to be revisted
> when/if render nodes etc get supported. drmR drmC etc have not
> been proposed yet.
I see, that's enlighening.
Out of curiosity: personally, do you see any technical issues with a
sub-directory approach?
Thanks
Emil
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
