v4l2 api compliance test

Here is what I found from the various apps int he test dir:

driver-test doesn't do much. I am hoping to replace it.

ioctl-test looks pretty good for what it is, but could use a little work on making the results easier to understand.

In documenting the tests, something just caused my test box to go to sleep.

[ 2067.460263] vivi/0: [d6cb2180/4] timeout
[ 2067.460267] vivi/0: [d6cb2480/5] timeout
[ 2215.838800] vivi: open called (minor=0)
[ 2388.964289] vivi: open called (minor=0)
[ 2477.927340] eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
[ 2480.753620] Syncing filesystems ... done.
[ 2480.753887] PM: Preparing system for mem sleep
[ 2480.754414] Freezing user space processes ... (elapsed 0.03 seconds) done.
[ 2480.792622] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
[ 2480.792745] PM: Entering mem sleep
[ 2480.792750] Suspending console(s)

That was freaky. Hopefully I'll figure out how that happened and report it.

v4l-info
...
fmt.pix.colorspace : unknown

Which may explain why ./pixfmt-test doesn't find any supported formats.

./vbi-test
V4L2 call: ret=-1: sampling_rate=0, samples_per_line=0, sample_format=0, offset=0, start=0/0, count=0/0
good?

lib$ vim v4l2_driver.c
This seems to have 1/2 the code I need. a main with some command line parameter support, spin though the cap.capabilities, make sure the ones that are supported
don't error, and maybe make sure the ones that aren't do.

So, before I go any further, comments?

Quoted 3 lines · On Sat, 01 Mar 2008 01:45:24 -0600 Carl Karsten <[email protected]> wrote:

Here is what I found from the various apps int he test dir:

driver-test doesn't do much. I am hoping to replace it.

The idea of this is to check if a driver is compliant with V4L2 specs. For example, several webcam drivers returns wrong buffer sizes to userspace. This testing program should do some basic configuration of the board and start capture, warning about non-compliance.

This program already warns about some issues, but I didn't have time to finish it.

Ideally, it should implement all ioctls from the API, and test the possible different configuration, helping to stress a driver.

Some options may be added to it, to select a fast test or a more detailed and longer one.

Quoted 2 lines

ioctl-test looks pretty good for what it is, but could use a little work on making the results easier to understand.

This is my first trial on writing a testing code. It just dumbly runs the V4L ioctls. Since it doesn't do anything coherent, this may produce weird results on real drivers. The debug printk's at the driver may help to see if everything is ok.

Quoted 13 lines

In documenting the tests, something just caused my test box to go to sleep.

[ 2067.460263] vivi/0: [d6cb2180/4] timeout
[ 2067.460267] vivi/0: [d6cb2480/5] timeout
[ 2215.838800] vivi: open called (minor=0)
[ 2388.964289] vivi: open called (minor=0)
[ 2477.927340] eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
[ 2480.753620] Syncing filesystems ... done.
[ 2480.753887] PM: Preparing system for mem sleep
[ 2480.754414] Freezing user space processes ... (elapsed 0.03 seconds) done.
[ 2480.792622] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
[ 2480.792745] PM: Entering mem sleep
[ 2480.792750] Suspending console(s)

Quoted 1 line

That was freaky. Hopefully I'll figure out how that happened and report it.

This is really weird. vivi doesn't implement any suspend code.

Quoted 5 lines

v4l-info
...
fmt.pix.colorspace : unknown

Which may explain why ./pixfmt-test doesn't find any supported formats.

v4l-info uses the old V4L1 API (and V4L2). Maybe, some format were not correctly translated by v4l1-compat.

Quoted 4 lines

./vbi-test
V4L2 call: ret=-1: sampling_rate=0, samples_per_line=0, sample_format=0, offset=0, start=0/0, count=0/0
good?

vivi doesn't implement vbi. Returning an error seems OK.

Quoted 5 lines

lib$ vim v4l2_driver.c
This seems to have 1/2 the code I need. a main with some command line parameter support, spin though the cap.capabilities, make sure the ones that are supported
don't error, and maybe make sure the ones that aren't do.

Quoted 1 line

So, before I go any further, comments?

Please, feel free to improve the tools. Unfortunately, nobody yet had time to dedicate on improving the testing tools.

Quoted 6 lines · Mauro Carvalho Chehab

On Sat, 01 Mar 2008 01:45:24 -0600
Carl Karsten <[email protected]> wrote:

Please, feel free to improve the tools. Unfortunately, nobody yet had time to dedicate on improving the testing tools.

These 2 issues are thwarting my efforts to write my tester:

1. memory leak:
valgrind ./capture --userp -d /dev/video1
==17153== malloc/free: in use at exit: 2,457,632 bytes in 5 blocks.

2. capabilities mismatch:
./capture --userp -d /dev/video1
VIDIOC_QBUF error 22, Invalid argument

details: http://linuxtv.org/v4lwiki/index.php/Test_Suite#Bugs_in_Examples

Carl K

Quoted 13 lines · Carl Karsten

Quoted 6 lines · Mauro Carvalho Chehab

