The Zephyr community came together at Open Source Summit India 2026 in Mumbai to share knowledge and explore developments, tooling, and real-world applications across embedded systems.
In this second post event blog, we recap two lightning talks from the Zephyr track focused on camera support. One explored the architectural changes needed for Zephyr to support AI-driven camera workloads, while the other compared the camera frameworks in Zephyr and Linux and discussed potential enhancements for more advanced vision applications.
Lightning Talk: If Zephyr Wants To Power AI Cameras, What Must Change? – Rutvij Trivedi, Silicon Signals Pvt. Ltd.
Rutvij Trivedi explored what needs to change in Zephyr’s camera and driver architecture to support real-world AI vision applications. Cameras are no longer used only to capture pictures or video. They are becoming real-time data pipelines that send frames and related information to image signal processors (ISPs), neural processing units (NPUs), and control systems.
While Zephyr provides deterministic behavior and efficient embedded control, AI camera workloads introduce additional requirements. These include zero-copy buffer sharing, coordination between accelerators, bounded latency, frame-level metadata synchronization, controlled backpressure, and predictable streaming states.
Based on the Silicon Signals team’s experience with Linux media pipelines and embedded camera development, Rutvij highlighted limitations in traditional RTOS-style camera models. Zephyr’s current video framework does not provide enough information to track the metadata and AI inference results associated with individual frames. This can cause processing results, such as object-detection boxes, to be applied to the wrong frame.
The session presented two proposed enhancements. The first would attach metadata, ISP statistics, and inference results to individual video buffers. The second would introduce per-buffer callbacks, allowing frames to move between pipeline stages without repeatedly waking the CPU. These changes could improve buffer ownership, reduce processing overhead, and make camera pipelines easier to monitor and manage.
The proposed changes are currently being explored through prototypes and community discussions. The goal is not to reproduce all the features of the Linux camera subsystem, but to introduce simple and lightweight abstractions that could help Zephyr support advanced AI cameras in robotics, industrial, and mission-critical systems.
Lightning Talk: Strengthening Zephyr’s Camera Framework: Architecture Review and Enhancements – Elgin Perumbilly & Ankit Siddhapura, Silicon Signals Pvt LTD
Elgin Perumbilly and Ankit Siddhapura examined how camera support is structured in Zephyr and compared it with the Linux kernel camera subsystem. Zephyr prioritizes real-time behavior, low memory usage, and a simple system design, making it suitable for small and low-power vision devices. Linux, through frameworks such as Video4Linux2 and the Media Controller subsystem, provides a more structured and scalable architecture for complex pipelines, multiple cameras, and advanced image processing.
Drawing on their practical experience with camera products, different chipsets, and operating systems, the speakers identified two areas where Zephyr’s camera framework could be strengthened: runtime power management for camera drivers and status flags for individual video buffers.
The first enhancement focused on power efficiency. When a camera stream is stopped, the sensor may stop capturing images while its clocks and regulators remain active, continuing to consume power. The proposed runtime power-management support would suspend the sensor and disable unnecessary resources when it is not being used. The device would then resume automatically when streaming begins again. This could reduce power consumption, extend battery life, and improve thermal efficiency. The team implemented power-management callbacks in an IMX335 camera driver and tested the approach on STM32N6 hardware.
The second enhancement involved adding status flags to video buffers. These flags would allow applications to identify whether a frame is valid, incomplete, or contains partial data. The speakers noted that more design discussions are needed to determine how Zephyr should handle incomplete or fragmented frames while considering the limitations of resource-constrained devices.
The session highlighted the architectural trade-offs between Zephyr and Linux and showed how Zephyr’s camera framework could evolve toward more advanced and scalable vision capabilities. The aim is to learn from Linux’s structured approach while preserving Zephyr’s lightweight design, predictable real-time behavior, and suitability for resource-constrained systems.
Together, these sessions highlighted areas where Zephyr’s camera framework could evolve to support more advanced embedded vision and AI applications. The proposed improvements included frame-level metadata, per-buffer callbacks, runtime power management, and buffer status flags.
Both talks drew lessons from Linux camera frameworks while emphasizing that the goal is not to reproduce Linux in Zephyr. Instead, the focus is on introducing lightweight improvements that preserve Zephyr’s real-time behavior, low memory usage, and simple design while enabling more efficient and predictable camera pipelines on resource-constrained devices.