On Thu, 8 Jan 2009, Mauro Carvalho Chehab wrote: > 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. Aha! Great! At last - all doubts resolved, life is beautiful again - thanks Mauro!:-) Now, let me guess, whether all applications understand it that way too... Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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