On Sat, 01 Mar 2008 01:45:24 -0600
Carl Karsten <[email protected]> wrote:

Please, feel free to improve the tools. Unfortunately, nobody yet had time to dedicate on improving the testing tools.

These 2 issues are thwarting my efforts to write my tester:

1. memory leak:
valgrind ./capture --userp -d /dev/video1
==17153== malloc/free: in use at exit: 2,457,632 bytes in 5 blocks.

Quoted 5 lines

2. capabilities mismatch:
./capture --userp -d /dev/video1
VIDIOC_QBUF error 22, Invalid argument

details: http://linuxtv.org/v4lwiki/index.php/Test_Suite#Bugs_in_Examples

I'm not sure why a memory leak on abnormal termination is worrisome for you. It looks like init_userp() allocated a bunch of "buffers", which has to happen for a program to use user pointer mode of v4l2. The function errno_exit() doesn't bother to clean up when the VIDIOC_QBUF ioctl() call fails. free() is only called by uninit_device(). Since the alternate flow of the program through errno_exit() to termination doesn't call free() on "buffers", you should have a process heap memory leak on error exit.

Since this is userspace, a memory leak from the process heap doesn't hang around when the process terminates - no big deal.

You could
equally gripe that the program didn't close it's file descriptors with the driver on errno_exit() - but process termination cleans those up too.

Quoted 29 lines · Andy Walls

Quoted 13 lines · Carl Karsten

Quoted 6 lines · Mauro Carvalho Chehab

On Sat, 01 Mar 2008 01:45:24 -0600
Carl Karsten <[email protected]> wrote:

Please, feel free to improve the tools. Unfortunately, nobody yet had time to dedicate on improving the testing tools.

These 2 issues are thwarting my efforts to write my tester:

1. memory leak:
valgrind ./capture --userp -d /dev/video1
==17153== malloc/free: in use at exit: 2,457,632 bytes in 5 blocks.

Quoted 5 lines

2. capabilities mismatch:
./capture --userp -d /dev/video1
VIDIOC_QBUF error 22, Invalid argument

details: http://linuxtv.org/v4lwiki/index.php/Test_Suite#Bugs_in_Examples

I'm not sure why a memory leak on abnormal termination is worrisome for you. It looks like init_userp() allocated a bunch of "buffers", which has to happen for a program to use user pointer mode of v4l2. The function errno_exit() doesn't bother to clean up when the VIDIOC_QBUF ioctl() call fails. free() is only called by uninit_device(). Since the alternate flow of the program through errno_exit() to termination doesn't call free() on "buffers", you should have a process heap memory leak on error exit.

Quoted 2 lines

Since this is userspace, a memory leak from the process heap doesn't hang around when the process terminates - no big deal.

Are you sure about that?

if I run
./capture --userp -d /dev/video1
VIDIOC_QBUF error 22, Invalid argument

enough I can't run the valid modes:

juser@dhcp186:~/vga2usb/v4l.org/examples$ ./capture --read -d /dev/video1
read error 12, Cannot allocate memory

juser@dhcp186:~/vga2usb/v4l.org/examples$ ./capture --mmap -d /dev/video1
mmap error 12, Cannot allocate memory

although free still shows lots:

juser@dhcp186:~/vga2usb/v4l.org/examples$ free
             total       used       free     shared    buffers     cached
Mem:       1033388     282340     751048          0      31012      98208
-/+ buffers/cache:     153120     880268
Swap:       859436          0     859436

Quoted 4 lines

You could
equally gripe that the program didn't close it's file descriptors with the driver on errno_exit() - but process termination cleans those up too.

I am personally interested in anything that makes it harder for me to determine if a driver is misbehaving.

In addition, I would think that the API's example code should be a squeaky clean example of how real code should be written, given it is often used as a starting point. If problems are identified, they should at least be noted, better yet removed.

Carl K

Quoted 10 lines

Quoted 10 lines

Quoted 1 line

details: http://linuxtv.org/v4lwiki/index.php/Test_Suite#Bugs_in_Examples

I'm not sure why a memory leak on abnormal termination is worrisome for you. It looks like init_userp() allocated a bunch of "buffers", which has to happen for a program to use user pointer mode of v4l2. The function errno_exit() doesn't bother to clean up when the VIDIOC_QBUF ioctl() call fails. free() is only called by uninit_device(). Since the alternate flow of the program through errno_exit() to termination doesn't call free() on "buffers", you should have a process heap memory leak on error exit.

Quoted 3 lines

Quoted 2 lines

Since this is userspace, a memory leak from the process heap doesn't hang around when the process terminates - no big deal.

Are you sure about that?

About the process heap, yes.

Quoted 8 lines

if I run
./capture --userp -d /dev/video1
VIDIOC_QBUF error 22, Invalid argument

enough I can't run the valid modes:

juser@dhcp186:~/vga2usb/v4l.org/examples$ ./capture --read -d /dev/video1
read error 12, Cannot allocate memory

The capture app would output "Out of memory" if the calloc() call for the --read option buffers failed. This is some global/kernel resource that has been exhausted.

