On Tue, Jun 26, 2018 at 11:38:20AM +0100, Emil Velikov wrote:
On 21 June 2018 at 16:32, Jonathan Gray jsg@jsg.id.au 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@jsg.id.au 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?
I get that you want a single path but it seems these functions were really designed assuming the approach was going to be a sub-directory.