Anatomy of a V4L driver

How a driver gets loaded into memory

Firstly, a v4l driver is a kernel module that hooks into at least the videodev module (v4l) and possibly other modules such as v4l1-compat or videobuf, depending what it uses.

Since a v4l driver is a kernel module, it will be loaded using modprobe or insmod. If using insmod, make sure to load all dependancies, or else your module will have unresolved symboles and will fail to load, such as this:

     vloopback_crc: module not supported by Novell, setting U taint flag.
     vloopback_crc: Unknown symbol videobuf_reqbufs, st_info == 0x1
     vloopback_crc: Unknown symbol v4l_compat_translate_ioctl, st_info == 0x1
     vloopback_crc: Unknown symbol videobuf_dqbuf, st_info == 0x1
     vloopback_crc: Unknown symbol videobuf_qbuf, st_info == 0x1
     vloopback_crc: Unknown symbol videobuf_read_one, st_info == 0x1

These errors can be frustrating, but a good place to start is determining the dependancies. In this case we look at the prefix (videobuf_), and it hints to us that the video-buf module needs to be loaded. Same thing for v4l-compat. More information about Unresolved Symbols is available here.

What happens when the driver first starts up

When a driver, and pretty much any kernel module gets started up, there needs to be a generic way for the module to initialize itself (this must be a way that the kernel will know how to get the module going). In the code of the module, there needs to be code such as this:

      module_init(vloopback_init);
      module_exit(cleanup_vloopback_module);

module_init and module_exit being the keywords here. With the appropriate make flags, the compiler will know to bind these functions (vloopback_init, cleanup_vloopback_module) to the initialize and cleanup functions for the kernel to call.

It is in the initialize function that the device (/dev/video5) will actually be created and it is where the device can setup it's default parameters.

How applications communicate with a v4l driver

v4l drivers are compliant with the ioctl interface of the kernel. This means that if a v4l driver is written, any application that is compatible with v4l will be able to communicate with that driver. To do this, the application needs to send generic v4l ioctl (Input Output Controls) commands that the driver will be able to understand and respond to.

Usually, when an application (such as mythtv, xawtv) starts up, you need to tell it which device to communicate to. Say the device is on /dev/video5, then the application will bind itself to /dev/video5 and the ioctls will be forwared to the driver in question via videodev module. The driver will then interpret the ioctl command (such as channel up, down, volume up, down, read, open...) and do the appropriate action.

Additional information on writing v4l drivers

A great resource for getting started writing drivers (although outdated), is the following link.

Additionally, by checking out the v4l source, there are many files in there which can be used as templates for drivers. It is not easy to put all the knowledge together, but with time it comes.