Hi there, So I noticed that one of the "V4L2 ambiguities" discussed at the Media Workshop relates to expected behavior with TRY_FMT/S_FMT. Specifically (from http://www.linuxtv.org/news.php?entry=2012-12-28.mchehab):
=== 1.4. Unsupported formats in TRY_FMT/S_FMT What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviors 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. 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). Should we make a recommendation whether the currently selected format or a default format should be returned? One proposal is to just return a default format if the requested pixelformat is unsupported. Returning the currently selected format leads to inconsistent results. Results: TRY_FMT/S_FMT should never return an error when the requested format is not supported. Drivers should always return a valid format, preferably a format that is as widely supported by applications as possible. Both TRY_FMT and S_FMT should have the same behaviour. Drivers should not return different formats when getting the same input parameters. The format returned should be a driver default format if possible (stateless behaviour) but can be stateful if needed. The API spec should let clear that format retuns may be different when different video inputs (or outputs) are selected. === Note that this will cause ABI breakage with existing applications. If an application expects an error condition to become aware that the requested format was not supported, that application will silently think the requested format was valid but in fact the driver is returning data in some other format. Tvtime (one of the more popular apps for watching analog television) is one such application that will broken. http://git.linuxtv.org/tvtime.git/blob/HEAD:/src/videoinput.c#l452 If YUVY isn't supported but UYVY is (for example, with the Hauppauge HVR-950q), the application will think it's doing YUYV when in fact the driver is returning UYVY. MythTV is a little better (it does ultimately store the format returned by the driver), however even there it depends on an error being returned in order to know to do userland format conversion. https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythtv/recorders/NuppelVideoRecorder.cpp#L1367 Now it would be quite simple to change tvtime to use the expected behavior, but if backward compatibility with the ABI is of paramount importance, then we cannot proceed with this change as proposed. Don't misunderstand me - if I were inventing the API today then the proposed approach is what I would recommend - but since these parts of the ABI are something like ten years old, we have to take into account legacy applications. Discussion is welcome. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
