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

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

 



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

--
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