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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux