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