On Sat, Sep 8, 2018 at 5:17 AM Ezequiel Garcia <ezequiel@xxxxxxxxxxxxx> wrote: > > On Tue, 2018-07-24 at 23:06 +0900, Tomasz Figa wrote: [snip] > > +Querying capabilities > > +===================== > > + > > +1. To enumerate the set of coded formats supported by the driver, the > > + client may call :c:func:`VIDIOC_ENUM_FMT` on ``CAPTURE``. > > + > > + * The driver must always return the full set of supported formats, > > + irrespective of the format set on the ``OUTPUT`` queue. > > + > > +2. To enumerate the set of supported raw formats, the client may call > > + :c:func:`VIDIOC_ENUM_FMT` on ``OUTPUT``. > > + > > + * The driver must return only the formats supported for the format > > + currently active on ``CAPTURE``. > > + > > Paul and I where discussing about the default active format on CAPTURE > and OUTPUT queues. That is, the format that is active (if any) right > after driver probes. > > Currently, the v4l2-compliance tool tests the default active format, > by requiring drivers to support: > > fmt = g_fmt() > s_fmt(fmt) > > Is this actually required? Should we also require this for stateful > and stateless codecs? If yes, should it be documented? The general V4L2 principle is that drivers must maintain some sane default state right from when they are exposed to the userspace. I'd try to stick to the common V4L2 semantics, unless there is a very good reason not to do so. Note that we actually diverged from it on CAPTURE state for stateful decoders, because we return an error, if any format-related ioctl is called on CAPTURE queue before OUTPUT queue is initialized with a valid coded format, either explicitly by the client or implicitly via bitstream parsing. The reason was backwards compatibility with clients which don't handle source change events. If that wasn't the case, we could have made the CAPTURE queue completely independent and have the format there reset with source change event, whenever it becomes invalid due to things like resolution change or speculative initialization miss, which would make things much more symmetrical. Best regards, Tomasz
