RFC: V4L2 API ambiguities

RFC: V4L2 API ambiguities

[Hans Verkuil]

Hi all!

As part of the 2012 Kernel Summit V4L2 workshop I will be discussing a bunch of
V4L2 ambiguities/improvements.

I've made a list of all the V4L2 issues and put them in two categories: issues
that I think are easy to resolve (within a few minutes at most), and those that
are harder.

If you think I put something in the easy category that you believe is actually
hard, then please let me know.

If you attend the workshop, then please read through this and think about it a
bit, particularly for the second category.

If something is unclear, or you think another topic should be added, then let me
know as well.

Regards,

	Hans


Easy:

1) Split off the control part from videodev2.h. Controls are almost 30% of
   videodev2.h. I think maintaining controls would be easier if they are moved
   to e.g. linux/v4l2-controls.h which is included by videodev2.h.

2) Currently there are three types of controls: standard controls, controls
   that are specific to a chipset (e.g. cx2341x, mfc51) and driver-specific
   controls. The controls of the first two types have well defined and unique
   IDs. For driver-specific controls however there are no clear rules.

   It all depends on one question: should driver-specific controls have a
   unique control ID as well, or can they overlap with other drivers?

   If the answer is that they should be unique as well, then all driver-specific
   controls will have to be defined in a single header so you can be certain
   that there is no overlap.

   If the answer is that they may overlap, then each driver can either define
   their controls inside their own driver, or in a driver-specific public header.

   In both cases a control ID range has to be defined for such controls, to
   ensure that they never clash with standard or chipset-specific control IDs.
   E.g. >= V4L2_CTRL_CLASS_XXX + 0x8000 (no overlap) or + 0xf000 (overlap
   allowed).

   My preference is to allow overlap.

3) What should VIDIOC_STREAMON/OFF do if the stream is already started/stopped?
   I believe they should do nothing and just return 0. The main reason for that
   is it can be useful if an application can just call VIDIOC_STREAMOFF without
   having to check whether streaming is in progress.

4) What should a driver return in TRY_FMT/S_FMT if the requested format is not
   supported (possible behaviours include returning the currently selected format
   or a default format).

   The spec says this: "Drivers should not return an error code unless the input
   is ambiguous", but it does not explain what constitutes an ambiguous input.
   Frankly, I can't think of any and in my opinion TRY/S_FMT should never return
   an error other than EINVAL (if the buffer type is unsupported) or EBUSY (for
   S_FMT if streaming is in progress).

   Returning an error for any other reason doesn't help the application since
   the app will have no way of knowing what to do next.

5) VIDIOC_QUERYCAP allows bus_info to be empty. Since the purpose of bus_info
   is to distinguish multiple identical devices this makes no sense. I propose
   to make the spec more strict and require that bus_info is always filled in
   with a unique string.

6) Deprecate V4L2_BUF_TYPE_PRIVATE. None of the kernel drivers use it, and I
   cannot see any good use-case for this. If some new type of buffer is needed,
   then that should be added instead of allowing someone to abuse this buffer
   type.

7) A driver that has both a video node and a vbi node (for example) that uses
   the same struct v4l2_ioctl_ops for both nodes will have to check in e.g.
   vidioc_g_fmt_vid_cap or vidioc_g_fmt_vbi_cap whether it is called from the
   correct node (video or vbi) and return an error if it isn't.

   That's an annoying test that can be done in the V4L2 core as well. Especially
   since few drivers actually test for that.

   Should such checks be added to the V4L2 core? And if so, should we add some
   additional VFL types? Currently we have GRABBER (video nodes), VBI, RADIO
   and SUBDEV. But if we want to do proper core checks, then we would also need
   OUTPUT, VBI_OUT and M2M.

8) Remove the experimental tag from the following old drivers:

	VIDEO_TLV320AIC23B
	USB_STKWEBCAM
	VIDEO_CX18
	VIDEO_CX18_ALSA
	VIDEO_ZORAN_AVS6EYES
	DVB_USB_AF9005
	MEDIA_TUNER_TEA5761

   Removing this tag from these drivers might be too soon, though:

	VIDEO_NOON010PC30
	VIDEO_OMAP3

9) What should VIDIOC_G_STD/DV_PRESET/DV_TIMINGS return if the current input
   or output does not support that particular timing approach? EINVAL? ENODATA?
   This is relevant for the case where a driver has multiple inputs/outputs
   where some are SDTV (and support the STD API) and others are HDTV (and
   support the DV_TIMINGS API).

   I propose ENODATA.

10) Proposal: add these defines:

#define V4L2_IN_CAP_TIMINGS V4L2_IN_CAP_CUSTOM_TIMINGS
#define V4L2_OUT_CAP_TIMINGS V4L2_OUT_CAP_CUSTOM_TIMINGS

Since DV_TIMINGS is now used for any HDTV timings and no longer just for
custom, non-standard timings, the word "CUSTOM" is no longer appropriate.

11) What should video output drivers do with the sequence and timestamp
    fields when they return a v4l2_buffer from VIDIOC_DQBUF?

    I think the spec is clear with respect to the timestamp:

    "The driver stores the time at which the first data byte was actually
     sent out in the timestamp field."

    For sequence the spec just says:

    "Set by the driver, counting the frames in the sequence."

    So I think that output drivers should indeed set both sequence and
    timestemp.

12) Make the argument of write-only ioctls const in v4l2-ioctls.h. This makes
    it obvious to drivers that they shouldn't change the contents of the input
    struct since it won't make it back to userspace. It also simplifies
    v4l2-ioctl.c since it can rely on the fact that after the ioctl call the
    contents of the struct hasn't changed. Right now the struct contents is
    logged (if debugging is on) before the ioctl call for write-only ioctls.


Hard(er):

1) What is the right/best way to set the timestamp? The spec says gettimeofday,
   but is it my understanding that ktime_get_ts is much more efficient.

   Some drivers are already using ktime_get_ts.

   Options:

   a) all drivers must comply to the spec and use gettimeofday
   b) we change the spec and all drivers must use the more efficient ktime_get_ts
   c) we add a buffer flag V4L2_BUF_FLAG_MONOTONIC to tell userspace that a
      monotonic clock like ktime_get_ts is used and all drivers that use
      ktime_get_ts should set that flag.

   If we go for c, then we should add a recommendation to use one or the other
   as the preferred timestamp for new drivers.

2) If a driver supports only formats with more than one plane, should
   V4L2_CAP_VIDEO_CAPTURE still be defined? And if a driver also supports
   single-plane formats in addition to >1 plane formats, should
   V4L2_CAP_VIDEO_CAPTURE be compulsary?

3) VIDIOC_CROPCAP: the spec says that CROPCAP must be implemented by all
   capture and output devices (Section "Image Cropping, Inserting and Scaling").
   In reality only a subset of the drivers support cropcap.

   Should cropcap really be compulsory? Or only for drivers that can scale? And
   in that case, should we make a default implementation for those drivers that
   do not support it? (E.g.: call g_fmt and use the width/height as the
   default and bounds rectangles, and set the pixel aspect to 1/1)

4) Pixel aspect: currently this is only available through VIDIOC_CROPCAP. It
   never really belonged to VIDIOC_CROPCAP IMHO. It's just not a property of
   cropping/composing. It really belongs to the input/output timings (STD or
   DV_TIMINGS). That's where the pixel aspect ratio is determined.

   While it is possible to add it to the dv_timings struct, I see no way of
   cleanly adding it to struct v4l2_standard (mostly because VIDIOC_ENUMSTD
   is now handled inside the V4L2 core and doesn't call the drivers anymore).

   An alternative is to add it to struct v4l2_input/output, but I don't know
   if it is possible to defined a pixelaspect for inputs that are not the
   current input.

   What I am thinking of is just to add a new ioctl for this VIDIOC_G_PIXELASPECT.
   The argument is then:

	struct v4l2_pixelaspect {
		__u32 type;
		struct v4l2_fract pixelaspect;
		__u32 reserved[5];
	};

   This combines well with the selection API.

5) How to handle tuner ownership if both a video and radio node share the same
   tuner?

   Obvious rules:

   - Calling S_FREQ, S_TUNER, S_MODULATOR or S_HW_FREQ_SEEK will change owner
     or return EBUSY if streaming is in progress.
   - Ditto for STREAMON, read/write and polling for read/write.
   - Ditto for ioctls that expect a valid tuner configuration like QUERYSTD.
   - Just opening a device node should *not* switch ownership.

   But it is not clear what to do when any of these ioctls are called:

   - G_FREQUENCY: could just return the last set frequency for radio or TV:
     requires that that is remembered when switching ownership. This is what
     happens today, so G_FREQUENCY does not have to switch ownership.
   - G_TUNER: the rxsubchans, signal and afc fields all require ownership of
     the tuner. So in principle you would want to switch ownership when
     G_TUNER is called. On the other hand, that would mean that calling
     v4l2-ctl --all -d /dev/radio0 would change tuner ownership to radio for
     /dev/video0. That's rather unexpected.

     It is possible to just set rxsubchans, signal and afc to 0 if the device
     node doesn't own the tuner. I'm inclined to do that.
   - Should closing a device node switch ownership? E.g. if nobody has a radio
     device open, should the tuner switch back to TV mode automatically? I don't
     think it should.
   - How about hybrid tuners?

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Hans de Goede]

Hi,

<snip>

> Easy:
>
> 1) Split off the control part from videodev2.h. Controls are almost 30% of
>     videodev2.h. I think maintaining controls would be easier if they are moved
>     to e.g. linux/v4l2-controls.h which is included by videodev2.h.
>

Ack.

> 2) Currently there are three types of controls: standard controls, controls
>     that are specific to a chipset (e.g. cx2341x, mfc51) and driver-specific
>     controls. The controls of the first two types have well defined and unique
>     IDs. For driver-specific controls however there are no clear rules.
>
>     It all depends on one question: should driver-specific controls have a
>     unique control ID as well, or can they overlap with other drivers?
>
>     If the answer is that they should be unique as well, then all driver-specific
>     controls will have to be defined in a single header so you can be certain
>     that there is no overlap.
>
>     If the answer is that they may overlap, then each driver can either define
>     their controls inside their own driver, or in a driver-specific public header.
>
>     In both cases a control ID range has to be defined for such controls, to
>     ensure that they never clash with standard or chipset-specific control IDs.
>     E.g. >= V4L2_CTRL_CLASS_XXX + 0x8000 (no overlap) or + 0xf000 (overlap
>     allowed).
>
>     My preference is to allow overlap.
>

+1 for allowing overlap, and only when it is expected that some special app will
actually use the device specific controls (versus the user changing them in
a generic v4l2 control panel app), then the private controls should be defined
in a public header. If no such special app is expected, the private controls
should be defined inside a private header of the driver.

> 3) What should VIDIOC_STREAMON/OFF do if the stream is already started/stopped?
>     I believe they should do nothing and just return 0. The main reason for that
>     is it can be useful if an application can just call VIDIOC_STREAMOFF without
>     having to check whether streaming is in progress.

+1 for just returning 0

> 4) What should a driver return in TRY_FMT/S_FMT if the requested format is not
>     supported (possible behaviours include returning the currently selected format
>     or a default format).
>
>     The spec says this: "Drivers should not return an error code unless the input
>     is ambiguous", but it does not explain what constitutes an ambiguous input.
>     Frankly, I can't think of any and in my opinion TRY/S_FMT should never return
>     an error other than EINVAL (if the buffer type is unsupported) or EBUSY (for
>     S_FMT if streaming is in progress).
>
>     Returning an error for any other reason doesn't help the application since
>     the app will have no way of knowing what to do next.
>

Ack on not returning an error for requesting an unavailable format. As for what the
driver should do (default versus current format) I've no preference, I vote for
letting this be decided by the driver implementation.

> 5) VIDIOC_QUERYCAP allows bus_info to be empty. Since the purpose of bus_info
>     is to distinguish multiple identical devices this makes no sense. I propose
>     to make the spec more strict and require that bus_info is always filled in
>     with a unique string.
>

Ack.

> 6) Deprecate V4L2_BUF_TYPE_PRIVATE. None of the kernel drivers use it, and I
>     cannot see any good use-case for this. If some new type of buffer is needed,
>     then that should be added instead of allowing someone to abuse this buffer
>     type.
>

Ack.

> 7) A driver that has both a video node and a vbi node (for example) that uses
>     the same struct v4l2_ioctl_ops for both nodes will have to check in e.g.
>     vidioc_g_fmt_vid_cap or vidioc_g_fmt_vbi_cap whether it is called from the
>     correct node (video or vbi) and return an error if it isn't.
>
>     That's an annoying test that can be done in the V4L2 core as well. Especially
>     since few drivers actually test for that.
>
>     Should such checks be added to the V4L2 core? And if so, should we add some
>     additional VFL types? Currently we have GRABBER (video nodes), VBI, RADIO
>     and SUBDEV. But if we want to do proper core checks, then we would also need
>     OUTPUT, VBI_OUT and M2M.

I'm in favor of adding checks to the core.

>
> 8) Remove the experimental tag from the following old drivers:
>
> 	VIDEO_TLV320AIC23B
> 	USB_STKWEBCAM
> 	VIDEO_CX18
> 	VIDEO_CX18_ALSA
> 	VIDEO_ZORAN_AVS6EYES
> 	DVB_USB_AF9005
> 	MEDIA_TUNER_TEA5761

ACK.

>
>     Removing this tag from these drivers might be too soon, though:
>
> 	VIDEO_NOON010PC30
> 	VIDEO_OMAP3
>

I've no opinion on these.

> 9) What should VIDIOC_G_STD/DV_PRESET/DV_TIMINGS return if the current input
>     or output does not support that particular timing approach? EINVAL? ENODATA?
>     This is relevant for the case where a driver has multiple inputs/outputs
>     where some are SDTV (and support the STD API) and others are HDTV (and
>     support the DV_TIMINGS API).
>
>     I propose ENODATA.

+1 for ENODATA, EINVAL makes no sense if all the input parameters are correct.

>
> 10) Proposal: add these defines:
>
> #define V4L2_IN_CAP_TIMINGS V4L2_IN_CAP_CUSTOM_TIMINGS
> #define V4L2_OUT_CAP_TIMINGS V4L2_OUT_CAP_CUSTOM_TIMINGS
>
> Since DV_TIMINGS is now used for any HDTV timings and no longer just for
> custom, non-standard timings, the word "CUSTOM" is no longer appropriate.
>

No opinion.

> 11) What should video output drivers do with the sequence and timestamp
>      fields when they return a v4l2_buffer from VIDIOC_DQBUF?
>
>      I think the spec is clear with respect to the timestamp:
>
>      "The driver stores the time at which the first data byte was actually
>       sent out in the timestamp field."
>
>      For sequence the spec just says:
>
>      "Set by the driver, counting the frames in the sequence."
>
>      So I think that output drivers should indeed set both sequence and
>      timestemp.
>

Ack.

> 12) Make the argument of write-only ioctls const in v4l2-ioctls.h. This makes
>      it obvious to drivers that they shouldn't change the contents of the input
>      struct since it won't make it back to userspace. It also simplifies
>      v4l2-ioctl.c since it can rely on the fact that after the ioctl call the
>      contents of the struct hasn't changed. Right now the struct contents is
>      logged (if debugging is on) before the ioctl call for write-only ioctls.
>

Ack (although this will break compilation of some drivers, but that can be fixed).

> Hard(er):
>
> 1) What is the right/best way to set the timestamp? The spec says gettimeofday,
>     but is it my understanding that ktime_get_ts is much more efficient.
>
>     Some drivers are already using ktime_get_ts.
>
>     Options:
>
>     a) all drivers must comply to the spec and use gettimeofday
>     b) we change the spec and all drivers must use the more efficient ktime_get_ts
>     c) we add a buffer flag V4L2_BUF_FLAG_MONOTONIC to tell userspace that a
>        monotonic clock like ktime_get_ts is used and all drivers that use
>        ktime_get_ts should set that flag.
>
>     If we go for c, then we should add a recommendation to use one or the other
>     as the preferred timestamp for new drivers.

Wouldn't b/c break the API?

> 2) If a driver supports only formats with more than one plane, should
>     V4L2_CAP_VIDEO_CAPTURE still be defined?

No

>     And if a driver also supports
>     single-plane formats in addition to >1 plane formats, should
>     V4L2_CAP_VIDEO_CAPTURE be compulsary?

Yes, so that non multi-plane aware apps keep working.

> 3) VIDIOC_CROPCAP: the spec says that CROPCAP must be implemented by all
>     capture and output devices (Section "Image Cropping, Inserting and Scaling").
>     In reality only a subset of the drivers support cropcap.
>
>     Should cropcap really be compulsory? Or only for drivers that can scale? And
>     in that case, should we make a default implementation for those drivers that
>     do not support it? (E.g.: call g_fmt and use the width/height as the
>     default and bounds rectangles, and set the pixel aspect to 1/1)
>

I vote for making it non compulsory, and simply returning -ENOTTY for drivers which
don't support it.

> 4) Pixel aspect: currently this is only available through VIDIOC_CROPCAP. It
>     never really belonged to VIDIOC_CROPCAP IMHO. It's just not a property of
>     cropping/composing. It really belongs to the input/output timings (STD or
>     DV_TIMINGS). That's where the pixel aspect ratio is determined.
>
>     While it is possible to add it to the dv_timings struct, I see no way of
>     cleanly adding it to struct v4l2_standard (mostly because VIDIOC_ENUMSTD
>     is now handled inside the V4L2 core and doesn't call the drivers anymore).
>
>     An alternative is to add it to struct v4l2_input/output, but I don't know
>     if it is possible to defined a pixelaspect for inputs that are not the
>     current input.
>
>     What I am thinking of is just to add a new ioctl for this VIDIOC_G_PIXELASPECT.
>     The argument is then:
>
> 	struct v4l2_pixelaspect {
> 		__u32 type;
> 		struct v4l2_fract pixelaspect;
> 		__u32 reserved[5];
> 	};
>
>     This combines well with the selection API.

We will want to be able to enumerate this too, so I vote for extending v4l2_frmsize_discrete
with a struct v4l2_fract pixelaspect, and likewise for v4l2_frmsize_stepwise.

Likewise we also want to get the pixelaspect on a TRY_FMT, which is a bit tricky, since
we cannot extend  v4l2_pix_format (*) instead we could add a v4l2_pix_format_w_aspect, and add
that to the v4l2_format union. Then apps who want to pixelratio can look inside
v4l2_pix_format_w_aspect instead, with the note that the aspect may be reported as 0/0 by
drivers which don't support reporting it. This avoids adding a new ioctl, and gives us
a way to get the pixelratio without actually having to set the fmt.

(*) no reserved space inside it, and if we would allow it to grow, we still would have an
issue because that would also grow v4l2_framebuffer, which we certainly cannot do.

> 5) How to handle tuner ownership if both a video and radio node share the same
>     tuner?
>
>     Obvious rules:
>
>     - Calling S_FREQ, S_TUNER, S_MODULATOR or S_HW_FREQ_SEEK will change owner
>       or return EBUSY if streaming is in progress.

That won't work, as there is no such thing as streaming from a radio node, I
suggest we go with the simple approach we discussed at our last meeting in
your Dutch House: Calling S_FREQ, S_TUNER, S_MODULATOR or S_HW_FREQ_SEEK will
make an app the tuner-owner, and *closing* the device handle makes an app
release its tuner ownership. If an other app already is the tuner owner
-EBUSY is returned.

>     - Ditto for STREAMON, read/write and polling for read/write.

No, streaming and tuning are 2 different things, if an app does both, it
will likely tune before streaming, but in some cases a user may use a streaming
only app together with say v4l2-ctl to do the actual tuning. I think keeping
things simple here is key. Lets just treat the "tuner" and "stream" as 2 separate
entities with a separate ownership.

>     - Ditto for ioctls that expect a valid tuner configuration like QUERYSTD.

QUERY is a read only ioctl, so it should not be influenced by any ownership, nor
imply ownership.

>     - Just opening a device node should *not* switch ownership.
Ack!

>     But it is not clear what to do when any of these ioctls are called:
>
>     - G_FREQUENCY: could just return the last set frequency for radio or TV:
>       requires that that is remembered when switching ownership. This is what
>       happens today, so G_FREQUENCY does not have to switch ownership.

Ack.

>     - G_TUNER: the rxsubchans, signal and afc fields all require ownership of
>       the tuner. So in principle you would want to switch ownership when
>       G_TUNER is called. On the other hand, that would mean that calling
>       v4l2-ctl --all -d /dev/radio0 would change tuner ownership to radio for
>       /dev/video0. That's rather unexpected.
>
>       It is possible to just set rxsubchans, signal and afc to 0 if the device
>       node doesn't own the tuner. I'm inclined to do that.

Right, G_TUNER should not change ownership, if the tuner is currently in radio
mode and a G_TUNER is done on the video node just 0 out the fields which we cannot
fill with useful info.

>     - Should closing a device node switch ownership? E.g. if nobody has a radio
>       device open, should the tuner switch back to TV mode automatically? I don't
>       think it should.

+1 on delaying the mode switch until it is actually necessary to switch mode.

>     - How about hybrid tuners?

No opinion.

Regards,

Hans

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Hans Verkuil]

On Mon August 13 2012 15:13:34 Hans de Goede wrote:
> Hi,
> 
> <snip>
> 
> > 5) How to handle tuner ownership if both a video and radio node share the same
> >     tuner?
> >
> >     Obvious rules:
> >
> >     - Calling S_FREQ, S_TUNER, S_MODULATOR or S_HW_FREQ_SEEK will change owner
> >       or return EBUSY if streaming is in progress.
> 
> That won't work, as there is no such thing as streaming from a radio node,

There is, actually: read() for RDS data and alsa streaming (although that might
be hard to detect in the case of USB audio).

> I suggest we go with the simple approach we discussed at our last meeting in
> your Dutch House: Calling S_FREQ, S_TUNER, S_MODULATOR or S_HW_FREQ_SEEK will
> make an app the tuner-owner, and *closing* the device handle makes an app
> release its tuner ownership. If an other app already is the tuner owner
> -EBUSY is returned.

So the ownership is associated with a filehandle?

> 
> >     - Ditto for STREAMON, read/write and polling for read/write.
> 
> No, streaming and tuning are 2 different things, if an app does both, it
> will likely tune before streaming, but in some cases a user may use a streaming
> only app together with say v4l2-ctl to do the actual tuning. I think keeping
> things simple here is key. Lets just treat the "tuner" and "stream" as 2 separate
> entities with a separate ownership.

That would work provided the ownership is associated with a filehandle.

> 
> >     - Ditto for ioctls that expect a valid tuner configuration like QUERYSTD.
> 
> QUERY is a read only ioctl, so it should not be influenced by any ownership, nor
> imply ownership.

It is definitely influenced by ownership, since if the tuner is in radio mode,
then it can't detect a standard. Neither is this necessarily a passive call as
some (mostly older) drivers need to switch the receiver to different modes in
order to try and detect the current standard.

> >     - Just opening a device node should *not* switch ownership.
> Ack!
> 
> >     But it is not clear what to do when any of these ioctls are called:
> >
> >     - G_FREQUENCY: could just return the last set frequency for radio or TV:
> >       requires that that is remembered when switching ownership. This is what
> >       happens today, so G_FREQUENCY does not have to switch ownership.
> 
> Ack.
> 
> >     - G_TUNER: the rxsubchans, signal and afc fields all require ownership of
> >       the tuner. So in principle you would want to switch ownership when
> >       G_TUNER is called. On the other hand, that would mean that calling
> >       v4l2-ctl --all -d /dev/radio0 would change tuner ownership to radio for
> >       /dev/video0. That's rather unexpected.
> >
> >       It is possible to just set rxsubchans, signal and afc to 0 if the device
> >       node doesn't own the tuner. I'm inclined to do that.
> 
> Right, G_TUNER should not change ownership, if the tuner is currently in radio
> mode and a G_TUNER is done on the video node just 0 out the fields which we cannot
> fill with useful info.
> 
> >     - Should closing a device node switch ownership? E.g. if nobody has a radio
> >       device open, should the tuner switch back to TV mode automatically? I don't
> >       think it should.
> 
> +1 on delaying the mode switch until it is actually necessary to switch mode.
> 
> >     - How about hybrid tuners?
> 
> No opinion.

Regards,

	Hans

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Hans de Goede]

Hi,

