Description
Is your enhancement proposal related to a problem? Please describe.
Add link frequencies, blanking duration, flip-aware pixel format, possibly more essential elements of Linux V4L2/Media.
Describe the solution you'd like
Image sensors are not the ideal place for processing data, and the tendency is to move all the image processing from the sensor to the associated SoC or an FPGA or a dedicated ISP chip.
For these sensors, the complexity of the situation is not handled by the sensor itself but by the controlling hardware, which needs a more structured model to better handle the complexity that was hidden.
MT9M114, OV2640, OV5640, OV7670, OV7725, GC2145 all give already-corrected data out in RGB565 or YUYV. Complexity is hidden inside.
IMX219, IMX335 (and more to come) are PRs for sensors with raw bayer output, and their integration can be helped by a more structured API, opening the road for custom IPA/3A (auto-exposure, auto-focus, auto-white-balance, etc.).
Describe alternatives you've considered
Compromises: simplified APIs to help sensors with built-in ISP (easier to use) without compromising the simple sensors with bayer output (more complex drivers).
Additional context
A discussion will introduce the roadmap for bringing some elements of libcamera on Zephyr and extras to build custom ISPs. This present issue is only about the driver API itself.
A supposedly recent and frequently maintained Linux driver to take example from could be the generic CCS driver:
Or various image sensors that have a recent copyright date (2023, 2024, 2025) such as: