On Wed, 7 Jan 2009 10:14:31 +0100 (CET) Guennadi Liakhovetski <g.liakhovetski@xxxxxx> wrote: > Hi all > > I have been guessing around these operations for a while now, and > eventually have decided to ask. > > My current understanding is, that S_FMT in terms of window geometry should > (ideally) set user window sizes, while the view area should preferably be > kept maximum, i.e., it should scale, if supported. Yes. However, if you cannot scale to that resolution, you should return -EINVAL. > For example on mt9t031 > binning and skipping are used for that. Whereas CROP uses the current > scaling configuration and selects a sub-window, so, once you've done S_FMT > to 320x240, a crop request for 640x480 might well fail. I also understand this way. You cannot crop with a resolution bigger than what you've selected. > For this you have > to issue a S_FMT, i.e., change scaling. Or would one have to re-scale > transparently? > > Is this interpretation correct? It seems to reflect the API as documented > on http://v4l2spec.bytesex.org/spec/book1.htm correctly. > > If it is correct, then what should CROP_CAP return as maximum supported > window sizes? Should it return them according to the current scaling or > according to scale 1? I understand that it should return against the current scaling. Cheers, Mauro -- 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
