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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