On 08/13/2012 04:52 PM, Hans Verkuil wrote:
> On Mon August 13 2012 15:13:34 Hans de Goede wrote:
>> Hi,
>>
>> <snip>
>>
>>> 5) How to handle tuner ownership if both a video and radio node share the same
>>>      tuner?
>>>
>>>      Obvious rules:
>>>
>>>      - Calling S_FREQ, S_TUNER, S_MODULATOR or S_HW_FREQ_SEEK will change owner
>>>        or return EBUSY if streaming is in progress.
>>
>> That won't work, as there is no such thing as streaming from a radio node,
>
> There is, actually: read() for RDS data and alsa streaming (although that might
> be hard to detect in the case of USB audio).
>
>> I suggest we go with the simple approach we discussed at our last meeting in
>> your Dutch House: Calling S_FREQ, S_TUNER, S_MODULATOR or S_HW_FREQ_SEEK will
>> make an app the tuner-owner, and *closing* the device handle makes an app
>> release its tuner ownership. If an other app already is the tuner owner
>> -EBUSY is returned.
>
> So the ownership is associated with a filehandle?

Yes, that is how it works for videobuf streams too, right? The only difference
being that with videobuf streams there is an expilict way to release the ownership,
where as for tuner ownership there is none, so the ownership is released on device
close.

>
>>
>>>      - Ditto for STREAMON, read/write and polling for read/write.
>>
>> No, streaming and tuning are 2 different things, if an app does both, it
>> will likely tune before streaming, but in some cases a user may use a streaming
>> only app together with say v4l2-ctl to do the actual tuning. I think keeping
>> things simple here is key. Lets just treat the "tuner" and "stream" as 2 separate
>> entities with a separate ownership.
>
> That would work provided the ownership is associated with a filehandle.

Right.

>
>>
>>>      - Ditto for ioctls that expect a valid tuner configuration like QUERYSTD.
>>
>> QUERY is a read only ioctl, so it should not be influenced by any ownership, nor
>> imply ownership.
>
> It is definitely influenced by ownership, since if the tuner is in radio mode,
> then it can't detect a standard. Neither is this necessarily a passive call as
> some (mostly older) drivers need to switch the receiver to different modes in
> order to try and detect the current standard.

Hmm, then I guess that this call should fail with EBUSY if:
The tuner is owned by another app *and*
1) The tuner is in radio mode; or
2) The tuner is in tv mode *and* doing QUERYSTD requires "prodding" the device

<snip>

Regards,

Hans

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Ilyes Gouta]

Hi,

I've got one limitation for v4l2-mem2mem devices: a v4l2-mem2mem
device driver which can't support *both* V4L2_BUF_TYPE_VIDEO_CAPTURE
and V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE capture buffers.

AFAIK/U, this limitation is unjustified.

So, with v4l2-mem2mem :

1. It's not possible to alternatively queue these capture buffers in
the same v4l2-mem2mem instance (fd).
2. It's possible to have one v4l2-mem2mem instance for
V4L2_BUF_TYPE_VIDEO_CAPTURE and another one (separate fd) for
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; but ..
3. In order to get 2., the driver has to call v4l2_m2m_ctx_init() in
v4l2_ioctl_ops::vidioc_reqbufs(), not in v4l2_file_operations::open()
- which is kind of 'OKay'
4. v4l2_m2m_ctx_init() take a callback function as an argument, which
will be called to setup *both* the output and capture vb2 queue.
5. Still in order to get 2., the driver has to call vidioc_reqbufs()
on the capture buffers first, then on the output buffers. If not,
v4l2_m2m_ctx_init() will attempt to setup both output and capture
queues, but still w/ incomplete information on the type of the capture
queue, the userspace really wants.

A solution would be to decouple the output and capture queues
initialization in v4l2_m2m_ctx_init().

-Ilyes

On Mon, Aug 13, 2012 at 2:13 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> <snip>
>
>
>> Easy:
>>
>> 1) Split off the control part from videodev2.h. Controls are almost 30% of
>>     videodev2.h. I think maintaining controls would be easier if they are
>> moved
>>     to e.g. linux/v4l2-controls.h which is included by videodev2.h.
>>
>
> Ack.
>
>
>> 2) Currently there are three types of controls: standard controls,
>> controls
>>     that are specific to a chipset (e.g. cx2341x, mfc51) and
>> driver-specific
>>     controls. The controls of the first two types have well defined and
>> unique
>>     IDs. For driver-specific controls however there are no clear rules.
>>
>>     It all depends on one question: should driver-specific controls have a
>>     unique control ID as well, or can they overlap with other drivers?
>>
>>     If the answer is that they should be unique as well, then all
>> driver-specific
>>     controls will have to be defined in a single header so you can be
>> certain
>>     that there is no overlap.
>>
>>     If the answer is that they may overlap, then each driver can either
>> define
>>     their controls inside their own driver, or in a driver-specific public
>> header.
>>
>>     In both cases a control ID range has to be defined for such controls,
>> to
>>     ensure that they never clash with standard or chipset-specific control
>> IDs.
>>     E.g. >= V4L2_CTRL_CLASS_XXX + 0x8000 (no overlap) or + 0xf000 (overlap
>>     allowed).
>>
>>     My preference is to allow overlap.
>>
>
> +1 for allowing overlap, and only when it is expected that some special app
> will
> actually use the device specific controls (versus the user changing them in
> a generic v4l2 control panel app), then the private controls should be
> defined
> in a public header. If no such special app is expected, the private controls
> should be defined inside a private header of the driver.
>
>
>> 3) What should VIDIOC_STREAMON/OFF do if the stream is already
>> started/stopped?
>>     I believe they should do nothing and just return 0. The main reason
>> for that
>>     is it can be useful if an application can just call VIDIOC_STREAMOFF
>> without
>>     having to check whether streaming is in progress.
>
>
> +1 for just returning 0
>
>
>> 4) What should a driver return in TRY_FMT/S_FMT if the requested format is
>> not
>>     supported (possible behaviours include returning the currently
>> selected format
>>     or a default format).
>>
>>     The spec says this: "Drivers should not return an error code unless
>> the input
>>     is ambiguous", but it does not explain what constitutes an ambiguous
>> input.
>>     Frankly, I can't think of any and in my opinion TRY/S_FMT should never
>> return
>>     an error other than EINVAL (if the buffer type is unsupported) or
>> EBUSY (for
>>     S_FMT if streaming is in progress).
>>
>>     Returning an error for any other reason doesn't help the application
>> since
>>     the app will have no way of knowing what to do next.
>>
>
> Ack on not returning an error for requesting an unavailable format. As for
> what the
> driver should do (default versus current format) I've no preference, I vote
> for
> letting this be decided by the driver implementation.
>
>
>> 5) VIDIOC_QUERYCAP allows bus_info to be empty. Since the purpose of
>> bus_info
>>     is to distinguish multiple identical devices this makes no sense. I
>> propose
>>     to make the spec more strict and require that bus_info is always
>> filled in
>>     with a unique string.
>>
>
> Ack.
>
>
>> 6) Deprecate V4L2_BUF_TYPE_PRIVATE. None of the kernel drivers use it, and
>> I
>>     cannot see any good use-case for this. If some new type of buffer is
>> needed,
>>     then that should be added instead of allowing someone to abuse this
>> buffer
>>     type.
>>
>
> Ack.
>
>
>> 7) A driver that has both a video node and a vbi node (for example) that
>> uses
>>     the same struct v4l2_ioctl_ops for both nodes will have to check in
>> e.g.
>>     vidioc_g_fmt_vid_cap or vidioc_g_fmt_vbi_cap whether it is called from
>> the
>>     correct node (video or vbi) and return an error if it isn't.
>>
>>     That's an annoying test that can be done in the V4L2 core as well.
>> Especially
>>     since few drivers actually test for that.
>>
>>     Should such checks be added to the V4L2 core? And if so, should we add
>> some
>>     additional VFL types? Currently we have GRABBER (video nodes), VBI,
>> RADIO
>>     and SUBDEV. But if we want to do proper core checks, then we would
>> also need
>>     OUTPUT, VBI_OUT and M2M.
>
>
> I'm in favor of adding checks to the core.
>
>
>>
>> 8) Remove the experimental tag from the following old drivers:
>>
>>         VIDEO_TLV320AIC23B
>>         USB_STKWEBCAM
>>         VIDEO_CX18
>>         VIDEO_CX18_ALSA
>>         VIDEO_ZORAN_AVS6EYES
>>         DVB_USB_AF9005
>>         MEDIA_TUNER_TEA5761
>
>
> ACK.
>
>
>>
>>     Removing this tag from these drivers might be too soon, though:
>>
>>         VIDEO_NOON010PC30
>>         VIDEO_OMAP3
>>
>
> I've no opinion on these.
>
>
>> 9) What should VIDIOC_G_STD/DV_PRESET/DV_TIMINGS return if the current
>> input
>>     or output does not support that particular timing approach? EINVAL?
>> ENODATA?
>>     This is relevant for the case where a driver has multiple
>> inputs/outputs
>>     where some are SDTV (and support the STD API) and others are HDTV (and
>>     support the DV_TIMINGS API).
>>
>>     I propose ENODATA.
>
>
> +1 for ENODATA, EINVAL makes no sense if all the input parameters are
> correct.
>
>
>>
>> 10) Proposal: add these defines:
>>
>> #define V4L2_IN_CAP_TIMINGS V4L2_IN_CAP_CUSTOM_TIMINGS
>> #define V4L2_OUT_CAP_TIMINGS V4L2_OUT_CAP_CUSTOM_TIMINGS
>>
>> Since DV_TIMINGS is now used for any HDTV timings and no longer just for
>> custom, non-standard timings, the word "CUSTOM" is no longer appropriate.
>>
>
> No opinion.
>
>
>> 11) What should video output drivers do with the sequence and timestamp
>>      fields when they return a v4l2_buffer from VIDIOC_DQBUF?
>>
>>      I think the spec is clear with respect to the timestamp:
>>
>>      "The driver stores the time at which the first data byte was actually
>>       sent out in the timestamp field."
>>
>>      For sequence the spec just says:
>>
>>      "Set by the driver, counting the frames in the sequence."
>>
>>      So I think that output drivers should indeed set both sequence and
>>      timestemp.
>>
>
> Ack.
>
>
>> 12) Make the argument of write-only ioctls const in v4l2-ioctls.h. This
>> makes
>>      it obvious to drivers that they shouldn't change the contents of the
>> input
>>      struct since it won't make it back to userspace. It also simplifies
>>      v4l2-ioctl.c since it can rely on the fact that after the ioctl call
>> the
>>      contents of the struct hasn't changed. Right now the struct contents
>> is
>>      logged (if debugging is on) before the ioctl call for write-only
>> ioctls.
>>
>
> Ack (although this will break compilation of some drivers, but that can be
> fixed).
>
>
>> Hard(er):
>>
>> 1) What is the right/best way to set the timestamp? The spec says
>> gettimeofday,
>>     but is it my understanding that ktime_get_ts is much more efficient.
>>
>>     Some drivers are already using ktime_get_ts.
>>
>>     Options:
>>
>>     a) all drivers must comply to the spec and use gettimeofday
>>     b) we change the spec and all drivers must use the more efficient
>> ktime_get_ts
>>     c) we add a buffer flag V4L2_BUF_FLAG_MONOTONIC to tell userspace that
>> a
>>        monotonic clock like ktime_get_ts is used and all drivers that use
>>        ktime_get_ts should set that flag.
>>
>>     If we go for c, then we should add a recommendation to use one or the
>> other
>>     as the preferred timestamp for new drivers.
>
>
> Wouldn't b/c break the API?
>
>
>> 2) If a driver supports only formats with more than one plane, should
>>     V4L2_CAP_VIDEO_CAPTURE still be defined?
>
>
> No
>
>
>>     And if a driver also supports
>>     single-plane formats in addition to >1 plane formats, should
>>     V4L2_CAP_VIDEO_CAPTURE be compulsary?
>
>
> Yes, so that non multi-plane aware apps keep working.
>
>
>> 3) VIDIOC_CROPCAP: the spec says that CROPCAP must be implemented by all
>>     capture and output devices (Section "Image Cropping, Inserting and
>> Scaling").
>>     In reality only a subset of the drivers support cropcap.
>>
>>     Should cropcap really be compulsory? Or only for drivers that can
>> scale? And
>>     in that case, should we make a default implementation for those
>> drivers that
>>     do not support it? (E.g.: call g_fmt and use the width/height as the
>>     default and bounds rectangles, and set the pixel aspect to 1/1)
>>
>
> I vote for making it non compulsory, and simply returning -ENOTTY for
> drivers which
> don't support it.
>
>
>> 4) Pixel aspect: currently this is only available through VIDIOC_CROPCAP.
>> It
>>     never really belonged to VIDIOC_CROPCAP IMHO. It's just not a property
>> of
>>     cropping/composing. It really belongs to the input/output timings (STD
>> or
>>     DV_TIMINGS). That's where the pixel aspect ratio is determined.
>>
>>     While it is possible to add it to the dv_timings struct, I see no way
>> of
>>     cleanly adding it to struct v4l2_standard (mostly because
>> VIDIOC_ENUMSTD
>>     is now handled inside the V4L2 core and doesn't call the drivers
>> anymore).
>>
>>     An alternative is to add it to struct v4l2_input/output, but I don't
>> know
>>     if it is possible to defined a pixelaspect for inputs that are not the
>>     current input.
>>
>>     What I am thinking of is just to add a new ioctl for this
>> VIDIOC_G_PIXELASPECT.
>>     The argument is then:
>>
>>         struct v4l2_pixelaspect {
>>                 __u32 type;
>>                 struct v4l2_fract pixelaspect;
>>                 __u32 reserved[5];
>>         };
>>
>>     This combines well with the selection API.
>
>
> We will want to be able to enumerate this too, so I vote for extending
> v4l2_frmsize_discrete
> with a struct v4l2_fract pixelaspect, and likewise for
> v4l2_frmsize_stepwise.
>
> Likewise we also want to get the pixelaspect on a TRY_FMT, which is a bit
> tricky, since
> we cannot extend  v4l2_pix_format (*) instead we could add a
> v4l2_pix_format_w_aspect, and add
> that to the v4l2_format union. Then apps who want to pixelratio can look
> inside
> v4l2_pix_format_w_aspect instead, with the note that the aspect may be
> reported as 0/0 by
> drivers which don't support reporting it. This avoids adding a new ioctl,
> and gives us
> a way to get the pixelratio without actually having to set the fmt.
>
> (*) no reserved space inside it, and if we would allow it to grow, we still
> would have an
> issue because that would also grow v4l2_framebuffer, which we certainly
> cannot do.
>
>
>> 5) How to handle tuner ownership if both a video and radio node share the
>> same
>>     tuner?
>>
>>     Obvious rules:
>>
>>     - Calling S_FREQ, S_TUNER, S_MODULATOR or S_HW_FREQ_SEEK will change
>> owner
>>       or return EBUSY if streaming is in progress.
>
>
> That won't work, as there is no such thing as streaming from a radio node, I
> suggest we go with the simple approach we discussed at our last meeting in
> your Dutch House: Calling S_FREQ, S_TUNER, S_MODULATOR or S_HW_FREQ_SEEK
> will
> make an app the tuner-owner, and *closing* the device handle makes an app
> release its tuner ownership. If an other app already is the tuner owner
> -EBUSY is returned.
>
>
>>     - Ditto for STREAMON, read/write and polling for read/write.
>
>
> No, streaming and tuning are 2 different things, if an app does both, it
> will likely tune before streaming, but in some cases a user may use a
> streaming
> only app together with say v4l2-ctl to do the actual tuning. I think keeping
> things simple here is key. Lets just treat the "tuner" and "stream" as 2
> separate
> entities with a separate ownership.
>
>
>>     - Ditto for ioctls that expect a valid tuner configuration like
>> QUERYSTD.
>
>
> QUERY is a read only ioctl, so it should not be influenced by any ownership,
> nor
> imply ownership.
>
>
>>     - Just opening a device node should *not* switch ownership.
>
> Ack!
>
>
>>     But it is not clear what to do when any of these ioctls are called:
>>
>>     - G_FREQUENCY: could just return the last set frequency for radio or
>> TV:
>>       requires that that is remembered when switching ownership. This is
>> what
>>       happens today, so G_FREQUENCY does not have to switch ownership.
>
>
> Ack.
>
>
>>     - G_TUNER: the rxsubchans, signal and afc fields all require ownership
>> of
>>       the tuner. So in principle you would want to switch ownership when
>>       G_TUNER is called. On the other hand, that would mean that calling
>>       v4l2-ctl --all -d /dev/radio0 would change tuner ownership to radio
>> for
>>       /dev/video0. That's rather unexpected.
>>
>>       It is possible to just set rxsubchans, signal and afc to 0 if the
>> device
>>       node doesn't own the tuner. I'm inclined to do that.
>
>
> Right, G_TUNER should not change ownership, if the tuner is currently in
> radio
> mode and a G_TUNER is done on the video node just 0 out the fields which we
> cannot
> fill with useful info.
>
>
>>     - Should closing a device node switch ownership? E.g. if nobody has a
>> radio
>>       device open, should the tuner switch back to TV mode automatically?
>> I don't
>>       think it should.
>
>
> +1 on delaying the mode switch until it is actually necessary to switch
> mode.
>
>
>>     - How about hybrid tuners?
>
>
> No opinion.
>
> Regards,
>
> Hans
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Sylwester Nawrocki]

