[RFC] drm: Start documenting userspace ABI

[Laurent Pinchart]

On Wednesday 19 November 2014 14:23:47 Daniel Vetter wrote:
> On Tue, Nov 18, 2014 at 04:24:39PM +0100, Thierry Reding wrote:
> > On Tue, Nov 18, 2014 at 04:05:08PM +0100, David Herrmann wrote:
> > > On Tue, Nov 18, 2014 at 3:43 PM, Thierry Reding wrote:
> > > > On Tue, Nov 18, 2014 at 03:27:27PM +0100, Daniel Vetter wrote:
> > > >> On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote:
> > > >> > From: Thierry Reding 
> > > >> > 
> > > >> > After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented
> > > >> > with different semantics on different drivers it seems like a good
> > > >> > idea to start to more rigorously document userspace ABI to avoid
> > > >> > these things in the future.
> > > >> > 
> > > >> > This is a first draft of what such documentation could look like.
> > > >> > Not all IOCTLs are documented and some explanation about the other
> > > >> > system calls (mmap(), poll(), read(), ...) would be good too. But I
> > > >> > wanted to send this out for early review to see if the direction is
> > > >> > reasonable. If so my plan is to continue to chip away at this as I
> > > >> > find time.
> > > >> > 
> > > >> > Signed-off-by: Thierry Reding 
> > > >> 
> > > >> Imo for ioctls the right thing to do is having proper manpages, not
> > > >> kerneldoc or DocBook sections. manpages really lend themselves well
> > > >> to specify all the different facets of a single interface.
> > > > 
> > > > I don't think I've ever seen manpages document IOCTLs at this level of
> > > > detail. The intention of this is to add documentation about the IOCTLs
> > > > at the kernel/userspace transition. Keeping this in the kernel has the
> > > > advantage that it's a whole lot easier to keep updated, much like what
> > > > we do with the other kerneldoc.
> > > > 
> > > > That doesn't mean we shouldn't have manpages, but I think both are for
> > > > the most part orthogonal, even though they may describe various facets
> > > > of the same interfaces.
> > > 
> > > tty_ioctl(4)
> > > console_ioctl(4)
> > > 
> > > I think a similar man-page ala drm_ioctl(4) makes a lot of sense.

The DRM API is much more complex, I think it deserves one page per ioctl.

> > > >> Also, we already have some skeleton of that in libdrm, so I think
> > > >> extending that would be best.
> > > > 
> > > > One other reason why I don't think libdrm is the best fit for this is
> > > > that libdrm is just one userspace implementation abstracting away the
> > > > interfaces that this describes. Not everyone will use libdrm. So in my
> > > > opinion its great if libdrm documents the API that it exposes, but I
> > > > don't think it should document the kernel interfaces that it uses. The
> > > > kernel exposes them, so it should provide the documentation for it as
> > > > well.
> > > 
> > > I don't mind documenting this in the kernel-doc. But if we start
> > > something like drm_ioctl(4) (I pushed some more generic man-pages to
> > > libdrm a few years ago), we have this documented in 2 places, which is
> > > always annoying for updates.
> > 
> > I wonder if it would somehow be possible to generate manpages from the
> > DocBook to avoid this duplication.

I'm pretty sure that should be possible. DocBook has appropriate markup to 
document functions in a manpage-like manner, see 
http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html for instance.

> > One of the things that DRM_IOCTL_MODE_CREATE_DUMB showed is that both
> > drivers and userspace can interpret things wrongly, and I fear that if all
> > we have is a manpage to document the IOCTLs, people writing the drivers
> > may not be tempted enough to read that manpage. So I think we want
> > documentation for both driver and userspace developers.
> 
> Imo docs don't help with that kind of fumble, only nasty testcases will.
> People only read docs when they don't understand stuff (i.e. trying to
> write drivers). Imo manpages an ioctl docs are only really good for
> designing the interface (since it forces you to really think through the
> semantics to be able to describe them concisely and precisely). But even
> there I think having solid testcases is better invested time.
> 
> Documentation for developers is imo an entirely different matter, I think
> that gets used a lot more. Or at least I find them fairly useful.

