Hi Hans, On Sat, Mar 04, 2017 at 11:57:32AM +0100, Hans Verkuil wrote: ... > >>+To simplify their implementation, drivers may also require buffers to be > >>+reallocated in order to change formats or controls that influence the buffer > >>+size. In that case, to perform such changes, userspace applications shall > >>+first stop the video stream with the :c:func:`VIDIOC_STREAMOFF` ioctl if it > >>+is running and free all buffers with the :c:func:`VIDIOC_REQBUFS` ioctl if > >>+they are allocated. The format or controls can then be modified, and buffers > >>+shall then be reallocated and the stream restarted. A typical ioctl sequence > >>+is > >>+ > >>+ #. VIDIOC_STREAMOFF > >>+ #. VIDIOC_REQBUFS(0) > >>+ #. VIDIOC_S_FMT > >>+ #. VIDIOC_S_EXT_CTRLS > > > >Same here. > > > >Would it be safe to say that controls are changed first? I wonder if there > >could be special cases where this wouldn't apply though. It could ultimately > >come down to hardware features: rotation might be only available for certain > >formats so you'd need to change the format first to enable rotation. > > > >What you're documenting above is a typical sequence so it doesn't have to be > >applicable to all potential hardware. I might mention there could be such > >dependencies. I wonder if one exists at the moment. No? > > The way V4L2 works is that the last ioctl called gets 'preference'. So the > driver should attempt to satisfy the ioctl, even if that means undoing previous > ioctls. In other words, V4L2 allows any order, but the end-result might be > different depending on the hardware capabilities. Indeed. But the above sequence suggests that formats are set before controls. I suggested to clarify that part. -- Regards, Sakari Ailus e-mail: sakari.ailus@xxxxxx XMPP: sailus@xxxxxxxxxxxxxx
