About Me

I've written media-related Linux drivers for consumer and embedded devices since 2001 and I'm one of the Video4Linux core developers. I've given Linux media-related talks at the FOSDEM, LPC and ELC. I currently work as an embedded Linux consultant through my company Ideas on Board where I develop a wide range of embedded drivers including DRM/KMS and V4L2.

Project Details

The Media Controller kernel API has been designed to exposing detailed information about media devices, and video capture devices in particular, to userspace. While the API is not limited to a particular type of device, it has so far been used mostly to expose the topology of complex embedded media devices to applications, allowing a fine-grained control over the device that wasn't possible through the V4L API alone.

Handling those devices in userspace isn't simple due to the hardware complexity. Careful testing of applications and userspace libraries is thus needed, especially when they aim at supporting a wide range of devices. The fact that the devices with which code needs to be tested are embedded and not always easily available to developers further increases testing issues.

A similar issue exists with the V4L API and has been addressed by a kernel driver that emulates a V4L device without requiring hardware. The goal of this project is to create a similar driver for the Media Controller API.


Tasks for the Application Period

Tasks must be completed in the order listed. The tasks list isn't complete yet.

Building the Media Controller Test Tool

A userspace utility named media-ctl is available as part of the v4l-utils package. In order to test the code that will be developed for this project the latest version of media-ctl will be needed. Furthermore, as changes to media-ctl might need to be performed as well, the utility should be compiled from its sources.

The purpose of this first task is not to submit a patch, but to ensure you can download, modify, compile and run the media-ctl test tool as this will be needed later during the course of the project.

Open-source development works based on trust. A proof that you have complete the first task properly isn't stricly required. If you don't complete it you will likely have problems later, so this is really a task designed to help you getting started with the project. Of course if you're not sure whether your results are correct and would like guidance, or have any other question, please ask on the outreachy-kernel mailing list and CC me.

Testing the Test Tool with a Hardware Device

This task is optional but recommended.

While no access to hardware is needed to implement a virtual Media Controller driver, understanding the API is easier done when testing on a real device. All USB cameras compatible with the USB Video Class can be used to first experiment with the Media Controller API.

The uvcvideo kernel driver implements the Media Controller API when the kernel is build with Media Controller support.

Testing the Virtual V4L Driver

The Virtual V4L driver is available in the drivers/media/platform/vivid/ directory of the kernel sources.

Creating a Skeleton Driver

The skeleton driver will serve as the base for the virtual Media Controller driver.

Create a Media Controller Device in the Skeleton Driver

This task starts building the virtual Media Controller infrastructure in the skeleton driver.

Add Entities to the Media Controller Device

It's now time to add entities to the device to build a media graph.

Tasks for the Internship Period

The Virtual Media Controller driver is divided in two major parts.

Graph Management

The goal of the Virtual Media Controller device is to expose a graph of media entities to userspace. To make this trully useful, the graph topology needs to be configurable, ideally from userspace. Tasks for this part are

Video Pipeline

With a virtual entities graph in place, support for virtual video sources and video processing entities would allow more elaborate usage of the driver by userspace video applications. This part extends the driver by adding virtual V4L2 video devices and sub-devices to the graph and implementing the corresponding V4L2 API.

The target is to implement the following entities.

The test pattern generator and scaler code from the vivid driver should be reused to implement the sensors and scaler subdevices.

The final target is a graph containing two sensor and debayer instances, one scaler instance, three video capture instances and one video output instance as shown below.


As this could require more time than available for the internship, the internship target is a pipeline consisting of one sensor subdevice and one V4L2 video capture device.

If time permits, possible extensions that can be considered are

Scope and Schedule

The two parts are mostly independent from each other. Once the graph topology configuration data structure is implemented support for dynamic graph modifications and for the video pipeline can be developed separately. As the three months internship period will likely not be long enough to implement all proposed features, you have the freedom to pick the tasks you find the most interesting (this should of course be discussed and agreed upon) and propose a time line. The main goal for the internship period is to get a driver merged (or on its way to being merged) in the mainline kernel with enough features to make it useful.

Contact Info

Email: <laurent.pinchart AT ideasonboard DOT com> IRC: pinchartl on and


KernelNewbies: LaurentPinchart (last edited 2017-12-30 01:30:27 by localhost)