I think both are useful. From my personal experience proper detailed ioctl 
documentation helps a lots when writing kernel drivers. Even in the case of 
the DRM subsystem where various helper functions push the driver away from the 
ioctl API, proper documentation of the structures passed by userspace is very 
helpful for driver developers.  Not to mention of course that the 
documentation helps getting the helpers right.

Test cases are also invaluable. I've seen both test cases being used to fix 
drivers and documentation, clarifying the API as they get developed. 
Implementing a test case is a very good way to test the maturity of an API.

> > Documenting 

[RFC] drm: Start documenting userspace ABI

[Daniel Vetter]

On Tue, Nov 18, 2014 at 04:24:39PM +0100, Thierry Reding wrote:
> On Tue, Nov 18, 2014 at 04:05:08PM +0100, David Herrmann wrote:
> > Hi
> > 
> > On Tue, Nov 18, 2014 at 3:43 PM, Thierry Reding
> >  wrote:
> > > On Tue, Nov 18, 2014 at 03:27:27PM +0100, Daniel Vetter wrote:
> > >> On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote:
> > >> > From: Thierry Reding 
> > >> >
> > >> > After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
> > >> > different semantics on different drivers it seems like a good idea to
> > >> > start to more rigorously document userspace ABI to avoid these things
> > >> > in the future.
> > >> >
> > >> > This is a first draft of what such documentation could look like. Not
> > >> > all IOCTLs are documented and some explanation about the other system
> > >> > calls (mmap(), poll(), read(), ...) would be good too. But I wanted to
> > >> > send this out for early review to see if the direction is reasonable.
> > >> > If so my plan is to continue to chip away at this as I find time.
> > >> >
> > >> > Signed-off-by: Thierry Reding 
> > >>
> > >> Imo for ioctls the right thing to do is having proper manpages, not
> > >> kerneldoc or DocBook sections. manpages really lend themselves well to
> > >> specify all the different facets of a single interface.
> > >
> > > I don't think I've ever seen manpages document IOCTLs at this level of
> > > detail. The intention of this is to add documentation about the IOCTLs
> > > at the kernel/userspace transition. Keeping this in the kernel has the
> > > advantage that it's a whole lot easier to keep updated, much like what
> > > we do with the other kerneldoc.
> > >
> > > That doesn't mean we shouldn't have manpages, but I think both are for
> > > the most part orthogonal, even though they may describe various facets
> > > of the same interfaces.
> > 
> > tty_ioctl(4)
> > console_ioctl(4)
> > 
> > I think a similar man-page ala drm_ioctl(4) makes a lot of sense.
> > 
> > >> Also, we already have some skeleton of that in libdrm, so I think
> > >> extending that would be best.
> > >
> > > One other reason why I don't think libdrm is the best fit for this is
> > > that libdrm is just one userspace implementation abstracting away the
> > > interfaces that this describes. Not everyone will use libdrm. So in my
> > > opinion its great if libdrm documents the API that it exposes, but I
> > > don't think it should document the kernel interfaces that it uses. The
> > > kernel exposes them, so it should provide the documentation for it as
> > > well.
> > 
> > I don't mind documenting this in the kernel-doc. But if we start
> > something like drm_ioctl(4) (I pushed some more generic man-pages to
> > libdrm a few years ago), we have this documented in 2 places, which is
> > always annoying for updates.
> 
> I wonder if it would somehow be possible to generate manpages from the
> DocBook to avoid this duplication. One of the things that
> DRM_IOCTL_MODE_CREATE_DUMB showed is that both drivers and userspace can
> interpret things wrongly, and I fear that if all we have is a manpage to
> document the IOCTLs, people writing the drivers may not be tempted
> enough to read that manpage. So I think we want documentation for both
> driver and userspace developers.

Imo docs don't help with that kind of fumble, only nasty testcases will.
People only read docs when they don't understand stuff (i.e. trying to
write drivers). Imo manpages an ioctl docs are only really good for
designing the interface (since it forces you to really think through the
semantics to be able to describe them concisely and precisely). But even
there I think having solid testcases is better invested time.