Hi!

On 08/13/2012 03:13 PM, Hans de Goede wrote:
>> 2) If a driver supports only formats with more than one plane, should
>> V4L2_CAP_VIDEO_CAPTURE still be defined?
> 
> No

Agreed.

>> And if a driver also supports
>> single-plane formats in addition to >1 plane formats, should
>> V4L2_CAP_VIDEO_CAPTURE be compulsary?
> 
> Yes, so that non multi-plane aware apps keep working.

There is the multi-planar API and there are multi-planar formats. Single- 
and multi-planar formats can be handled with the multi-planar API. So if 
a driver supports single- and multi-planar formats by means on multi-planar
APIs, there shouldn't be a need for signalling V4L2_CAP_VIDEO_CAPTURE, 
which normally indicates single-planar API. The driver may choose to not 
support it, in order to handle single-planar formats. Thus, in my opinion 
making V4L2_CAP_VIDEO_CAPTURE compulsory wouldn't make sense. Unless the 
driver supports both types of ioctls (_mplane and regular versions), we 
shouldn't flag V4L2_CAP_VIDEO_CAPTURE. 

Regards,
Sylwester

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Hans de Goede]

Hi,

On 08/13/2012 09:15 PM, Sylwester Nawrocki wrote:
<snip>

>>> And if a driver also supports
>>> single-plane formats in addition to >1 plane formats, should
>>> V4L2_CAP_VIDEO_CAPTURE be compulsary?
>>
>> Yes, so that non multi-plane aware apps keep working.
>
> There is the multi-planar API and there are multi-planar formats. Single-
> and multi-planar formats can be handled with the multi-planar API. So if
> a driver supports single- and multi-planar formats by means on multi-planar
> APIs, there shouldn't be a need for signalling V4L2_CAP_VIDEO_CAPTURE,
> which normally indicates single-planar API. The driver may choose to not
> support it, in order to handle single-planar formats. Thus, in my opinion
> making V4L2_CAP_VIDEO_CAPTURE compulsory wouldn't make sense. Unless the
> driver supports both types of ioctls (_mplane and regular versions), we
> shouldn't flag V4L2_CAP_VIDEO_CAPTURE.
>

Ok.

Regards,

Hans

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Laurent Pinchart]

Hi Hans,

On Monday 13 August 2012 15:13:34 Hans de Goede wrote:

[snip]

> > 4) What should a driver return in TRY_FMT/S_FMT if the requested format is
> >     not supported (possible behaviours include returning the currently
> >     selected format or a default format).
> >     
> >     The spec says this: "Drivers should not return an error code unless
> >     the input is ambiguous", but it does not explain what constitutes an
> >     ambiguous input. Frankly, I can't think of any and in my opinion
> >     TRY/S_FMT should never return an error other than EINVAL (if the
> >     buffer type is unsupported) or EBUSY (for S_FMT if streaming is in
> >     progress).
> >     
> >     Returning an error for any other reason doesn't help the application
> >     since the app will have no way of knowing what to do next.
> 
> Ack on not returning an error for requesting an unavailable format. As for
> what the driver should do (default versus current format) I've no
> preference, I vote for letting this be decided by the driver
> implementation.

That's exactly the point that I wanted to clarify :-) I don't see a good 
reason to let the driver decide on this, and would prefer returning a default 
format as TRY_FMT would then always return the same result for a given input 
format regardless of the currently selected format.

-- 
Regards,

Laurent Pinchart

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Hans de Goede]

Hi,

On 08/14/2012 02:00 AM, Laurent Pinchart wrote:
> Hi Hans,
>
> On Monday 13 August 2012 15:13:34 Hans de Goede wrote:
>
> [snip]
>
>>> 4) What should a driver return in TRY_FMT/S_FMT if the requested format is
>>>      not supported (possible behaviours include returning the currently
>>>      selected format or a default format).
>>>
>>>      The spec says this: "Drivers should not return an error code unless
>>>      the input is ambiguous", but it does not explain what constitutes an
>>>      ambiguous input. Frankly, I can't think of any and in my opinion
>>>      TRY/S_FMT should never return an error other than EINVAL (if the
>>>      buffer type is unsupported) or EBUSY (for S_FMT if streaming is in
>>>      progress).
>>>
>>>      Returning an error for any other reason doesn't help the application
>>>      since the app will have no way of knowing what to do next.
>>
>> Ack on not returning an error for requesting an unavailable format. As for
>> what the driver should do (default versus current format) I've no
>> preference, I vote for letting this be decided by the driver
>> implementation.
>
> That's exactly the point that I wanted to clarify :-) I don't see a good
> reason to let the driver decide on this, and would prefer returning a default
> format

I see.

> as TRY_FMT would then always return the same result for a given input
> format regardless of the currently selected format.

That argument makes sense, so ack from me on always returning a default format.

Regards,

Hans

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Rémi Denis-Courmont]

Le lundi 13 août 2012 15:27:56 Hans Verkuil, vous avez écrit :
> 1) What is the right/best way to set the timestamp? The spec says
> gettimeofday, but is it my understanding that ktime_get_ts is much more
> efficient.
> 
>    Some drivers are already using ktime_get_ts.
> 
>    Options:
> 
>    a) all drivers must comply to the spec and use gettimeofday

gettimeofday() is wrong for use other than getting the wall clock time.
In particular, it breaks if the real-time clock gets adjusted while streaming.

Practically all modern multimedia applications on Linux use the monotonic 
POSIX clock in a way or another.

>    b) we change the spec and all drivers must use the more efficient
> ktime_get_ts

Unfortunately, that would not be enough to be immediately useful. Userspace 
needs a way to know that it can (finally!) trust the timestamps. Currently, 
since different drivers use different clocks, the only reasonable option for 
user space consists of ignoring the V4L2 timestamp. Thus userspace has to fall 
back to the current clock time after ioctl(DQBUF) returns, as an 
approximation.

> c) we add a buffer flag V4L2_BUF_FLAG_MONOTONIC to tell
> userspace that a monotonic clock like ktime_get_ts is used and all drivers
> that use ktime_get_ts should set that flag.

Yes, either a buffer or a capability flag ought to work.

>    If we go for c, then we should add a recommendation to use one or the
> other as the preferred timestamp for new drivers.

IMHO, all drivers should be adapted to the new specification as far as 
possible.


Of course, that will break any user space application that would have trusted 
V4L2 to return valid CLOCK_REALTIME timestamps so far. I'd argue such an 
application was already broken in practice even if it conformed to the letter 
of the V4L2 specification.

-- 
Rémi Denis-Courmont
C/C++ software engineer looking for a job
http://www.linkedin.com/in/remidenis

Re: RFC: V4L2 API ambiguities

[Walter Van Eetvelt]

On Mon, 13 Aug 2012 14:27:56 +0200, Hans Verkuil <hverkuil@xs4all.nl>
wrote:
> Hi all!
> 
> As part of the 2012 Kernel Summit V4L2 workshop I will be discussing a
> bunch of
> V4L2 ambiguities/improvements.
...
> 
> If something is unclear, or you think another topic should be added,
then
> let me
> know as well.

For me there is a an issue in the V4L specs for the support of DVB-S/C/T
devices where the CI device is decoupled from the Tuners.  
At the moment there is no standard solution on which device drivers
implementers and Application programmers can fall back.

