Laurent raised a few API issues/questions in his review of the documentation.
I've consolidated those in this RFC. I would like to know what others think
and if I should make changes.
1) Should you be allowed to set controls directly if they are also used in
requests? Right now this is allowed, although we warn in the spec that
this can lead to undefined behavior.
In my experience being able to do this is very useful while testing,
and restricting this is not all that easy to implement. I also think it is
not our job. It is not as if something will break when you do this.
If there really is a good reason why you can't mix this for a specific
control, then the driver can check this and return -EBUSY.
2) If request_fd in QBUF or the control ioctls is not a request fd, then we
now return ENOENT. Laurent suggests using EBADR ('Invalid request descriptor')
instead. This seems like a good idea to me. Should I change this?
3) Calling VIDIOC_G_EXT_CTRLS for a request that has not been queued yet will
return either the value of the control you set earlier in the request, or
the current HW control value if it was never set in the request.
I believe it makes sense to return what was set in the request previously
(if you set it, you should be able to get it), but it is an idea to return
ENOENT when calling this for controls that are NOT in the request.
I'm inclined to implement that. Opinions?
4) When queueing a buffer to a request with VIDIOC_QBUF you set V4L2_BUF_FLAG_REQUEST_FD
to indicate a valid request_fd. For other queue ioctls that take a struct v4l2_buffer
this flag and the request_fd field are just ignored. Should we return EINVAL
instead if the flag is set for those ioctls?
The argument for just ignoring it is that older kernels that do not know about
this flag will ignore it as well. There is no check against unknown flags.
Regards,
Hans