Documentation for developers is imo an entirely different matter, I think
that gets used a lot more. Or at least I find them fairly useful.

> Documenting this within the kernel is also pretty easy. I know that I'll
> be much more tempted to do it within the kernel than if I have to switch
> to some other repository, build system and whatnot.
> 
> Perhaps in this case having two places where it's documented isn't all
> that bad. It's ABI after all, so the documentation never needs to
> change. Theoretically.
> 
> > And even if people don't use libdrm, I think it's totally acceptable
> > to ship man-pages with libdrm. Distributions are free to provide
> > drm-man-pages as stand-alone package (which is _really_ easy to
> > generate from libdrm).
> 
> I guess one other home for these could be the man-pages project on
> kernel.org. It's what carries most (all?) of the Linux kernel-specific
> man-pages (like the tty_ioctl and console_ioctl ones that you referred
> to).

There has been talks about merging the linux manpages back into the kernel
actually. But yeah that seems like a good home, especially since Micheal
Kerrisk seems pretty sharp with reviewing manpages.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[RFC] drm: Start documenting userspace ABI

[Thierry Reding]

On Tue, Nov 18, 2014 at 04:05:08PM +0100, David Herrmann wrote:
> Hi
> 
> On Tue, Nov 18, 2014 at 3:43 PM, Thierry Reding
>  wrote:
> > On Tue, Nov 18, 2014 at 03:27:27PM +0100, Daniel Vetter wrote:
> >> On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote:
> >> > From: Thierry Reding 
> >> >
> >> > After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
> >> > different semantics on different drivers it seems like a good idea to
> >> > start to more rigorously document userspace ABI to avoid these things
> >> > in the future.
> >> >
> >> > This is a first draft of what such documentation could look like. Not
> >> > all IOCTLs are documented and some explanation about the other system
> >> > calls (mmap(), poll(), read(), ...) would be good too. But I wanted to
> >> > send this out for early review to see if the direction is reasonable.
> >> > If so my plan is to continue to chip away at this as I find time.
> >> >
> >> > Signed-off-by: Thierry Reding 
> >>
> >> Imo for ioctls the right thing to do is having proper manpages, not
> >> kerneldoc or DocBook sections. manpages really lend themselves well to
> >> specify all the different facets of a single interface.
> >
> > I don't think I've ever seen manpages document IOCTLs at this level of
> > detail. The intention of this is to add documentation about the IOCTLs
> > at the kernel/userspace transition. Keeping this in the kernel has the
> > advantage that it's a whole lot easier to keep updated, much like what
> > we do with the other kerneldoc.
> >
> > That doesn't mean we shouldn't have manpages, but I think both are for
> > the most part orthogonal, even though they may describe various facets
> > of the same interfaces.
> 
> tty_ioctl(4)
> console_ioctl(4)
> 
> I think a similar man-page ala drm_ioctl(4) makes a lot of sense.
> 
> >> Also, we already have some skeleton of that in libdrm, so I think
> >> extending that would be best.
> >
> > One other reason why I don't think libdrm is the best fit for this is
> > that libdrm is just one userspace implementation abstracting away the
> > interfaces that this describes. Not everyone will use libdrm. So in my
> > opinion its great if libdrm documents the API that it exposes, but I
> > don't think it should document the kernel interfaces that it uses. The
> > kernel exposes them, so it should provide the documentation for it as
> > well.
> 
> I don't mind documenting this in the kernel-doc. But if we start
> something like drm_ioctl(4) (I pushed some more generic man-pages to
> libdrm a few years ago), we have this documented in 2 places, which is
> always annoying for updates.

I wonder if it would somehow be possible to generate manpages from the
DocBook to avoid this duplication. One of the things that
DRM_IOCTL_MODE_CREATE_DUMB showed is that both drivers and userspace can
interpret things wrongly, and I fear that if all we have is a manpage to
document the IOCTLs, people writing the drivers may not be tempted
enough to read that manpage. So I think we want documentation for both
driver and userspace developers.

Documenting this within the kernel is also pretty easy. I know that I'll
be much more tempted to do it within the kernel than if I have to switch
to some other repository, build system and whatnot.