This is for hardware with multiple tuners and one CI device that can
handle multiple streams (or even streams from different cards).   

The solution should explain how the Tuners are linked to the CI module(s).


The current situation leads to device drivers that are implemented but
that are not (fully) usable in any application.  The application developers
are waiting for API specs to explain how to implement  the CI capabilities.


In my experience a solution for this would bring more users to use
DVB-S/T/C capabilities of Linux (as the average TV user in many countries
uses a payed subscription).  

Walter

Re: RFC: V4L2 API ambiguities

[Devin Heitmueller]

On Mon, Aug 13, 2012 at 4:27 PM, Walter Van Eetvelt
<walter@van.eetvelt.be> wrote:
> For me there is a an issue in the V4L specs for the support of DVB-S/C/T
> devices where the CI device is decoupled from the Tuners.
> At the moment there is no standard solution on which device drivers
> implementers and Application programmers can fall back.

DVB isn't part of the V4L spec.  There are *tons* of problems with
DVB, none of which are being discussed in this meeting (out of scope).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: RFC: V4L2 API ambiguities

[Mauro Carvalho Chehab]

Em 13-08-2012 18:31, Devin Heitmueller escreveu:
> On Mon, Aug 13, 2012 at 4:27 PM, Walter Van Eetvelt
> <walter@van.eetvelt.be> wrote:
>> For me there is a an issue in the V4L specs for the support of DVB-S/C/T
>> devices where the CI device is decoupled from the Tuners.
>> At the moment there is no standard solution on which device drivers
>> implementers and Application programmers can fall back.
> 
> DVB isn't part of the V4L spec.  There are *tons* of problems with
> DVB, none of which are being discussed in this meeting (out of scope).

No, it is not out of scope. The thing is that none of the developers
that are going to be there proposed a DVB-specific themes, unfortunately.

Yet, there are two themes there that are not V4L only: the userspace
discussions and the SoC discussions. I expect that it will focus at
the media API's as a hole, and not just V4L API.

Regards,
Mauro

Re: RFC: V4L2 API ambiguities

[Devin Heitmueller]

On Mon, Aug 13, 2012 at 5:39 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> No, it is not out of scope. The thing is that none of the developers
> that are going to be there proposed a DVB-specific themes, unfortunately.
>
> Yet, there are two themes there that are not V4L only: the userspace
> discussions and the SoC discussions. I expect that it will focus at
> the media API's as a hole, and not just V4L API.

I'm talking specifically about a discussion of "V4L2 API Ambiguities",
which is the topic of this thread and the meeting in question.  I
realize other parts of the conference include DVB.  If you want me to
start piling onto this thread will all the problems/deficiencies
related to our DVB API, we can certainly do that.  However, none of
the people on this thread will have any real insight into them given
those individuals focus entirely on V4L2.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: RFC: V4L2 API ambiguities

[Mauro Carvalho Chehab]

Em 13-08-2012 18:42, Devin Heitmueller escreveu:
> On Mon, Aug 13, 2012 at 5:39 PM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> No, it is not out of scope. The thing is that none of the developers
>> that are going to be there proposed a DVB-specific themes, unfortunately.
>>
>> Yet, there are two themes there that are not V4L only: the userspace
>> discussions and the SoC discussions. I expect that it will focus at
>> the media API's as a hole, and not just V4L API.
> 
> I'm talking specifically about a discussion of "V4L2 API Ambiguities",
> which is the topic of this thread and the meeting in question.

OK. With that regards, you're right.

> I
> realize other parts of the conference include DVB.  If you want me to
> start piling onto this thread will all the problems/deficiencies
> related to our DVB API, we can certainly do that.  However, none of
> the people on this thread will have any real insight into them given
> those individuals focus entirely on V4L2.

Yeah, but anyway we can try to cover the points that Walter
made during the DVB topics.

I suspect, however, that we need an RFC with a proposal for CI
decoupled from the demux, in order to be able to discuss it.

Regards,
Mauro

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Laurent Pinchart]

Hi Hans,

On Monday 13 August 2012 14:27:56 Hans Verkuil wrote:
> Hi all!
> 
> As part of the 2012 Kernel Summit V4L2 workshop I will be discussing a bunch
> of V4L2 ambiguities/improvements.
> 
> I've made a list of all the V4L2 issues and put them in two categories:
> issues that I think are easy to resolve (within a few minutes at most), and
> those that are harder.
> 
> If you think I put something in the easy category that you believe is
> actually hard, then please let me know.
> 
> If you attend the workshop, then please read through this and think about it
> a bit, particularly for the second category.
> 
> If something is unclear, or you think another topic should be added, then
> let me know as well.
> 
> Easy:

[snip]

> 4) What should a driver return in TRY_FMT/S_FMT if the requested format is
> not supported (possible behaviours include returning the currently selected
> format or a default format).
> 
>    The spec says this: "Drivers should not return an error code unless the
> input is ambiguous", but it does not explain what constitutes an ambiguous
> input. Frankly, I can't think of any and in my opinion TRY/S_FMT should
> never return an error other than EINVAL (if the buffer type is unsupported)
> or EBUSY (for S_FMT if streaming is in progress).
> 
>    Returning an error for any other reason doesn't help the application
> since the app will have no way of knowing what to do next.

That wasn't my point. Drivers should obviously not return an error. Let's 
consider the case of a driver supporting YUYV and MJPEG. If the user calls 
TRY_FMT or S_FMT with the pixel format set to RGB565, should the driver return 
a hardcoded default format (one of YUYV or MJPEG), or the currently selected 
format ? In other words, should the pixel format returned by TRY_FMT or S_FMT 
when the requested pixel format is not valid be a fixed default pixel format, 
or should it depend on the currently selected pixel format ?

[snip]

> 11) What should video output drivers do with the sequence and timestamp
>     fields when they return a v4l2_buffer from VIDIOC_DQBUF?
> 
>     I think the spec is clear with respect to the timestamp:
> 
>     "The driver stores the time at which the first data byte was actually
>      sent out in the timestamp field."

The complete text says

"For input streams this is the system time (as returned by the gettimeofday() 
function) when the first data byte was captured. For output streams the data 
will not be displayed before this time, secondary to the nominal frame rate 
determined by the current video standard in enqueued order. Applications can 
for example zero this field to display frames as soon as possible. The driver 
stores the time at which the first data byte was actually sent out in the 
timestamp field. This permits applications to monitor the drift between the 
video and system clock."

Splitting it into two paragraphs after the first sentence would in my opinion 
be clearer.

>     For sequence the spec just says:
> 
>     "Set by the driver, counting the frames in the sequence."
> 
>     So I think that output drivers should indeed set both sequence and
>     timestemp.

I'm fine with that, I would then just like to clarify the spec.

[snip]

> Hard(er):
> 
> 1) What is the right/best way to set the timestamp? The spec says
> gettimeofday, but is it my understanding that ktime_get_ts is much more
> efficient.
> 
>    Some drivers are already using ktime_get_ts.
> 
>    Options:
> 
>    a) all drivers must comply to the spec and use gettimeofday
>    b) we change the spec and all drivers must use the more efficient
> ktime_get_ts
>    c) we add a buffer flag V4L2_BUF_FLAG_MONOTONIC to tell userspace that a
> monotonic clock like ktime_get_ts is used and all drivers that use
> ktime_get_ts should set that flag.
> 
>    If we go for c, then we should add a recommendation to use one or the
> other as the preferred timestamp for new drivers.

I'd like to take this opportunity to introduce a proposed extension to the 
V4L2 API.

UVC devices send a device timestamp for each frame in device clock units. I 
expect other devices to have similar capabilities.

That device timestamp can be converted to a host timestamp by a clock recovery 
algorithm that uses clocks correlation information provided by the device. The 
uvcvideo driver currently converts the device timestamp to a host timestamp in 
kernelspace and fills the v4l2_buffer timestamp field with the computed value 
(which is BTW something that I would like the spec to allow, we should specify 
which clock the timestamp field must refer to, but should not mandate the use 
of a specific kernel function to retrieve the value).

A userspace implementation of the clock recovery algorithm would produce 
better results. For this to be possible, applications (or 
libraries/middlewares) must retrieve the clock correlation information (a 
driver-specific ioctl makes sense here, as the information is device-
specific), and receive the device timestamp corresponding to each frame in 
v4l2_buffer. To avoid using one of the v4l2_buffer reserved fields to pass the 
device timestamp, I was thinking of adding a new ioctl or a flag in an 
existing ioctl to "switch" to device timestamp mode.

[snip]

> 4) Pixel aspect: currently this is only available through VIDIOC_CROPCAP. It
> never really belonged to VIDIOC_CROPCAP IMHO. It's just not a property of
> cropping/composing. It really belongs to the input/output timings (STD or
> DV_TIMINGS). That's where the pixel aspect ratio is determined.
> 
>    While it is possible to add it to the dv_timings struct, I see no way of
>    cleanly adding it to struct v4l2_standard (mostly because VIDIOC_ENUMSTD
>    is now handled inside the V4L2 core and doesn't call the drivers
> anymore).
> 
>    An alternative is to add it to struct v4l2_input/output, but I don't know
> if it is possible to defined a pixelaspect for inputs that are not the
> current input.
> 
>    What I am thinking of is just to add a new ioctl for this
> VIDIOC_G_PIXELASPECT. The argument is then:
> 
> 	struct v4l2_pixelaspect {
> 		__u32 type;
> 		struct v4l2_fract pixelaspect;
> 		__u32 reserved[5];
> 	};
> 
>    This combines well with the selection API.

We might want to report more "format"-related information in the future than 
just the pixel ratio, a more generic name for the ioctl might make sense.

Do we also need a corresponding subdev pad operation and subdev ioctl ?

-- 
Regards,

Laurent Pinchart

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Hans Verkuil]

On Tue August 14 2012 01:54:16 Laurent Pinchart wrote:
> Hi Hans,
> 
> On Monday 13 August 2012 14:27:56 Hans Verkuil wrote:
> > Hi all!
> > 
> > As part of the 2012 Kernel Summit V4L2 workshop I will be discussing a bunch
> > of V4L2 ambiguities/improvements.
> > 
> > I've made a list of all the V4L2 issues and put them in two categories:
> > issues that I think are easy to resolve (within a few minutes at most), and
> > those that are harder.
> > 
> > If you think I put something in the easy category that you believe is
> > actually hard, then please let me know.
> > 
> > If you attend the workshop, then please read through this and think about it
> > a bit, particularly for the second category.
> > 
> > If something is unclear, or you think another topic should be added, then
> > let me know as well.
> > 
> > Easy:
> 
> [snip]
> 
> > 4) What should a driver return in TRY_FMT/S_FMT if the requested format is
> > not supported (possible behaviours include returning the currently selected
> > format or a default format).
> > 
> >    The spec says this: "Drivers should not return an error code unless the
> > input is ambiguous", but it does not explain what constitutes an ambiguous
> > input. Frankly, I can't think of any and in my opinion TRY/S_FMT should
> > never return an error other than EINVAL (if the buffer type is unsupported)
> > or EBUSY (for S_FMT if streaming is in progress).
> > 
> >    Returning an error for any other reason doesn't help the application
> > since the app will have no way of knowing what to do next.
> 
> That wasn't my point. Drivers should obviously not return an error. Let's 
> consider the case of a driver supporting YUYV and MJPEG. If the user calls 
> TRY_FMT or S_FMT with the pixel format set to RGB565, should the driver return 
> a hardcoded default format (one of YUYV or MJPEG), or the currently selected 
> format ? In other words, should the pixel format returned by TRY_FMT or S_FMT 
> when the requested pixel format is not valid be a fixed default pixel format, 
> or should it depend on the currently selected pixel format ?

Actually, in this case I would probably choose a YUYV format that is closest
to the requested size. If a driver supports both compressed and uncompressed
formats, then it should only select a compressed format if the application
explicitly asked for it. Handling compressed formats is more complex than
uncompressed formats, so that seems a sensible rule.

The next heuristic I would apply is to choose a format that is closest to the
requested size.

So I guess my guidelines would be:

1) If the pixelformat is not supported, then choose an uncompressed format
(if possible) instead.
2) Next choose a format closest to, but smaller than (if possible) the
requested size.

But this would be a guideline only, and in the end it should be up to the
driver. Just as long TRY/S_FMT always returns a format.

