This article outlines some V4L2 compliant software which can be used as a means to test the functionality of V4L2 device drivers or applications -- essentially, code to test other code. If you create a new test utility, or if you know of a test that is not listed, please add it to the lists below.

−

If you need a test, look here.

+

==Test Drivers==

+

* [[VIVI]] -- Virtual Video Driver: A real v4l2 device driver with no physical hardware. This means anyone can use it (it is part of the Linux kernel: modprobe vivi).

−

If you create a new test, add it here.

+

:If your application has problems with a specific device driver, try using vivi instead. If you still have a problem, it is much more likely to be a problem with the application than with the driver. Knowing where to look is a big help in fixing problems.

−

If you know of a test that is not listed, please add it.

+

:However, vivi is not

+

:* perfect. Not surprising given it doesn't get the amount of real world use that real drivers do.

+

:* feature complete. It does not implement every interface of the v4l2 spec.

−

===Stable Starting Point===

+

:But it is something anyone can run, so it makes reproducing some problems possible that would otherwise be impossible without the specific hardware.

−

It seems the 2 V4L2 examples (capture.c and vivi.c) don't play well with each other. I am not really sure where to post about this, so I will start here and move it to the appropriate place once I find it. so far http://bugzilla.kernel.org seems the most likely. I am dumping my notes at the bottom of this page to try to keep the point of this page from getting buried.

+

−

===Test Driver===

+

==Test applications==

−

[[VIVI]] - Virtual Video Driver

+

Simple programs that test various functionality of a V4L2 driver.

−

A real v4l2 device driver with no physical hardware. This means anyone can use it (it is part of the Linux kernel: modprobe vivi).

+

There are many small test apps that seem to have been written to help isolate an existing problem, as opposed to actively looking for problems. This means the tests make assumptions about what is/isn't supported, which can cause [[Wikipedia:Type_I_and_type_II_errors|false positives]] when someone else uses them in a different environment or context. For instance, a specific feature test should not be run unless the device driver advertises support for the feature. Ideally, this means that all tests should first xioctl(fd, VIDIOC_QUERYCAP, &cap) and test cap.capabilities to see if the rest of the test is applicable. However, this does not mean you shouldn't post your test code if it does not comply with such ideal qualifications - as something is better than nothing.

−

+

−

If your application has problems with a specific device driver, try using vivi instead. If you still have a problem, it is much more likely to be a problem with the application than with the driver. Knowing where to look is a big help in fixing problems.

+

−

+

−

However, vivi is not

+

−

* perfect. Not surprising given it doesn't get the amount of real world use that real drivers do.

+

−

* feature complete. It does not implement every interface of the v4l2 spec.

+

−

+

−

But it is something anyone can run, so it makes reproducing some problems possible that would otherwise be impossible without the specific hardware.

+

−

+

−

===Test applications===

+

−

Simple programs that test various functionality of a driver.

+

−

+

−

There are many small test apps that seem to have been written to help isolate an existing problem, as opposed to actively looking for problems. This means the tests make assumptions about what is/isn't supported, which can cause [[Wikipedia:Type_I_and_type_II_errors|false positives]] when someone else uses them in a different environment. For instance, a specific feature test should not be run unless the device driver advertises support for the feature. Ideally, this means that all tests should first xioctl(fd, VIDIOC_QUERYCAP, &cap) and test cap.capabilities to see if the rest of the test is applicable. However, this does not mean you shouldn't post your test code it it does not comply with such ideal qualifications - as something is better than nothing.

{{Note|One user encountered problems between the vivi.c driver and the V4L2 capture.c example, suggesting that they do not "play well" together. See the [[Talk:V4L Test Suite|article's discussion page]] for more details}}

vivi: "It is intended to be a working example code for current V4L2 Driver and Stub driver to facilitate the implementation of new video drivers.

−

−

They don't play well with each other. There is a memory leak, and I think vivi is telling capture to use a buffer mode that isn't valid - I call this "capabilities mismatch" but I am not really sure what the problem is.

−

−

====Summary====

−

−

detailed report: "vivi memory leak = kernel panic"

−

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/294951

−

−

=====memory leak=====

−

sudo modprobe vivi

−

gcc capture.c -g -o capture

−

valgrind ./capture --userp -d /dev/video1

−

==17153== malloc/free: in use at exit: 2,457,632 bytes in 5 blocks.

−

−

=====capabilities mismatch=====

−

./capture --userp -d /dev/video1

−

VIDIOC_QBUF error 22, Invalid argument

−

−

====Detail====

−

setup for both: (capture.c is the original, same problem with capture_example.c, see URL above)

Latest revision as of 17:09, 8 October 2011

This article outlines some V4L2 compliant software which can be used as a means to test the functionality of V4L2 device drivers or applications -- essentially, code to test other code. If you create a new test utility, or if you know of a test that is not listed, please add it to the lists below.

Test Drivers

VIVI -- Virtual Video Driver: A real v4l2 device driver with no physical hardware. This means anyone can use it (it is part of the Linux kernel: modprobe vivi).

If your application has problems with a specific device driver, try using vivi instead. If you still have a problem, it is much more likely to be a problem with the application than with the driver. Knowing where to look is a big help in fixing problems.

However, vivi is not

perfect. Not surprising given it doesn't get the amount of real world use that real drivers do.

feature complete. It does not implement every interface of the v4l2 spec.

But it is something anyone can run, so it makes reproducing some problems possible that would otherwise be impossible without the specific hardware.

Test applications

Simple programs that test various functionality of a V4L2 driver.

There are many small test apps that seem to have been written to help isolate an existing problem, as opposed to actively looking for problems. This means the tests make assumptions about what is/isn't supported, which can cause false positives when someone else uses them in a different environment or context. For instance, a specific feature test should not be run unless the device driver advertises support for the feature. Ideally, this means that all tests should first xioctl(fd, VIDIOC_QUERYCAP, &cap) and test cap.capabilities to see if the rest of the test is applicable. However, this does not mean you shouldn't post your test code if it does not comply with such ideal qualifications - as something is better than nothing.