It acts as a device driver to a virtual video input device which it creates (i.e. it emulates a real video device using the V4L2 API, without there actually being any physical hardware device present within the system). The driver generates a dynamic vertical colour bar test pattern, overlaid with a timestamp and basic video property information, and which is available for viewing through V4L2 software applications. Within the viewing app, changing the source input option for the virtual device will result in slightly different colour bar test patterns.

as a base “example of how V4L2 drivers should be written. vivi only uses the vmalloc() API, but it's good enough to get started with” (videobuf kernel documentation) ... note: you would want to use the videobuf2 framework, as it greatly simplifies the work of writing a v4l2 driver [1]

Some Technical Details:
The vivi driver produces a CPU load because of its generation of a video image; something which is not of an issue in the case of real V4L2 drivers (i.e. device drivers for real physical hardware that accept an external video input signal).

In late 2012, vivi was substantially improved in regards to the image generation (note: this work gained inclusion into the 3.9 kernel) and, consequently, CPU loading should now be reduced by quite a bit. For more info, in particular to ideally making a driver's buffers available to userspace through mmap() as opposed to via doing a memcpy (which will produce a high CPU load), see this discussion thread: http://www.mail-archive.com/linux-media@vger.kernel.org/msg60684.html