Regards,

	Hans

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Laurent Pinchart]

Hi Hans,

On Tuesday 14 August 2012 12:54:34 Hans Verkuil wrote:
> On Tue August 14 2012 01:54:16 Laurent Pinchart wrote:
> > On Monday 13 August 2012 14:27:56 Hans Verkuil wrote:
> > > Hi all!
> > > 
> > > As part of the 2012 Kernel Summit V4L2 workshop I will be discussing a
> > > bunch of V4L2 ambiguities/improvements.
> > > 
> > > I've made a list of all the V4L2 issues and put them in two categories:
> > > issues that I think are easy to resolve (within a few minutes at most),
> > > and those that are harder.
> > > 
> > > If you think I put something in the easy category that you believe is
> > > actually hard, then please let me know.
> > > 
> > > If you attend the workshop, then please read through this and think
> > > about it a bit, particularly for the second category.
> > > 
> > > If something is unclear, or you think another topic should be added,
> > > then let me know as well.
> > 
> > > Easy:
> > [snip]
> > 
> > > 4) What should a driver return in TRY_FMT/S_FMT if the requested format
> > > is not supported (possible behaviours include returning the currently
> > > selected format or a default format).
> > > 
> > > The spec says this: "Drivers should not return an error code unless
> > > the input is ambiguous", but it does not explain what constitutes an
> > > ambiguous input. Frankly, I can't think of any and in my opinion
> > > TRY/S_FMT should never return an error other than EINVAL (if the buffer
> > > type is unsupported)or EBUSY (for S_FMT if streaming is in progress).
> > > 
> > > Returning an error for any other reason doesn't help the application
> > > since the app will have no way of knowing what to do next.
> > 
> > That wasn't my point. Drivers should obviously not return an error. Let's
> > consider the case of a driver supporting YUYV and MJPEG. If the user calls
> > TRY_FMT or S_FMT with the pixel format set to RGB565, should the driver
> > return a hardcoded default format (one of YUYV or MJPEG), or the
> > currently selected format ? In other words, should the pixel format
> > returned by TRY_FMT or S_FMT when the requested pixel format is not valid
> > be a fixed default pixel format, or should it depend on the currently
> > selected pixel format ?
> 
> Actually, in this case I would probably choose a YUYV format that is closest
> to the requested size. If a driver supports both compressed and
> uncompressed formats, then it should only select a compressed format if the
> application explicitly asked for it. Handling compressed formats is more
> complex than uncompressed formats, so that seems a sensible rule.

That wasn't my point either :-) YUYV/MJPEG was just an example. You can 
replace MJPEG with UYVY or NV12 above. What I want to know is whether TRY_FMT 
and S_FMT must, when given a non-supported format, return a fixed supported 
format or return a supported format that can depend on the currently selected 
format.

> The next heuristic I would apply is to choose a format that is closest to
> the requested size.
> 
> So I guess my guidelines would be:
> 
> 1) If the pixelformat is not supported, then choose an uncompressed format
> (if possible) instead.
> 2) Next choose a format closest to, but smaller than (if possible) the
> requested size.
> 
> But this would be a guideline only, and in the end it should be up to the
> driver. Just as long TRY/S_FMT always returns a format.

-- 
Regards,

Laurent Pinchart

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Hans Verkuil]

On Tue August 14 2012 13:06:46 Laurent Pinchart wrote:
> Hi Hans,
> 
> On Tuesday 14 August 2012 12:54:34 Hans Verkuil wrote:
> > On Tue August 14 2012 01:54:16 Laurent Pinchart wrote:
> > > On Monday 13 August 2012 14:27:56 Hans Verkuil wrote:
> > > > Hi all!
> > > > 
> > > > As part of the 2012 Kernel Summit V4L2 workshop I will be discussing a
> > > > bunch of V4L2 ambiguities/improvements.
> > > > 
> > > > I've made a list of all the V4L2 issues and put them in two categories:
> > > > issues that I think are easy to resolve (within a few minutes at most),
> > > > and those that are harder.
> > > > 
> > > > If you think I put something in the easy category that you believe is
> > > > actually hard, then please let me know.
> > > > 
> > > > If you attend the workshop, then please read through this and think
> > > > about it a bit, particularly for the second category.
> > > > 
> > > > If something is unclear, or you think another topic should be added,
> > > > then let me know as well.
> > > 
> > > > Easy:
> > > [snip]
> > > 
> > > > 4) What should a driver return in TRY_FMT/S_FMT if the requested format
> > > > is not supported (possible behaviours include returning the currently
> > > > selected format or a default format).
> > > > 
> > > > The spec says this: "Drivers should not return an error code unless
> > > > the input is ambiguous", but it does not explain what constitutes an
> > > > ambiguous input. Frankly, I can't think of any and in my opinion
> > > > TRY/S_FMT should never return an error other than EINVAL (if the buffer
> > > > type is unsupported)or EBUSY (for S_FMT if streaming is in progress).
> > > > 
> > > > Returning an error for any other reason doesn't help the application
> > > > since the app will have no way of knowing what to do next.
> > > 
> > > That wasn't my point. Drivers should obviously not return an error. Let's
> > > consider the case of a driver supporting YUYV and MJPEG. If the user calls
> > > TRY_FMT or S_FMT with the pixel format set to RGB565, should the driver
> > > return a hardcoded default format (one of YUYV or MJPEG), or the
> > > currently selected format ? In other words, should the pixel format
> > > returned by TRY_FMT or S_FMT when the requested pixel format is not valid
> > > be a fixed default pixel format, or should it depend on the currently
> > > selected pixel format ?
> > 
> > Actually, in this case I would probably choose a YUYV format that is closest
> > to the requested size. If a driver supports both compressed and
> > uncompressed formats, then it should only select a compressed format if the
> > application explicitly asked for it. Handling compressed formats is more
> > complex than uncompressed formats, so that seems a sensible rule.
> 
> That wasn't my point either :-) YUYV/MJPEG was just an example. You can 
> replace MJPEG with UYVY or NV12 above. What I want to know is whether TRY_FMT 
> and S_FMT must, when given a non-supported format, return a fixed supported 
> format or return a supported format that can depend on the currently selected 
> format.
> 
> > The next heuristic I would apply is to choose a format that is closest to
> > the requested size.
> > 
> > So I guess my guidelines would be:
> > 
> > 1) If the pixelformat is not supported, then choose an uncompressed format
> > (if possible) instead.
> > 2) Next choose a format closest to, but smaller than (if possible) the
> > requested size.
> > 
> > But this would be a guideline only, and in the end it should be up to the
> > driver. Just as long TRY/S_FMT always returns a format.

Well, the currently selected format is irrelevant. The user is obviously
requesting something else and the driver should attempt to return something
that is at least somewhat close to what it requested. If that's impossible,
then falling back to some default format is a good choice.

Does that answer the question?

Regards,

	Hans

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Laurent Pinchart]

Hi Hans,

On Tuesday 14 August 2012 13:11:49 Hans Verkuil wrote:
> On Tue August 14 2012 13:06:46 Laurent Pinchart wrote:
> > On Tuesday 14 August 2012 12:54:34 Hans Verkuil wrote:
> > > On Tue August 14 2012 01:54:16 Laurent Pinchart wrote:
> > > > On Monday 13 August 2012 14:27:56 Hans Verkuil wrote:
> > > > [snip]
> > > > 
> > > > > 4) What should a driver return in TRY_FMT/S_FMT if the requested
> > > > > format is not supported (possible behaviours include returning the
> > > > > currently selected format or a default format).
> > > > > 
> > > > > The spec says this: "Drivers should not return an error code unless
> > > > > the input is ambiguous", but it does not explain what constitutes an
> > > > > ambiguous input. Frankly, I can't think of any and in my opinion
> > > > > TRY/S_FMT should never return an error other than EINVAL (if the
> > > > > buffer type is unsupported)or EBUSY (for S_FMT if streaming is in
> > > > > progress).
> > > > > 
> > > > > Returning an error for any other reason doesn't help the application
> > > > > since the app will have no way of knowing what to do next.
> > > > 
> > > > That wasn't my point. Drivers should obviously not return an error.
> > > > Let's consider the case of a driver supporting YUYV and MJPEG. If the
> > > > user calls TRY_FMT or S_FMT with the pixel format set to RGB565,
> > > > should the driver return a hardcoded default format (one of YUYV or
> > > > MJPEG), or the currently selected format ? In other words, should the
> > > > pixel format returned by TRY_FMT or S_FMT when the requested pixel
> > > > format is not valid be a fixed default pixel format, or should it
> > > > depend on the currently selected pixel format ?
> > > 
> > > Actually, in this case I would probably choose a YUYV format that is
> > > closest to the requested size. If a driver supports both compressed and
> > > uncompressed formats, then it should only select a compressed format if
> > > the application explicitly asked for it. Handling compressed formats is
> > > more complex than uncompressed formats, so that seems a sensible rule.
> > 
> > That wasn't my point either :-) YUYV/MJPEG was just an example. You can
> > replace MJPEG with UYVY or NV12 above. What I want to know is whether
> > TRY_FMT and S_FMT must, when given a non-supported format, return a fixed
> > supported format or return a supported format that can depend on the
> > currently selected format.
> > 
> > > The next heuristic I would apply is to choose a format that is closest
> > > to the requested size.
> > > 
> > > So I guess my guidelines would be:
> > > 
> > > 1) If the pixelformat is not supported, then choose an uncompressed
> > > format (if possible) instead.
> > > 2) Next choose a format closest to, but smaller than (if possible) the
> > > requested size.
> > > 
> > > But this would be a guideline only, and in the end it should be up to
> > > the driver. Just as long TRY/S_FMT always returns a format.
> 
> Well, the currently selected format is irrelevant. The user is obviously
> requesting something else and the driver should attempt to return something
> that is at least somewhat close to what it requested. If that's impossible,
> then falling back to some default format is a good choice.
> 
> Does that answer the question?

Yes it does, and I agree with that. Some drivers return the currently selected 
format when a non-supported format is requested. I think the spec should be 
clarified to make it mandatory to return a fixed default format independent of 
the currently selected format, and non-compliant drivers should be fixed.

-- 
Regards,

Laurent Pinchart

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Hans Verkuil]

On Tue August 14 2012 13:15:21 Laurent Pinchart wrote:
> Hi Hans,
> 
> On Tuesday 14 August 2012 13:11:49 Hans Verkuil wrote:
> > On Tue August 14 2012 13:06:46 Laurent Pinchart wrote:
> > > On Tuesday 14 August 2012 12:54:34 Hans Verkuil wrote:
> > > > On Tue August 14 2012 01:54:16 Laurent Pinchart wrote:
> > > > > On Monday 13 August 2012 14:27:56 Hans Verkuil wrote:
> > > > > [snip]
> > > > > 
> > > > > > 4) What should a driver return in TRY_FMT/S_FMT if the requested
> > > > > > format is not supported (possible behaviours include returning the
> > > > > > currently selected format or a default format).
> > > > > > 
> > > > > > The spec says this: "Drivers should not return an error code unless
> > > > > > the input is ambiguous", but it does not explain what constitutes an
> > > > > > ambiguous input. Frankly, I can't think of any and in my opinion
> > > > > > TRY/S_FMT should never return an error other than EINVAL (if the
> > > > > > buffer type is unsupported)or EBUSY (for S_FMT if streaming is in
> > > > > > progress).
> > > > > > 
> > > > > > Returning an error for any other reason doesn't help the application
> > > > > > since the app will have no way of knowing what to do next.
> > > > > 
> > > > > That wasn't my point. Drivers should obviously not return an error.
> > > > > Let's consider the case of a driver supporting YUYV and MJPEG. If the
> > > > > user calls TRY_FMT or S_FMT with the pixel format set to RGB565,
> > > > > should the driver return a hardcoded default format (one of YUYV or
> > > > > MJPEG), or the currently selected format ? In other words, should the
> > > > > pixel format returned by TRY_FMT or S_FMT when the requested pixel
> > > > > format is not valid be a fixed default pixel format, or should it
> > > > > depend on the currently selected pixel format ?
> > > > 
> > > > Actually, in this case I would probably choose a YUYV format that is
> > > > closest to the requested size. If a driver supports both compressed and
> > > > uncompressed formats, then it should only select a compressed format if
> > > > the application explicitly asked for it. Handling compressed formats is
> > > > more complex than uncompressed formats, so that seems a sensible rule.
> > > 
> > > That wasn't my point either :-) YUYV/MJPEG was just an example. You can
> > > replace MJPEG with UYVY or NV12 above. What I want to know is whether
> > > TRY_FMT and S_FMT must, when given a non-supported format, return a fixed
> > > supported format or return a supported format that can depend on the
> > > currently selected format.
> > > 
> > > > The next heuristic I would apply is to choose a format that is closest
> > > > to the requested size.
> > > > 
> > > > So I guess my guidelines would be:
> > > > 
> > > > 1) If the pixelformat is not supported, then choose an uncompressed
> > > > format (if possible) instead.
> > > > 2) Next choose a format closest to, but smaller than (if possible) the
> > > > requested size.
> > > > 
> > > > But this would be a guideline only, and in the end it should be up to
> > > > the driver. Just as long TRY/S_FMT always returns a format.
> > 
> > Well, the currently selected format is irrelevant. The user is obviously
> > requesting something else and the driver should attempt to return something
> > that is at least somewhat close to what it requested. If that's impossible,
> > then falling back to some default format is a good choice.
> > 
> > Does that answer the question?
> 
> Yes it does, and I agree with that. Some drivers return the currently selected 
> format when a non-supported format is requested. I think the spec should be 
> clarified to make it mandatory to return a fixed default format independent of 
> the currently selected format, and non-compliant drivers should be fixed.

I don't know whether it should be mandated. In the end it doesn't matter to the
application: that just wants to get some format that is valid.

It's a good recommendation for drivers, but I do not think that there is anything
wrong as such with drivers that return the current format.

Am I missing something here? Is there any particular advantage of returning a
default fallback format from the point of view of an application?

Regards,

	Hans

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Laurent Pinchart]

On Tuesday 14 August 2012 13:32:43 Hans Verkuil wrote:
> On Tue August 14 2012 13:15:21 Laurent Pinchart wrote:
> > On Tuesday 14 August 2012 13:11:49 Hans Verkuil wrote:
> > > On Tue August 14 2012 13:06:46 Laurent Pinchart wrote:
> > > > On Tuesday 14 August 2012 12:54:34 Hans Verkuil wrote:
> > > > > On Tue August 14 2012 01:54:16 Laurent Pinchart wrote:
> > > > > > On Monday 13 August 2012 14:27:56 Hans Verkuil wrote:
> > > > > > [snip]
> > > > > > 
> > > > > > > 4) What should a driver return in TRY_FMT/S_FMT if the requested
> > > > > > > format is not supported (possible behaviours include returning
> > > > > > > the currently selected format or a default format).
> > > > > > > 
> > > > > > > The spec says this: "Drivers should not return an error code
> > > > > > > unless the input is ambiguous", but it does not explain what
> > > > > > > constitutes an ambiguous input. Frankly, I can't think of any
> > > > > > > and in my opinion TRY/S_FMT should never return an error other
> > > > > > > than EINVAL (if the buffer type is unsupported)or EBUSY (for
> > > > > > > S_FMT if streaming is in progress).
> > > > > > > 
> > > > > > > Returning an error for any other reason doesn't help the
> > > > > > > application since the app will have no way of knowing what to do
> > > > > > > next.
> > > > > > 
> > > > > > That wasn't my point. Drivers should obviously not return an
> > > > > > error. Let's consider the case of a driver supporting YUYV and
> > > > > > MJPEG. If the user calls TRY_FMT or S_FMT with the pixel format
> > > > > > set to RGB565, should the driver return a hardcoded default format
> > > > > > (one of YUYV or MJPEG), or the currently selected format ? In
> > > > > > other words, should the pixel format returned by TRY_FMT or S_FMT
> > > > > > when the requested pixel format is not valid be a fixed default
> > > > > > pixel format, or should it depend on the currently selected pixel
> > > > > > format ?
> > > > > 
> > > > > Actually, in this case I would probably choose a YUYV format that is
> > > > > closest to the requested size. If a driver supports both compressed
> > > > > and uncompressed formats, then it should only select a compressed
> > > > > format if the application explicitly asked for it. Handling
> > > > > compressed formats is more complex than uncompressed formats, so
> > > > > that seems a sensible rule.
> > > > 
> > > > That wasn't my point either :-) YUYV/MJPEG was just an example. You
> > > > can replace MJPEG with UYVY or NV12 above. What I want to know is
> > > > whether TRY_FMT and S_FMT must, when given a non-supported format,
> > > > return a fixed supported format or return a supported format that can
> > > > depend on the currently selected format.
> > > > 
> > > > > The next heuristic I would apply is to choose a format that is
> > > > > closest to the requested size.
> > > > > 
> > > > > So I guess my guidelines would be:
> > > > > 
> > > > > 1) If the pixelformat is not supported, then choose an uncompressed
> > > > > format (if possible) instead.
> > > > > 2) Next choose a format closest to, but smaller than (if possible)
> > > > > the requested size.
> > > > > 
> > > > > But this would be a guideline only, and in the end it should be up
> > > > > to the driver. Just as long TRY/S_FMT always returns a format.
> > > 
> > > Well, the currently selected format is irrelevant. The user is obviously
> > > requesting something else and the driver should attempt to return
> > > something that is at least somewhat close to what it requested. If
> > > that's impossible, then falling back to some default format is a good
> > > choice.
> > > 
> > > Does that answer the question?
> > 
> > Yes it does, and I agree with that. Some drivers return the currently
> > selected format when a non-supported format is requested. I think the
> > spec should be clarified to make it mandatory to return a fixed default
> > format independent of the currently selected format, and non-compliant
> > drivers should be fixed.
>
> I don't know whether it should be mandated. In the end it doesn't matter to
> the application: that just wants to get some format that is valid.
> 
> It's a good recommendation for drivers, but I do not think that there is
> anything wrong as such with drivers that return the current format.
> 
> Am I missing something here? Is there any particular advantage of returning
> a default fallback format from the point of view of an application?

Mostly consistency. I find returning different results for TRY_FMT calls with 
the exact same parameters confusing, both for applications and users.

-- 
Regards,

Laurent Pinchart

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Guennadi Liakhovetski]

On Tue, 14 Aug 2012, Laurent Pinchart wrote:

> On Tuesday 14 August 2012 13:32:43 Hans Verkuil wrote:
> > On Tue August 14 2012 13:15:21 Laurent Pinchart wrote:
> > > On Tuesday 14 August 2012 13:11:49 Hans Verkuil wrote:
> > > > On Tue August 14 2012 13:06:46 Laurent Pinchart wrote:
> > > > > On Tuesday 14 August 2012 12:54:34 Hans Verkuil wrote:
> > > > > > On Tue August 14 2012 01:54:16 Laurent Pinchart wrote:
> > > > > > > On Monday 13 August 2012 14:27:56 Hans Verkuil wrote:
> > > > > > > [snip]
> > > > > > > 
> > > > > > > > 4) What should a driver return in TRY_FMT/S_FMT if the requested
> > > > > > > > format is not supported (possible behaviours include returning
> > > > > > > > the currently selected format or a default format).
> > > > > > > > 
> > > > > > > > The spec says this: "Drivers should not return an error code
> > > > > > > > unless the input is ambiguous", but it does not explain what
> > > > > > > > constitutes an ambiguous input. Frankly, I can't think of any
> > > > > > > > and in my opinion TRY/S_FMT should never return an error other
> > > > > > > > than EINVAL (if the buffer type is unsupported)or EBUSY (for
> > > > > > > > S_FMT if streaming is in progress).
> > > > > > > > 
> > > > > > > > Returning an error for any other reason doesn't help the
> > > > > > > > application since the app will have no way of knowing what to do
> > > > > > > > next.
> > > > > > > 
> > > > > > > That wasn't my point. Drivers should obviously not return an
> > > > > > > error. Let's consider the case of a driver supporting YUYV and
> > > > > > > MJPEG. If the user calls TRY_FMT or S_FMT with the pixel format
> > > > > > > set to RGB565, should the driver return a hardcoded default format
> > > > > > > (one of YUYV or MJPEG), or the currently selected format ? In
> > > > > > > other words, should the pixel format returned by TRY_FMT or S_FMT
> > > > > > > when the requested pixel format is not valid be a fixed default
> > > > > > > pixel format, or should it depend on the currently selected pixel
> > > > > > > format ?
> > > > > > 
> > > > > > Actually, in this case I would probably choose a YUYV format that is
> > > > > > closest to the requested size. If a driver supports both compressed
> > > > > > and uncompressed formats, then it should only select a compressed
> > > > > > format if the application explicitly asked for it. Handling
> > > > > > compressed formats is more complex than uncompressed formats, so
> > > > > > that seems a sensible rule.
> > > > > 
> > > > > That wasn't my point either :-) YUYV/MJPEG was just an example. You
> > > > > can replace MJPEG with UYVY or NV12 above. What I want to know is
> > > > > whether TRY_FMT and S_FMT must, when given a non-supported format,
> > > > > return a fixed supported format or return a supported format that can
> > > > > depend on the currently selected format.
> > > > > 
> > > > > > The next heuristic I would apply is to choose a format that is
> > > > > > closest to the requested size.
> > > > > > 
> > > > > > So I guess my guidelines would be:
> > > > > > 
> > > > > > 1) If the pixelformat is not supported, then choose an uncompressed
> > > > > > format (if possible) instead.
> > > > > > 2) Next choose a format closest to, but smaller than (if possible)
> > > > > > the requested size.
> > > > > > 
> > > > > > But this would be a guideline only, and in the end it should be up
> > > > > > to the driver. Just as long TRY/S_FMT always returns a format.
> > > > 
> > > > Well, the currently selected format is irrelevant. The user is obviously
> > > > requesting something else and the driver should attempt to return
> > > > something that is at least somewhat close to what it requested. If
> > > > that's impossible, then falling back to some default format is a good
> > > > choice.
> > > > 
> > > > Does that answer the question?
> > > 
> > > Yes it does, and I agree with that. Some drivers return the currently
> > > selected format when a non-supported format is requested. I think the
> > > spec should be clarified to make it mandatory to return a fixed default
> > > format independent of the currently selected format, and non-compliant
> > > drivers should be fixed.
> >
> > I don't know whether it should be mandated. In the end it doesn't matter to
> > the application: that just wants to get some format that is valid.
> > 
> > It's a good recommendation for drivers, but I do not think that there is
> > anything wrong as such with drivers that return the current format.
> > 
> > Am I missing something here? Is there any particular advantage of returning
> > a default fallback format from the point of view of an application?
> 
> Mostly consistency. I find returning different results for TRY_FMT calls with 
> the exact same parameters confusing, both for applications and users.

We've discussed this issue privately with Laurent before, and my opinion 
was rather to go with the currently configured format. The advantage of 
this would be, that situations, when a user has configured some format and 
then is trying to switch to an unsupported format, and instead the driver 
switches to a 3rd format, instead of keeping the current one, would be 
avoided.

OTOH, it seems a good idea to whenever possible return the same result in 
reply to the same request, in this case to TRY_FMT. And it also seems 
logical to have S_FMT do the same thing as TRY_FMT... So, this argument 
seems stronger than my original one... Just one request - don't insist on 
immediate conversion of existing drivers;-)

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Laurent Pinchart]

Hi Guennadi,