Quoted 2 lines

juser@dhcp186:~/vga2usb/v4l.org/examples$ ./capture --mmap -d /dev/video1
mmap error 12, Cannot allocate memory

Ditto for this. This message can only happen at the end of init_mmap() when the mmap call fails. Thus an allocation of some sort of kernel global resource/space failed.

I don't know what could be exhausting those kernel resources when using the userp option. The failed ioctl()'s calls to the vivi driver would be a place to start looking.

Quoted 8 lines

although free still shows lots:

juser@dhcp186:~/vga2usb/v4l.org/examples$ free
             total       used       free     shared    buffers     cached
Mem:       1033388     282340     751048          0      31012      98208
-/+ buffers/cache:     153120     880268
Swap:       859436          0     859436

Perhaps you could look at /proc/meminfo between runs and see if something is gradually being exhausted. Vmalloc address space exhaustion is what I'd look for.

Quoted 8 lines

Quoted 6 lines

You could
equally gripe that the program didn't close it's file descriptors with the driver on errno_exit() - but process termination cleans those up too.

I am personally interested in anything that makes it harder for me to determine if a driver is misbehaving.

Ah, eliminating unknowns. OK.

Quoted 5 lines

In addition, I would think that the API's example code should be a squeaky clean example of how real code should be written, given it is often used as a starting point. If problems are identified, they should at least be noted, better yet removed.

I can't say I disagree.

so assuming the problem is with capture.c, who do I tell? (i know where to send anything else it might be: v4l list.

Quoted 29 lines · Carl Karsten

Quoted 28 lines · Andy Walls

Quoted 13 lines · Carl Karsten

Quoted 6 lines · Mauro Carvalho Chehab

On Sat, 01 Mar 2008 01:45:24 -0600
Carl Karsten <[email protected]> wrote:

Please, feel free to improve the tools. Unfortunately, nobody yet had time to dedicate on improving the testing tools.

These 2 issues are thwarting my efforts to write my tester:

1. memory leak:
valgrind ./capture --userp -d /dev/video1
==17153== malloc/free: in use at exit: 2,457,632 bytes in 5 blocks.

Quoted 5 lines

2. capabilities mismatch:
./capture --userp -d /dev/video1
VIDIOC_QBUF error 22, Invalid argument

details: http://linuxtv.org/v4lwiki/index.php/Test_Suite#Bugs_in_Examples

I'm not sure why a memory leak on abnormal termination is worrisome for you. It looks like init_userp() allocated a bunch of "buffers", which has to happen for a program to use user pointer mode of v4l2. The function errno_exit() doesn't bother to clean up when the VIDIOC_QBUF ioctl() call fails. free() is only called by uninit_device(). Since the alternate flow of the program through errno_exit() to termination doesn't call free() on "buffers", you should have a process heap memory leak on error exit.

Quoted 3 lines

Quoted 2 lines

Since this is userspace, a memory leak from the process heap doesn't hang around when the process terminates - no big deal.

Are you sure about that?

About the process heap, yes.

Quoted 8 lines

if I run
./capture --userp -d /dev/video1
VIDIOC_QBUF error 22, Invalid argument

enough I can't run the valid modes:

juser@dhcp186:~/vga2usb/v4l.org/examples$ ./capture --read -d /dev/video1
read error 12, Cannot allocate memory

The capture app would output "Out of memory" if the calloc() call for the --read option buffers failed. This is some global/kernel resource that has been exhausted.

Quoted 2 lines

juser@dhcp186:~/vga2usb/v4l.org/examples$ ./capture --mmap -d /dev/video1
mmap error 12, Cannot allocate memory

Ditto for this. This message can only happen at the end of init_mmap() when the mmap call fails. Thus an allocation of some sort of kernel global resource/space failed.

I don't know what could be exhausting those kernel resources when using the userp option. The failed ioctl()'s calls to the vivi driver would be a place to start looking.

Quoted 8 lines

although free still shows lots:

juser@dhcp186:~/vga2usb/v4l.org/examples$ free
             total       used       free     shared    buffers     cached
Mem:       1033388     282340     751048          0      31012      98208
-/+ buffers/cache:     153120     880268
Swap:       859436          0     859436

Perhaps you could look at /proc/meminfo between runs and see if something is gradually being exhausted. Vmalloc address space exhaustion is what I'd look for.

Quoted 10 lines · Andy Walls

Quoted 7 lines · Carl Karsten

Quoted 6 lines · Andy Walls

Quoted 5 lines · Carl Karsten

Quoted 4 lines · Mauro Carvalho Chehab

On Sat, 01 Mar 2008 01:45:24 -0600
Carl Karsten <[email protected]> wrote:

Quoted 4 lines

Perhaps you could look at /proc/meminfo between runs and see if something is gradually being exhausted. Vmalloc address space exhaustion is what I'd look for.

I forgot to sort it - now I see:

HighFree go from 72608 to 252
VmallocUsed from 6440 to 109724
VmallocChunk from 103620 to 336

I hope this sheds some light on where to look.

Carl K