OSS + ELC EU 2026

Camera sensors are evolving beyond single-stream models to generate multiple concurrent streams like RGB+IR video and embedded metadata alongside image data. Supporting these sensors in Linux introduces new challenges for the V4L2 and media controller subsystem, particularly around per-stream configuration and stream identification.

This talk presents two practical use cases for enabling multi-stream cameras in Linux. First, RGB+IR sensor support through V4L2 control framework extensions using array-based controls, enabling independent per-stream configuration while preserving a unified sensor model. Second, sensors transmitting embedded metadata, leveraging RAW sensor model proposed by Sakari Ailus, internal pads for metadata propagation, and data-type filtering in V4L2 bridge drivers to separate and route metadata and image streams.

Ref (lkml) : [PATCH v11 00/66] Generic line based metadata support, internal pads

These concepts are demonstrated through POC implementations on TI AM62A platform using OV2312 and IMX219 sensors, with integration into GStreamer and libcamera.

Attendees will gain practical insight into Linux multi-stream camera sensor implementation

Most Allwinner based products still runs on vendor BSP kernels with out-of-tree display drivers. But with recent upstream Linux Kernel improvements, its now possible to simultaneously drive multiple display panels over different interfaces like LVDS and MIPI, using mainline DRM subsystem on Allwinner A133 and A523 SoCs.

In this talk, I will share my experience bringing up a multi-display setup with 2 x LVDS and 1 x MIPI panels on Allwinner A133 using upstream kernel [1] and [2]. We will go through how the Allwinner display engine works, what the device tree topology looks like when you have multiple active display pipelines, and what DRM/KMS changes matters to get this working correctly.

We will also look at the userspace side - how a compositor like Weston handles multi-display and the limitations you hit in practice. I will cover some of the real problems I hit during bringup, not just the happy path.

[1]: https://lore.kernel.org/linux-sunxi/[email protected]/
[2]: https://lore.kernel.org/linux-sunxi/[email protected]/

Modern camera use cases are realized by complex pipelines of several IPs blocks that process frames produced by an image sensor to deliver great looking images to applications.

Support for the most advanced use cases is implemented by time-multiplexing the underlying hardware resources, performing job scheduling at the hardware/firmware level and orchestrating the image processing steps across multiple drivers and IPs.

The Video4Linux2 kernel subsystem currently doesn't provide any abstraction for drivers and applications to fully support modern designs and vendors that intend to make use of the capabilities of their hardware had so far worked around this
limitations by implementing downstream solutions.

This talk describes the most recent and the forthcoming developments in the Video4Linux2 kernel framework to support modern camera use cases, including but not limited to multi-driver pipelines, multi-context time multiplexing of hardware resources and job scheduling, with practical examples from the field on recent SoC designs.

Until recently camera software stacks have mainly been a proprietary closed source affair. Thanks to the linux-media and libcamera communities this has been slowly changing.

We are happy to present the first Free and Open Source Software stack for a Qualcomm camera hardware ISP, the Offline Processing Engine found on the QRB2210 (Agatti) SoC used on the Arduino UNO Q SBC. Using a standard mainline V4L2 ISP kernel driver together with libcamera.

This talk will cover the following topics:

* Overview of the Qualcomm camera subsystem architecture
* Mainline V4L2 ISP kernel driver for the Agatti OPE block
* CAMSS libcamera pipeline-handler and camss IPA for OPE
* Image processing steps supported by the presented FOSS stack
* Future plans for more image processing steps
* Future plans for supporting the ISP on other Qualcomm SoCs

An exploration into the complexities of physically connecting cameras to your embedded development board, and configuring them through device tree, and hopefully how we can make it easier in the future!


Small board computers are now prolific with their ability to connect RAW MIPI cameras directly to the board, and now that libcamera provides an open camera stack, connecting cameras to all your favourite boards should be easy.

But it's not. The connectors might have 15, 22 or 30 pins. The functions of each pin differ between boards. There's TypeA and TypeB cables.... And they better not be too long!

The lack of standardisation means it can still be difficult to connect your camera, and the combinatorial explosion of potential device tree overlays will soon become unmaintainable.

Lets look at suggestions that have been around for a decade already, and where that work is now leading to make connecting cameras easier!

RISC-V is evolving into a capable desktop replacement, driven by boards like the Lichee Pi 4A, but a major barrier remains: the lack of a fully open, upstream graphics stack.

This talk explores enabling hardware accelerated graphics on modern RISC-V SoCs by extending the open source Imagination PowerVR driver for the TH1520. We dive into the architectural challenges of this port, including the complex power sequencing that necessitated the new pwrseq-thead-gpu driver. We break down how the kernel DRM driver interacts with the Mesa PVR Vulkan driver, and how leveraging the Zink translation layer finally brings standard OpenGL desktop acceleration to the platform. Finally, we cover the current mainline status and next steps for the StarFive JH7110 display controller integration.

Key Takeaways / What Attendees Will Learn:
- Porting the open PowerVR driver to the RISC-V TH1520 SoC.
- Implementing kernel power sequencing (pwrseq) for complex GPU domains.
- Interacting between DRM, Mesa Vulkan, and Zink for desktop GL support.
- Current mainline status of the JH7110 Display Controller.

https://mwilczynski.dev/posts/riscv-gpu-zink/

WPE WebKit is the WebKit port for Linux-based embedded devices, powering Web-based user interfaces on platforms such as set-top boxes, smart appliances, and industrial systems. With the 2.54 release, a stable version of the new WPEPlatform API is now available, radically simplifying how the Web engine is embedded: thanks to built-in support for Wayland, DRM/KMS, and headless rendering, libwpe and external backends are no longer needed unless you target a different platform. Zero-copy buffer sharing via DMA-BUF is also available for efficient video and graphics pipelines on modern Linux kernels and supported platforms.

After a quick introduction to WPE WebKit, the session will demonstrate the new API in practice, showing how simple it has become to write a custom launcher to run Web-based applications on embedded devices. It will also offer practical guidance for migrating existing integrations to WPEPlatform, whether they are based on Cog or built directly on the legacy API.

Whether you are evaluating WPE for the first time or maintain devices already shipping it and wonder what it means for you, this talk will help you get started with the next generation of the WPE public API.

This talk offers a comprehensive look at what's changed in the embedded Linux world over the past year. Walt will walk through the latest kernel developments most relevant to embedded developers, survey key userspace projects shaping modern embedded designs, and cover the broader community, industry, and legal landscape — from the status of major processor architectures to initiatives at the Linux Foundation and beyond.

Whether you're tracking changes to subsystems you already rely on or looking for new tools and techniques to improve your workflow, this session will help you stay current in a fast-moving ecosystem. Come find out what's new, what's shifting, and what it means for your embedded Linux work.