Sunday, June 14, 2015

[Outreachy Status Log] Third week - Basic video pipe with a capture and sensor node

This is a resume in what I've been working on.
There is no much content in this post if you are looking for useful information to your project. I am posting more useful information under the Nerd category.
Check my first Outreachy post to know how they are organized.

This week I worked in a first pipeline skeleton as first proposed here.

This is the output of the topology from my code:

The sensors generate a simple grey image for now from a kthread, and it is being propagated to the Raw capture nodes. The other nodes (debayer, input and scaler) don't have any inteligent yet.
It is possible to view the generated (grey) image from tools such as qv4l2

The sensors and capture device codes still need to improve.

This week I sent this patch series to my mentor. After my mentor's feedback and the appropriate patch corrections, the next step is implementing a basic debayer, scaler and input intelligence.

You can check the development of this in my github Linux Kernel Fork branch vmc/devel/video-pipe


  1. Nice! I took a brief look at you code and it's pretty cool to see that you've gone this far! =D I've a couple of questions: Why do you use the freezer subsystem at this point? And is there any userspace config API or subsystem other than v4l2-ioctl?

  2. Hi! Thank you for the comment.

    The freezer subsystem is used to allow the system to hibernate in a safe state. When entering in hibernation, an internal flag PF_FROZEN is set and the try_to_freeze function will block in an infinity loop until this flag is cleared, we say that the task is frozen.
    The kernel waits for all the tasks marked as freezable to be in frozen state before creating the hibernation image.
    User space threads are set to frozen state by default when the system enters in hibernation, but the kernel threads must call try_to_freeze explicitly.
    This is useful mainly to protect the file system, i.e. when entering the hibernation the system creates an image (to be restored on wakeup), if some task writes to the file system *after* the creation of this image, it could let the fs in such inconsistent state that is really difficult to reverse.
    Another reason is: to create the hibernation image the system needs ram space, so it free a lot of memory and it doesn't want any task doing allocations while creating this image.
    You can find more information here:
    This is new to me as well, please tell me if you understand other things from it :)

    About the video4linux API, in its specification the user use ioctl calls to interact with drivers, the spec can be found in this link:
    I am planing to post some simple userspace code to show how to communicate with a camera driver in the furute

    1. Wow! I didn't know such details before... Thanks Helen! Waiting for your future posts!