akvcam: a V4L2 virtual camera driver for Linux

A kernel module that pretends to be a camera

akvcam is described in one line as a fully compliant V4L2 virtual camera driver for Linux, and the project description says the same thing more tersely: virtual camera for Linux. The primary language is C, which is what you would expect for code that registers a device with the kernel's video subsystem.

The value of a virtual camera is that it removes the physical device from the test loop. An application that opens /dev/video0, negotiates a format, allocates buffers and reads frames does not know or care whether a sensor or a generator produced them. Once akvcam is loaded, the same application code can be pointed at a synthetic source, which is what makes it useful for pipeline development, for automated tests that would otherwise need hardware, and for feeding one application from another.

The compliance claim is the one to test rather than accept. The feature list says the devices cannot be rejected by programs that reject M2M devices, and that the driver is fully compliant with the V4L2 standard. M2M means memory to memory, and a lot of video frameworks refuse to treat an M2M node as a capture device because it has no capture semantics. A driver that registers as a proper capture device therefore passes a check that a generic pipeline node would fail, which is a specific and testable claim rather than a vague promise.

The project is not archived and the last push was on 2026-10-18, the same day as the 2.0.0 release, so the driver is under current work.

Three memory modes, and they are not interchangeable

The feature list names support for map, user pointer, and read/write modes, and this is the part of the design that has the most direct consequences for the applications you point at it.

In a map mode the application allocates buffers and maps them into the driver's address space, which is the classic V4L2 streaming pattern and the one most applications use. In a user pointer mode the application hands the driver memory it has already allocated, which is the older V4L1 style still supported by some frameworks. In a read/write mode the device behaves more like a character device, and the application reads and writes it the way it would read a pipe.

Choosing among them is a decision about the consumer. A modern GStreamer or Video4Linux2 pipeline wants map mode. A tool that expects to open the node and read() from it wants read/write. The driver supports all three, and the configuration is what selects the behaviour, which means the same installation can serve different applications.

The related feature is that you can cat and echo to the device. That sounds like a joke until you realise what it implies: because the device supports read and write, a shell redirect is a legitimate way to feed data into it or take data out of it. For a developer that turns a frame source into something you can drive from a terminal, which is exactly the kind of convenience that makes a virtual device pleasant to work with.

The INI-file configuration is what makes this tunable. The feature list describes flexible configuration with a simple INI file like, and the repository tree carries a share/ directory where such data is conventionally kept, along with a package_info.conf.in file that suggests the driver is packaged for distribution.

Emulated controls and a default picture for the no-signal case

Two features exist purely so that applications which query a camera do not fall over.

The first is emulated camera controls in capture devices, covering brightness, contrast, saturation and similar settings. A real sensor exposes these as controls the application can read and write, and a virtual device that omits them causes applications to fail at capability enumeration or to show a greyed out settings panel. Emulating them means the control set exists and can be queried. The important word in the feature list is emulated: the values are not connected to anything real, they are a compatibility surface.

The second is a configurable default picture in case no input signal is available. When the driver has nothing to show, it presents a still image rather than nothing at all. That removes an entire class of confusing behaviour, where a preview pane goes black, or an application blocks waiting for a frame that never arrives, and the symptom looks like a driver bug rather than a missing source. The picture being configurable means you can make the placeholder recognisable, for example a test pattern that tells you immediately that you are looking at the fallback rather than at a live signal.

Both of these features point at the same design intent. The driver is built to be invisible to the application, and the fallback behaviour is designed so that the absence of signal is obvious to the human rather than mysterious to the program.

The build instructions live in the wiki, not in the README

The Build and Install section of the README is three lines long, and all of them point elsewhere: visit the wiki for comprehensive compile and install instructions. There is no configure, make or install command in the page, and no kernel version requirement is spelled out in the text.

That is a deliberate choice rather than an omission, and the repository structure backs it up. The tree has a CMakeLists.txt at the root, so the build is CMake-driven, an akvcam.kdev4 file for the KDevelop IDE, a src/ directory for the module sources, a ports/ directory for platform ports, a share/ directory for shared data, and a package_info.conf.in template that suggests the driver is packaged rather than compiled ad hoc on each machine. A CMake build plus a package template is a distribution-oriented layout, and the wiki is where the per-distribution steps live.

The kernel support claim is in the feature list rather than the build section: support for LTS kernels. That is a narrower statement than saying it works on any recent kernel, and it is the statement to check against your own system. Kernel modules are compiled against a specific kernel tree, so a driver that supports LTS kernels is a driver you can build for the kernels your distribution ships rather than only for a bleeding-edge one.

Downloads come from the GitHub releases, and there is also a daily-build release tag, which tells you that continuous builds are produced alongside the numbered releases. The recent tags are 2.0.0 from 2026-10-18, 1.4.0 from 2026-03-10 and 1.3.0 from 2025-07-07, so the 2.0.0 is a major bump on a project that had been on the 1.x line for a while.

GPL-2.0 and what that means for a kernel module

The licence is GPL-2.0, with a COPYING file in the repository root. For a kernel module this is the expected and largely the only workable choice, because the Linux kernel itself is GPL-2.0 and a module that links against kernel symbols is treated as part of the kernel for licensing purposes.

The practical consequence for a user is that a driver built for your machine cannot simply be redistributed in a closed product the way a permissive library could be. If you are shipping an appliance that includes akvcam, the driver is part of that distribution and comes with the GPL obligations attached to it. That is a normal outcome for a kernel module and not a defect in the project, but it is worth knowing before you make the driver part of a product.

The project also runs a Codacy quality dashboard, a Linux CI workflow badge, an OpenHub statistics badge, and keeps a ChangeLog file in the root. Issues go to the GitHub issue tracker, and there is a CONTRIBUTING.md. The donations page is linked from the README as well.

So the picture for a potential adopter is: an actively maintained, GPL-2.0, CMake-built kernel module with release artefacts and daily builds, whose build documentation lives in a wiki and whose core value is being invisible to the application on the other side of the device node.

Editorial conclusion

Adopt akvcam if you need a synthetic camera on Linux for testing video pipelines, screen capture to an application that only opens a camera, or development against a device you control, and if your kernel is one the project supports with LTS kernels covered. Do not adopt it for a production capture chain, since it is a virtual device with no real sensor behind it and its inputs are whatever your configuration points at, and do not expect it to solve a hardware driver problem. Before you commit, read the compile and install instructions in the project wiki, because the README deliberately keeps the build steps out of the page, and check the INI configuration format for the map, user pointer and read/write modes, since the choice of mode determines what your application can do with the frames it receives.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. webcamoid/akvcam on GitHub