minimum v4l2 api

Apparently vivi is messed up enough that maybe it makes sense to write a new test driver.

What is the minimum interface a v4l2 driver could have?

Something like: it registers itself as /dev/videoN, and QueryCaps returns nothing.
It does not return any image. (yeah ?)
It can be unloaded.

and anything else that someone thinks is required for a well behaved driver that follows the spec.

The plan is to start with that, get it and my tester working in harmony, then start adding things to both sides of the fence. I am thinking additional features will be enabled via module parameters, so that it can always be dumbed down back to it's minimum.

Carl K

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Tomorrow (Nov 16) I will be at a Linuxfest, where I am going to try to find someone up for writing this driver.

I am assuming there is some code they should use as a starting point. Either
A) "This is the generic/abstract code that can be extended to make a specific/concrete driver" (what I would call a framework)
B) "driver foo.c is a good example of how a V4L2 driver should be written; copy it and swap out the hardware specific code."
C) "vivi.c is close enough. you should really just work on fixing it."

I am hoping the correct answer is:
http://linuxtv.org/hg/~hverkuil/v4l-dvb-media2/file/6292505ca617/linu
x/Documentation/video4linux/v4l2-framework.txt

If someone can give me a rough stub to start with, that would make tomorrow's work more promising.

Carl K

Quoted 18 lines · Carl Karsten

Apparently vivi is messed up enough that maybe it makes sense to write a new test driver.

What is the minimum interface a v4l2 driver could have?

Something like: it registers itself as /dev/videoN, and QueryCaps returns nothing.
It does not return any image. (yeah ?)
It can be unloaded.

and anything else that someone thinks is required for a well behaved driver that follows the spec.

The plan is to start with that, get it and my tester working in harmony, then start adding things to both sides of the fence. I am thinking additional features will be enabled via module parameters, so that it can always be dumbed down back to it's minimum.

Quoted 8 lines

Carl K

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Quoted 12 lines · On Saturday 15 November 2008 21:59:44 Carl Karsten wrote:

Tomorrow (Nov 16) I will be at a Linuxfest, where I am going to try to find someone up for writing this driver.

I am assuming there is some code they should use as a starting point. Either
A) "This is the generic/abstract code that can be extended to make a specific/concrete driver" (what I would call a framework)
B) "driver foo.c is a good example of how a V4L2 driver should be written; copy it and swap out the hardware specific code."
C) "vivi.c is close enough. you should really just work on fixing it."

Quoted 3 lines

I am hoping the correct answer is:
http://linuxtv.org/hg/~hverkuil/v4l-dvb-media2/file/6292505ca617/linu
x/Documentation/video4linux/v4l2-framework.txt

Hopefully this will be the correct answer in the near future, but now it refers to structs that do not yet exist. I've reserved next weekend to continue work on this.

It's probably a good idea for me to create a template driver that can be used as a proper starting point, however nothing will be available soon enough for you. I don't think we have a 'perfect' driver right now. All drivers have their own problems. It's one of the main reasons I'm working on a better framework.

In any case, I don't think vivi is a good example, it's not written as a template driver, that was never the intention of vivi.

Regards,

Hans

Quoted 37 lines

If someone can give me a rough stub to start with, that would make tomorrow's work more promising.

Carl K

Quoted 18 lines · Carl Karsten

Apparently vivi is messed up enough that maybe it makes sense to write a new test driver.

What is the minimum interface a v4l2 driver could have?

Something like: it registers itself as /dev/videoN, and QueryCaps returns nothing.
It does not return any image. (yeah ?)
It can be unloaded.

and anything else that someone thinks is required for a well behaved driver that follows the spec.

The plan is to start with that, get it and my tester working in harmony, then start adding things to both sides of the fence. I am thinking additional features will be enabled via module parameters, so that it can always be dumbed down back to it's minimum.

Quoted 8 lines

Carl K

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Quoted 122 lines · On Monday 01 December 2008 03:32:00 Carl Karsten wrote:

Quoted 90 lines · Hans Verkuil

Quoted 60 lines · On Sunday 30 November 2008 20:16:07 Carl Karsten wrote:

Quoted 49 lines · Hans Verkuil

Quoted 29 lines · On Sunday 30 November 2008 18:49:45 Carl Karsten wrote:

Quoted 28 lines · Hans Verkuil

Quoted 27 lines · On Tuesday 25 November 2008 03:24:07 Carl Karsten wrote:

Quoted 26 lines · Hans Verkuil

Quoted 12 lines · On Saturday 15 November 2008 21:59:44 Carl Karsten wrote:

Tomorrow (Nov 16) I will be at a Linuxfest, where I am going to try to find someone up for writing this driver.

I am assuming there is some code they should use as a starting point. Either
A) "This is the generic/abstract code that can be extended to make a specific/concrete driver" (what I would call a framework) B) "driver foo.c is a good example of how a V4L2 driver should be written; copy it and swap out the hardware specific code." C) "vivi.c is close enough. you should really just work on fixing it."

Quoted 3 lines

I am hoping the correct answer is:
http://linuxtv.org/hg/~hverkuil/v4l-dvb-media2/file/6292505c
a6 17 /l inu x/Documentation/video4linux/v4l2-framework.txt

Hopefully this will be the correct answer in the near future, but now it refers to structs that do not yet exist. I've reserved next weekend to continue work on this.

