On Sat, Jun 22, 2019 at 11:42 AM Simon Ser contact@emersion.fr wrote:
On Wednesday, June 19, 2019 10:53 PM, Daniel Vetter daniel@ffwll.ch wrote:
tldr; Yes, I just didn't get around to it yet.
The rough plan is to actually document ioctls and properties and all that stuff in drm-uapi.rst, and then cross-link that with the driver-side documentation.
I'm confused regarding drm-uapi.rst's role. Is it a document for kernel driver writers to expand the uAPI, or is it a document for userspace?
It's currently filled with references to internal kernel symbols (drm_master_get, drm_ioctl_desc, drm_ioctl_permit and so on). Some chapters seem dedicated to kernel devs (e.g. "Testing and validation").
Is it really the right place for userspace devs to learn how to use KMS?
There's more to drm than kms, but yeah I think currently that's the best starting point we have for documenting the uapi. We might also need to separate some of the more kernel-internal bits into other chapters, e.g. ioctl and master stuff is currently there because those are fairly important concept from a drm uapi pov. But maybe we should pull out the implementation details into some other place.
Given that 0 of our ioctls and ioctl structures are currently documented, I'm not really worried about those issues just yet :-) -Daniel