Implement the video control framework with the following features:
- Drivers initialize the control with a valid value range at boot which
guides the application developer and the framework. Hence, the video
framework could do all common works for drivers e.g., sanity check.
- Controls need to be cached to memory. Video framework handles
get_ctrl(), drivers don't need to implement this API. It is because
reading control value directly from registers are not only inefficient
but also sometimes impossible, e.g. controls that scatter through
several registers. Only "volatile" control needs to be updated at
runtime.
- Only the devices (e.g., sensors) owning the controls need to
implement set_ctrl(). Other devices of the pipeline do not need to
propagate set_ctrl() and hence, do not need to implement this API
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
Use a video control ID in the private range rather than using an existing
CID, as the emulated imager does not effectively applies these properties
to the image feed and are just for API test purpose.
Signed-off-by: Josuah Demangeon <me@josuah.net>
Only store a single line of the full frame. This allows to support a
large enough frame size to remove the Kconfig option, which simplifies
the implementation (fewer checks needed).
Signed-off-by: Josuah Demangeon <me@josuah.net>
This PR fixes a blocking call to video_buffer_alloc in case of memory
shortage by addign a timeout parameter to the API.
Signed-off-by: Armin Kessler <ake@espros.com>
Add a new implementation of a test pattern generator, with the same
architecture as real drivers: split receiver core and
I2C-controlled sub-device, with changes of video format in
"zephyr,emul-imager" leads to different data produced by
"zephyr,emul-rx".
Signed-off-by: Josuah Demangeon <me@josuah.net>
Introduce a video_get_format_index() utility to help finding a caps
entry out of a given format. Introduce several utilities to seek and
apply frame intervals.
Signed-off-by: Josuah Demangeon <me@josuah.net>
