Hi Sylwester On Tue, 18 Sep 2012, Sylwester Nawrocki wrote: > Hi All, > > I'm trying to fulfil following requirements with V4L2 API that are specific > to most of Samsung camera sensors with embedded SoC ISP and also for local > SoC camera ISPs: > > - separate pixel format and pixel resolution needs to be configured > in a device for camera preview and capture; Nice to see this topic come to light again:-) You certainly remember this short discussion http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/40126 and preceding threads, where various related ideas have been discussed, I think, we already discussed this back in Warsaw and before that on the ML. So, I hope, this time we have a valid use-case for these contexts and they finally can be brought to an upstreamable implementation:-) Good luck! Guennadi > > - there is a need to set capture or preview mode in a device explicitly > as it makes various adjustments (in firmware) in each operation mode > and controls external devices accordingly (e.g. camera Flash); > > - some devices have more than two use case specific contexts that a user > needs to choose from, e.g. video preview, video capture, still preview, > still capture; for each of these modes there are separate settings, > especially pixel resolution and others corresponding to existing v4l2 > controls; > > - some devices can have two processing contexts enabled simultaneously, > e.g. a sensor emitting YUYV and JPEG streams simultaneously (please see > discussion [1]). > > This makes me considering making the v4l2 subdev (and maybe v4l2 controls) > API processing (capture) context aware. > > If I remember correctly introducing processing context, as the per file > handle device contexts in case of mem-to-mem devices was considered bad > idea in past discussions. But this was more about v4ll2 video nodes. > > And I was considering adding context only to v4l2 subdev API, and possibly > to the (extended) control API. The idea is to extend the subdev (and > controls ?) ioctls so it is possible to preconfigure sets of parameters > on subdevs, while V4L2 video node parameters would be switched "manually" > by applications to match a selected subdevs contest. There would also be > needed an API to select specific context (e.g. a control), or maybe > multiple contexts like in case of a sensor from discussion [1]. > > I've seen various hacks in some v4l2 drivers trying to fulfil above > requirements, e.g. abusing struct v4l2_mbus_framefmt::colorspace field > to select between capture/preview in a device or using 32-bit integer > control where upper 16-bits are used for pixel width and lower 16 for > pixel height. This may suggest there something missing at the API. > > Any suggestions, critics, please ?... :) > > -- > > Regards, > Sylwester > > [1] http://www.mail-archive.com/linux-media@xxxxxxxxxxxxxxx/msg42707.html > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