Perhaps in this case having two places where it's documented isn't all
that bad. It's ABI after all, so the documentation never needs to
change. Theoretically.

> And even if people don't use libdrm, I think it's totally acceptable
> to ship man-pages with libdrm. Distributions are free to provide
> drm-man-pages as stand-alone package (which is _really_ easy to
> generate from libdrm).

I guess one other home for these could be the man-pages project on
kernel.org. It's what carries most (all?) of the Linux kernel-specific
man-pages (like the tty_ioctl and console_ioctl ones that you referred
to).

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

[RFC] drm: Start documenting userspace ABI

[David Herrmann]

Hi

On Tue, Nov 18, 2014 at 3:43 PM, Thierry Reding
 wrote:
> On Tue, Nov 18, 2014 at 03:27:27PM +0100, Daniel Vetter wrote:
>> On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote:
>> > From: Thierry Reding 
>> >
>> > After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
>> > different semantics on different drivers it seems like a good idea to
>> > start to more rigorously document userspace ABI to avoid these things
>> > in the future.
>> >
>> > This is a first draft of what such documentation could look like. Not
>> > all IOCTLs are documented and some explanation about the other system
>> > calls (mmap(), poll(), read(), ...) would be good too. But I wanted to
>> > send this out for early review to see if the direction is reasonable.
>> > If so my plan is to continue to chip away at this as I find time.
>> >
>> > Signed-off-by: Thierry Reding 
>>
>> Imo for ioctls the right thing to do is having proper manpages, not
>> kerneldoc or DocBook sections. manpages really lend themselves well to
>> specify all the different facets of a single interface.
>
> I don't think I've ever seen manpages document IOCTLs at this level of
> detail. The intention of this is to add documentation about the IOCTLs
> at the kernel/userspace transition. Keeping this in the kernel has the
> advantage that it's a whole lot easier to keep updated, much like what
> we do with the other kerneldoc.
>
> That doesn't mean we shouldn't have manpages, but I think both are for
> the most part orthogonal, even though they may describe various facets
> of the same interfaces.

tty_ioctl(4)
console_ioctl(4)

I think a similar man-page ala drm_ioctl(4) makes a lot of sense.

>> Also, we already have some skeleton of that in libdrm, so I think
>> extending that would be best.
>
> One other reason why I don't think libdrm is the best fit for this is
> that libdrm is just one userspace implementation abstracting away the
> interfaces that this describes. Not everyone will use libdrm. So in my
> opinion its great if libdrm documents the API that it exposes, but I
> don't think it should document the kernel interfaces that it uses. The
> kernel exposes them, so it should provide the documentation for it as
> well.

I don't mind documenting this in the kernel-doc. But if we start
something like drm_ioctl(4) (I pushed some more generic man-pages to
libdrm a few years ago), we have this documented in 2 places, which is
always annoying for updates.

And even if people don't use libdrm, I think it's totally acceptable
to ship man-pages with libdrm. Distributions are free to provide
drm-man-pages as stand-alone package (which is _really_ easy to
generate from libdrm).

Thanks
David

[RFC] drm: Start documenting userspace ABI

[Thierry Reding]

On Tue, Nov 18, 2014 at 03:27:27PM +0100, Daniel Vetter wrote:
> On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
> > different semantics on different drivers it seems like a good idea to
> > start to more rigorously document userspace ABI to avoid these things
> > in the future.
> > 
> > This is a first draft of what such documentation could look like. Not
> > all IOCTLs are documented and some explanation about the other system
> > calls (mmap(), poll(), read(), ...) would be good too. But I wanted to
> > send this out for early review to see if the direction is reasonable.
> > If so my plan is to continue to chip away at this as I find time.
> > 
> > Signed-off-by: Thierry Reding 
> 
> Imo for ioctls the right thing to do is having proper manpages, not
> kerneldoc or DocBook sections. manpages really lend themselves well to
> specify all the different facets of a single interface.

I don't think I've ever seen manpages document IOCTLs at this level of
detail. The intention of this is to add documentation about the IOCTLs
at the kernel/userspace transition. Keeping this in the kernel has the
advantage that it's a whole lot easier to keep updated, much like what
we do with the other kerneldoc.

