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