It's probably a good idea for me to create a template driver that can be used as a proper starting point, however nothing will be available soon enough for you. I don't think we have a 'perfect' driver right now. All drivers have their own problems. It's one of the main reasons I'm working on a better framework.

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

Any progress?

Carl K

Erm, no. At least not on an example driver. As you may have noticed I'm working hard to get the new v4l2_device and v4l2_subdev structs merged.

personal disappointment is very offset by appreciation of what you are doing for the world, so no hard feelings :)

Phew, that's a relieve :-)

Quoted 9 lines

Quoted 9 lines

I also think it is much harder to make an example driver than I expected. In many ways the cx18 driver is actually not a bad choice, except for the fact that it doesn't use video-buf when it really should do that. It also very much depends on the type of driver: a PCI driver is quite different from an USB driver, and a webcam driver is again quite different from a TV capture driver. There is such a wide variety of hardware that we support that there isn't really such a thing as a perfect example driver.

Quoted 2 lines

Quoted 1 line

gspca is v4l v1 (right?)

No, it's v2. It might perhaps still support v1, I'm not sure.

oh wow, I thought that was still a ways off. well then...

Quoted 6 lines

Quoted 4 lines

perhaps something like that would be a good
place for me to look for creating a driver that doesn't rely on
hardware? Are there any v4l2 codebases that are not tied to
one piece of hardware?

Only vivi is software only. All other drivers are always tied to specific hardware.

Quoted 7 lines

er, I meant code that is used across many different pices of
hardware (as opposed to just one.) The thought is that would be
a) a good start for creating another test driver like vivi, and b) would benefit that code base by having some automated regression tests. Testing the test driver would test some code, but would mainly be useful for testing the tester. the substantial benefit would come from being able to test the drivers on real hardware.

Hmm, the driver that probably has the most accurate v4l2 support is ivtv (although I might be biased, being the maintainer of that driver). The cx18 driver is derived from ivtv and is probably a bit easier to understand. The main problem with ivtv and cx18 is that they don't use video-buf. So to test streaming video you would probably want to look at cx88 or bt8xx. For USB capture devices I think the em28xx driver is a decent driver and for webcams I would look at uvc.

The sad fact is that in many cases drivers reinvented the wheel due to the lack of a proper V4L2 framework, or copied the same broken code. E.g. drivers like saa7134 and cx88 both share the same defect where if you call VIDIOC_S_FMT that format is lost as soon as you close the filehandle. That's completely against the V4L2 spec which says that it is kept after closing the video device. This same bug is in a series of drivers, all copied from some original driver.

So if you are looking for hardware to test with, then I would suggest that you try to get a second-hand Hauppauge PVR-350. This allows you to test MPEG encoding, decoding, VBI (both raw and sliced), MPEG indexing, raw video encoding and decoding.

Quoted 4 lines

To test streaming IO get a card supported by the saa7134, cx88 or bt8xx drivers. For webcam support look at a UVC webcam (a webcam supported by the gspca driver is probably also OK for your purposes).

my ultimate goal is to help with the development (I would just test) a closed source v4l driver that digitizes svga (or whatever you call what video cards put out over 15 pin monitor connector, with res up to 2384x3370) and exposes it as a v4l stream. more on that project
here: http://chipy.org/V4l2forPyCon

The driver developer has said he would be doing a v4l2 one soon, and I would like to help test it. This would be done best if I had a good generic test app, but that has been troublesome given the state of v4l(2) drivers.

I could focus my work on making tests that only apply to the vga2usb device, but the usefulness would be limited to that device, so very limited, so I would pretty much be alone. I would rather put the effort into something universally useful to all v4l driver developers, and thus will get a bit more help.

I have the hardware I need (i think). it's the automated tests I am struggling with because there isn't a solid starting point. although perhaps getting some hardware that digitized composite and has a solid driver could be used by feeding a test pattern signal. the reason i am opposed to that is because the only people that will be able to help are people who have that card, or maybe when the tests become reliable and others start using it as part of their development. my fear is that alone I won't be able to get it to that point.

Quoted 6 lines

So given all this, what would you suggest?

(and if you already understood all this and your suggestions still stands, forgive me for making sure.)

Carl K

Hi Carl,

I think that you should look at two different test apps here. One utility would validate the V4L2 API as implemented by a driver as much as possible. I made a starting point at one time with the v4l2-compliance utility (in v4l2-apps/utils in the v4l-dvb repository), but that's really, really small at the moment. I never had time to expand on it.

The basic idea is that this utility queries the capabilities and based on that tries to exercise all the ioctls and verifies that what the driver returns has all the fields filled in, uses the right return codes/error and that you can set formats, controls, etc. according to the returned capabilities.

It could also do some short captures, but just to test if it works.

A second test app should be available to do long-term captures and look at timestamps and things like that.

I can definitely think of numerous test cases for you to implement. There simply is no proper testing application available right now.

What I don't quite follow is what this has to do with your questions about a good example driver.

Is that to help the developer that makes
this new V4L2 driver?

(And why is it closed source anyway?

Note that
video-buf is all EXPORT_SYMBOL_GPL so in order to use that the driver has to be GPL as well).

All you need to make a good test suite is the V4L2 spec. That's a pretty good document and (almost) always leading.

Quoted 3 lines · Hans Verkuil

I can definitely think of numerous test cases for you to implement. There simply is no proper testing application available right now.

I would ask you to add them to the a wiki page about it, but it appears to be missing:
http://linuxtv.org/v4lwiki/index.php/Test_Suite