That doesn't mean we shouldn't have manpages, but I think both are for
the most part orthogonal, even though they may describe various facets
of the same interfaces.

> Also, we already have some skeleton of that in libdrm, so I think
> extending that would be best.

One other reason why I don't think libdrm is the best fit for this is
that libdrm is just one userspace implementation abstracting away the
interfaces that this describes. Not everyone will use libdrm. So in my
opinion its great if libdrm documents the API that it exposes, but I
don't think it should document the kernel interfaces that it uses. The
kernel exposes them, so it should provide the documentation for it as
well.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

[RFC] drm: Start documenting userspace ABI

[Daniel Vetter]

On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
> different semantics on different drivers it seems like a good idea to
> start to more rigorously document userspace ABI to avoid these things
> in the future.
> 
> This is a first draft of what such documentation could look like. Not
> all IOCTLs are documented and some explanation about the other system
> calls (mmap(), poll(), read(), ...) would be good too. But I wanted to
> send this out for early review to see if the direction is reasonable.
> If so my plan is to continue to chip away at this as I find time.
> 
> Signed-off-by: Thierry Reding 

Imo for ioctls the right thing to do is having proper manpages, not
kerneldoc or DocBook sections. manpages really lend themselves well to
specify all the different facets of a single interface.

Also, we already have some skeleton of that in libdrm, so I think
extending that would be best.
-Daniel