On Tuesday 14 August 2012 23:14:18 Guennadi Liakhovetski wrote:
> On Tue, 14 Aug 2012, Laurent Pinchart wrote:
> > On Tuesday 14 August 2012 13:32:43 Hans Verkuil wrote:
> > > On Tue August 14 2012 13:15:21 Laurent Pinchart wrote:
> > > > On Tuesday 14 August 2012 13:11:49 Hans Verkuil wrote:
> > > > > On Tue August 14 2012 13:06:46 Laurent Pinchart wrote:
> > > > > > On Tuesday 14 August 2012 12:54:34 Hans Verkuil wrote:
> > > > > > > On Tue August 14 2012 01:54:16 Laurent Pinchart wrote:
> > > > > > > > On Monday 13 August 2012 14:27:56 Hans Verkuil wrote:
> > > > > > > > [snip]
> > > > > > > > 
> > > > > > > > > 4) What should a driver return in TRY_FMT/S_FMT if the
> > > > > > > > > requested format is not supported (possible behaviours
> > > > > > > > > include returning the currently selected format or a default
> > > > > > > > > format).
> > > > > > > > > 
> > > > > > > > > The spec says this: "Drivers should not return an error code
> > > > > > > > > unless the input is ambiguous", but it does not explain what
> > > > > > > > > constitutes an ambiguous input. Frankly, I can't think of
> > > > > > > > > any and in my opinion TRY/S_FMT should never return an error
> > > > > > > > > other than EINVAL (if the buffer type is unsupported)or
> > > > > > > > > EBUSY (for S_FMT if streaming is in progress).
> > > > > > > > > 
> > > > > > > > > Returning an error for any other reason doesn't help the
> > > > > > > > > application since the app will have no way of knowing what
> > > > > > > > > to do next.
> > > > > > > > 
> > > > > > > > That wasn't my point. Drivers should obviously not return an
> > > > > > > > error. Let's consider the case of a driver supporting YUYV and
> > > > > > > > MJPEG. If the user calls TRY_FMT or S_FMT with the pixel
> > > > > > > > format set to RGB565, should the driver return a hardcoded
> > > > > > > > default format (one of YUYV or MJPEG), or the currently
> > > > > > > > selected format ? In other words, should the pixel format
> > > > > > > > returned by TRY_FMT or S_FMT when the requested pixel format
> > > > > > > > is not valid be a fixed default pixel format, or should it
> > > > > > > > depend on the currently selected pixel format ?
> > > > > > > 
> > > > > > > Actually, in this case I would probably choose a YUYV format
> > > > > > > that is closest to the requested size. If a driver supports both
> > > > > > > compressed and uncompressed formats, then it should only select
> > > > > > > a compressed format if the application explicitly asked for it.
> > > > > > > Handling compressed formats is more complex than uncompressed
> > > > > > > formats, so that seems a sensible rule.
> > > > > > 
> > > > > > That wasn't my point either :-) YUYV/MJPEG was just an example.
> > > > > > You can replace MJPEG with UYVY or NV12 above. What I want to know
> > > > > > is whether TRY_FMT and S_FMT must, when given a non-supported
> > > > > > format, return a fixed supported format or return a supported
> > > > > > format that can depend on the currently selected format.
> > > > > > 
> > > > > > > The next heuristic I would apply is to choose a format that is
> > > > > > > closest to the requested size.
> > > > > > > 
> > > > > > > So I guess my guidelines would be:
> > > > > > > 
> > > > > > > 1) If the pixelformat is not supported, then choose an
> > > > > > > uncompressed format (if possible) instead.
> > > > > > > 2) Next choose a format closest to, but smaller than (if
> > > > > > > possible) the requested size.
> > > > > > > 
> > > > > > > But this would be a guideline only, and in the end it should be
> > > > > > > up to the driver. Just as long TRY/S_FMT always returns a
> > > > > > > format.
> > > > > 
> > > > > Well, the currently selected format is irrelevant. The user is
> > > > > obviously requesting something else and the driver should attempt to
> > > > > return something that is at least somewhat close to what it
> > > > > requested. If that's impossible, then falling back to some default
> > > > > format is a good choice.
> > > > > 
> > > > > Does that answer the question?
> > > > 
> > > > Yes it does, and I agree with that. Some drivers return the currently
> > > > selected format when a non-supported format is requested. I think the
> > > > spec should be clarified to make it mandatory to return a fixed
> > > > default format independent of the currently selected format, and non-
> > > > compliant drivers should be fixed.
> > > 
> > > I don't know whether it should be mandated. In the end it doesn't matter
> > > to the application: that just wants to get some format that is valid.
> > > 
> > > It's a good recommendation for drivers, but I do not think that there is
> > > anything wrong as such with drivers that return the current format.
> > > 
> > > Am I missing something here? Is there any particular advantage of
> > > returning a default fallback format from the point of view of an
> > > application?
> > 
> > Mostly consistency. I find returning different results for TRY_FMT calls
> > with the exact same parameters confusing, both for applications and
> > users.
>
> We've discussed this issue privately with Laurent before, and my opinion
> was rather to go with the currently configured format. The advantage of
> this would be, that situations, when a user has configured some format and
> then is trying to switch to an unsupported format, and instead the driver
> switches to a 3rd format, instead of keeping the current one, would be
> avoided.
> 
> OTOH, it seems a good idea to whenever possible return the same result in
> reply to the same request, in this case to TRY_FMT. And it also seems
> logical to have S_FMT do the same thing as TRY_FMT... So, this argument
> seems stronger than my original one... Just one request - don't insist on
> immediate conversion of existing drivers;-)

I'll consider "please submit a patch" as a very valid answer to any conversion 
request in the near future :-)

-- 
Regards,

Laurent Pinchart

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Hans de Goede]

Hi,

On 08/14/2012 12:54 PM, Hans Verkuil wrote:
> On Tue August 14 2012 01:54:16 Laurent Pinchart wrote:
>> Hi Hans,
>>
>> On Monday 13 August 2012 14:27:56 Hans Verkuil wrote:
>>> Hi all!
>>>
>>> As part of the 2012 Kernel Summit V4L2 workshop I will be discussing a bunch
>>> of V4L2 ambiguities/improvements.
>>>
>>> I've made a list of all the V4L2 issues and put them in two categories:
>>> issues that I think are easy to resolve (within a few minutes at most), and
>>> those that are harder.
>>>
>>> If you think I put something in the easy category that you believe is
>>> actually hard, then please let me know.
>>>
>>> If you attend the workshop, then please read through this and think about it
>>> a bit, particularly for the second category.
>>>
>>> If something is unclear, or you think another topic should be added, then
>>> let me know as well.
>>>
>>> Easy:
>>
>> [snip]
>>
>>> 4) What should a driver return in TRY_FMT/S_FMT if the requested format is
>>> not supported (possible behaviours include returning the currently selected
>>> format or a default format).
>>>
>>>     The spec says this: "Drivers should not return an error code unless the
>>> input is ambiguous", but it does not explain what constitutes an ambiguous
>>> input. Frankly, I can't think of any and in my opinion TRY/S_FMT should
>>> never return an error other than EINVAL (if the buffer type is unsupported)
>>> or EBUSY (for S_FMT if streaming is in progress).
>>>
>>>     Returning an error for any other reason doesn't help the application
>>> since the app will have no way of knowing what to do next.
>>
>> That wasn't my point. Drivers should obviously not return an error. Let's
>> consider the case of a driver supporting YUYV and MJPEG. If the user calls
>> TRY_FMT or S_FMT with the pixel format set to RGB565, should the driver return
>> a hardcoded default format (one of YUYV or MJPEG), or the currently selected
>> format ? In other words, should the pixel format returned by TRY_FMT or S_FMT
>> when the requested pixel format is not valid be a fixed default pixel format,
>> or should it depend on the currently selected pixel format ?
>
> Actually, in this case I would probably choose a YUYV format that is closest
> to the requested size. If a driver supports both compressed and uncompressed
> formats, then it should only select a compressed format if the application
> explicitly asked for it. Handling compressed formats is more complex than
> uncompressed formats, so that seems a sensible rule.
>
> The next heuristic I would apply is to choose a format that is closest to the
> requested size.

Size as in resolution or size as in bpp?

> So I guess my guidelines would be:
>
> 1) If the pixelformat is not supported, then choose an uncompressed format
> (if possible) instead.
> 2) Next choose a format closest to, but smaller than (if possible) the
> requested size.
>
> But this would be a guideline only, and in the end it should be up to the
> driver. Just as long TRY/S_FMT always returns a format.

I think we're making this way too complicated. I agree that TRY/S_FMT should
always returns a format and not EINVAL, but other then that lets just document
that if the driver does not know the passed in format it should return a default
format and not make this dependent on the passed in fmt, esp. since otherwise
the driver would need to know about all formats it does not support to best map
that to a one which it does support, which is just crazy.

So I suggest adding the following to the spec:

When a driver receives an unsupported pixfmt as input on a TRY/S_FMT call it
should replace this with a default pixfmt, independent of input pixfmt and
current driver state. Preferably a driver uses a well known uncompressed
pixfmt as its default.

Regards,

Hans

Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Chinmay V S]

On Tue, Aug 14, 2012 at 6:13 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
>
> On 08/14/2012 12:54 PM, Hans Verkuil wrote:
>>
>> On Tue August 14 2012 01:54:16 Laurent Pinchart wrote:
>>>
>>> Hi Hans,
>>>
>>> On Monday 13 August 2012 14:27:56 Hans Verkuil wrote:
>>>>
>>>> Hi all!
>>>>
>>>> As part of the 2012 Kernel Summit V4L2 workshop I will be discussing a
>>>> bunch
>>>> of V4L2 ambiguities/improvements.
>>>>
>>>> I've made a list of all the V4L2 issues and put them in two categories:
>>>> issues that I think are easy to resolve (within a few minutes at most),
>>>> and
>>>> those that are harder.
>>>>
>>>> If you think I put something in the easy category that you believe is
>>>> actually hard, then please let me know.
>>>>
>>>> If you attend the workshop, then please read through this and think
>>>> about it
>>>> a bit, particularly for the second category.
>>>>
>>>> If something is unclear, or you think another topic should be added,
>>>> then
>>>> let me know as well.
>>>>
>>>> Easy:
>>>
>>>
>>> [snip]
>>>
>>>> 4) What should a driver return in TRY_FMT/S_FMT if the requested format
>>>> is
>>>> not supported (possible behaviours include returning the currently
>>>> selected
>>>> format or a default format).
>>>>
>>>>     The spec says this: "Drivers should not return an error code unless
>>>> the
>>>> input is ambiguous", but it does not explain what constitutes an
>>>> ambiguous
>>>> input. Frankly, I can't think of any and in my opinion TRY/S_FMT should
>>>> never return an error other than EINVAL (if the buffer type is
>>>> unsupported)
>>>> or EBUSY (for S_FMT if streaming is in progress).
>>>>
>>>>     Returning an error for any other reason doesn't help the application
>>>> since the app will have no way of knowing what to do next.
>>>
>>>
>>> That wasn't my point. Drivers should obviously not return an error. Let's
>>> consider the case of a driver supporting YUYV and MJPEG. If the user
>>> calls
>>> TRY_FMT or S_FMT with the pixel format set to RGB565, should the driver
>>> return
>>> a hardcoded default format (one of YUYV or MJPEG), or the currently
>>> selected
>>> format ? In other words, should the pixel format returned by TRY_FMT or
>>> S_FMT
>>> when the requested pixel format is not valid be a fixed default pixel
>>> format,
>>> or should it depend on the currently selected pixel format ?
>>
>>
>> Actually, in this case I would probably choose a YUYV format that is
>> closest
>> to the requested size. If a driver supports both compressed and
>> uncompressed
>> formats, then it should only select a compressed format if the application
>> explicitly asked for it. Handling compressed formats is more complex than
>> uncompressed formats, so that seems a sensible rule.
>>
>> The next heuristic I would apply is to choose a format that is closest to
>> the
>> requested size.
>
>
> Size as in resolution or size as in bpp?
>
>
>> So I guess my guidelines would be:
>>
>> 1) If the pixelformat is not supported, then choose an uncompressed format
>> (if possible) instead.
>> 2) Next choose a format closest to, but smaller than (if possible) the
>> requested size.
>>
>> But this would be a guideline only, and in the end it should be up to the
>> driver. Just as long TRY/S_FMT always returns a format.
>
>
> I think we're making this way too complicated. I agree that TRY/S_FMT should
> always returns a format and not EINVAL, but other then that lets just
> document
> that if the driver does not know the passed in format it should return a
> default
> format and not make this dependent on the passed in fmt, esp. since
> otherwise
> the driver would need to know about all formats it does not support to best
> map
> that to a one which it does support, which is just crazy.
>
> So I suggest adding the following to the spec:
>
> When a driver receives an unsupported pixfmt as input on a TRY/S_FMT call it
> should replace this with a default pixfmt, independent of input pixfmt and
> current driver state. Preferably a driver uses a well known uncompressed
> pixfmt as its default.
>
>
> Regards,
>
> Hans
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Consistent results for TRY_FMT calls with the exact same parameters
seems proper from an application's perspective.

One reason why anyone would want the driver to return the current
format would be if there is some penalty associated with switching
formats in the driver/hardware. Currently, if one expects to avoid
such a penalty, one can always explicitly code for that in the
application by calling G_FMT rather than solely depending on the
result of TRY_FMT.

regards
CVS