On Tuesday 14 August 2012 13:32:43 Hans Verkuil wrote: > On Tue August 14 2012 13:15:21 Laurent Pinchart wrote: > > On Tuesday 14 August 2012 13:11:49 Hans Verkuil wrote: > > > On Tue August 14 2012 13:06:46 Laurent Pinchart wrote: > > > > On Tuesday 14 August 2012 12:54:34 Hans Verkuil wrote: > > > > > On Tue August 14 2012 01:54:16 Laurent Pinchart wrote: > > > > > > On Monday 13 August 2012 14:27:56 Hans Verkuil 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. > > > > > > > > > > > > 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. > > > > > > > > That wasn't my point either :-) YUYV/MJPEG was just an example. You > > > > can replace MJPEG with UYVY or NV12 above. What I want to know is > > > > whether TRY_FMT and S_FMT must, when given a non-supported format, > > > > return a fixed supported format or return a supported format that can > > > > depend on the currently selected format. > > > > > > > > > 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. > > > > > > Well, the currently selected format is irrelevant. The user is obviously > > > requesting something else and the driver should attempt to return > > > something that is at least somewhat close to what it requested. If > > > that's impossible, then falling back to some default format is a good > > > choice. > > > > > > Does that answer the question? > > > > Yes it does, and I agree with that. Some drivers return the currently > > selected format when a non-supported format is requested. I think the > > spec should be clarified to make it mandatory to return a fixed default > > format independent of the currently selected format, and non-compliant > > drivers should be fixed. > > I don't know whether it should be mandated. In the end it doesn't matter to > the application: that just wants to get some format that is valid. > > It's a good recommendation for drivers, but I do not think that there is > anything wrong as such with drivers that return the current format. > > Am I missing something here? Is there any particular advantage of returning > a default fallback format from the point of view of an application? Mostly consistency. I find returning different results for TRY_FMT calls with the exact same parameters confusing, both for applications and users. -- 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