> ---
>  Documentation/DocBook/drm.tmpl | 700 
> -
>  include/uapi/drm/drm.h |  95 --
>  2 files changed, 773 insertions(+), 22 deletions(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index ffe0d9b41826..bc125c043032 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -3831,8 +3831,706 @@ int num_ioctls;
>  
>
>  
> +
> +  DRM Userspace ABI
> +  
> +
> +  This third part of the DRM Developer's Guide documents userspace
> +  interfaces. DRM devices can be accessed using standard file operations
> +  such as open(), close(), ioctl() or mmap(). How these translate to the
> +  DRM drivers is explained in the following chapters.
> +
> +
> +  For driver-specific userspace interfaces (buffer allocation and
> +  management, command stream submission, ...) refer to the 
> driver-specific
> +  sections in .
> +
> +  
> +  
> +DRM IOCTLs
> +
> +  A number of IOCTLs can be performed on a DRM device node. Many of them
> +  are generic and apply to all devices, others are considered legacy and
> +  should no longer be used in new userspace applications.
> +
> +
> +  Identification
> +  
> +DRM_IOCTL_VERSION - query driver name and version
> +
> +  After opening a DRM device, userspace applications will typically
> +  want to identify the driver bound to the device. They can use this
> +  IOCTL to obtain information about the driver in the form of a
> +  drm_version structure.
> +
> +!Finclude/uapi/drm/drm.h drm_version
> +
> +  Returns 0 on success or one of the following error codes on
> +  failure:
> +
> +
> +  
> +EFAULT
> +
> +  
> +If data cannot be copied to any of the
> +name,
> +date or
> +desc fields.
> +  
> +
> +  
> +
> +  
> +  
> +DRM_IOCTL_GET_UNIQUE - get unique device name
> +
> +  Each device has a unique name associated with it. This is useful to
> +  differentiate between two devices driven by the same driver. Unique
> +  names of devices can be obtained with this IOCTL and the result is
> +  returned in a drm_unique structure.
> +
> +!Finclude/uapi/drm/drm.h drm_unique
> +
> +  Returns 0 on success or one of the following error codes on 
> failure:
> +
> +
> +  
> +EFAULT
> +
> +  
> +If the device's unique name cannot be copied to the
> +unique field.
> +  
> +
> +  
> +
> +  
> +  
> +DRM_IOCTL_SET_VERSION - request interface version
> +
> +  Request a specific interface or driver version. The values passed 
> in
> +  the drm_set_version structure are matched
> +  against the DRM interface and driver versions.
> +
> +!Finclude/uapi/drm/drm.h drm_set_version
> +
> +  Returns 0 on success or one of the following error codes on 
> failure:
> +
> +
> +  
> +EINVAL
> +
> +  
> +If the interface version in the kernel is incompatible with
> +that requested by the userspace application or if the driver
> +is not compatible with the version requested by the userspace
> +application.
> +  
> +
> +  
> +
> +  
> +  
> +DRM_IOCTL_GET_CAP - query device capabilities
> +
> +  DRM drivers vary in terms of which functionality that they support.
> +  Even within one driver, certain 

[RFC] drm: Start documenting userspace ABI

[Thierry Reding]

From: Thierry Reding 

After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
different semantics on different drivers it seems like a good idea to
start to more rigorously document userspace ABI to avoid these things
in the future.

This is a first draft of what such documentation could look like. Not
all IOCTLs are documented and some explanation about the other system
calls (mmap(), poll(), read(), ...) would be good too. But I wanted to
send this out for early review to see if the direction is reasonable.
If so my plan is to continue to chip away at this as I find time.

Signed-off-by: Thierry Reding 
---
 Documentation/DocBook/drm.tmpl | 700 -
 include/uapi/drm/drm.h |  95 --
 2 files changed, 773 insertions(+), 22 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index ffe0d9b41826..bc125c043032 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -3831,8 +3831,706 @@ int num_ioctls;

   
 
+
+  DRM Userspace ABI
+  
+
+  This third part of the DRM Developer's Guide documents userspace
+  interfaces. DRM devices can be accessed using standard file operations
+  such as open(), close(), ioctl() or mmap(). How these translate to the
+  DRM drivers is explained in the following chapters.
+
+
+  For driver-specific userspace interfaces (buffer allocation and
+  management, command stream submission, ...) refer to the driver-specific
+  sections in .
+
+  
+  
+DRM IOCTLs
+
+  A number of IOCTLs can be performed on a DRM device node. Many of them
+  are generic and apply to all devices, others are considered legacy and
+  should no longer be used in new userspace applications.
+
+
+  Identification
+  
+DRM_IOCTL_VERSION - query driver name and version
+
+  After opening a DRM device, userspace applications will typically
+  want to identify the driver bound to the device. They can use this
+  IOCTL to obtain information about the driver in the form of a
+  drm_version structure.
+
+!Finclude/uapi/drm/drm.h drm_version
+
+  Returns 0 on success or one of the following error codes on
+  failure:
+
+
+  
+EFAULT
+
+  
+If data cannot be copied to any of the
+name,
+date or
+desc fields.
+  
+
+  
+
+  
+  
+DRM_IOCTL_GET_UNIQUE - get unique device name
+
+  Each device has a unique name associated with it. This is useful to
+  differentiate between two devices driven by the same driver. Unique
+  names of devices can be obtained with this IOCTL and the result is
+  returned in a drm_unique structure.
+
+!Finclude/uapi/drm/drm.h drm_unique
+
+  Returns 0 on success or one of the following error codes on failure:
+
+
+  
+EFAULT
+
+  
+If the device's unique name cannot be copied to the
+unique field.
+  
+
+  
+
+  
+  
+DRM_IOCTL_SET_VERSION - request interface version
+
+  Request a specific interface or driver version. The values passed in
+  the drm_set_version structure are matched
+  against the DRM interface and driver versions.
+
+!Finclude/uapi/drm/drm.h drm_set_version
+
+  Returns 0 on success or one of the following error codes on failure:
+
+
+  
+EINVAL
+
+  
+If the interface version in the kernel is incompatible with
+that requested by the userspace application or if the driver
+is not compatible with the version requested by the userspace
+application.
+  
+
+  
+
+  
+  
+DRM_IOCTL_GET_CAP - query device capabilities
+
+  DRM drivers vary in terms of which functionality that they support.
+  Even within one driver, certain devices may not support the same
+  functionality as others. The DRM_IOCTL_GET_CAP
+  IOCTL can be used to query such capabilities at runtime.
+
+
+  The following is a list of available capabilities. Userspace
+  applications set the capability to one of
+  these before performing the IOCTL. The kernel returns the capability
+  value in the value field. Typically this
+  will be a boolean (0 or 1) value that denotes whether or not the
+  device supports the given capability. In other cases the returned
+  value is numerical and the