minimum v4l2 api

minimum v4l2 api

[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.

Carl K


--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: minimum v4l2 api - framework

[Carl Karsten]

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/linux/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


Carl Karsten wrote:
> 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:video4linux-list-request@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/video4linux-list
> 
> 

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: minimum v4l2 api - framework

[Hans Verkuil]

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."
>
> 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

>
> If someone can give me a rough stub to start with, that would make
> tomorrow's work more promising.
>
> Carl K
>
> Carl Karsten wrote:
> > 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:video4linux-list-request@redhat.com?subject=unsubscribe
> > https://www.redhat.com/mailman/listinfo/video4linux-list
>
> --
> video4linux-list mailing list
> Unsubscribe
> mailto:video4linux-list-request@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/video4linux-list


--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: minimum v4l2 api - framework

[Carl Karsten]

Hans Verkuil wrote:
> 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."
>>
>> 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.

How's this sound:  I'll hold off putting any effort into this this weekend.  Let
me know how things go next weekend, and if everything worked out as you hoped we
can start then.  That sounds like a much better use of everyone's time, and it
results in your code being tested in a fairly clean environment (no flaky
hardware that you don't even have, and simple apps that don't do much at all.)

I think you are misunderstanding why I mentioned vivi: All I want at this point
is what vivi is sposed to be, but it fails due to bugs.  A few people have
suggested that vivi is poorly coded, so fixing the bugs may be more difficult
than starting over.

I'll document the process of developing a test driver using the framework and
creating unit tests along the way.  This doc will be good for anyone developing
a real driver.

Carl K

> 
> Regards,
> 
> 	Hans
> 
>> If someone can give me a rough stub to start with, that would make
>> tomorrow's work more promising.
>>
>> Carl K
>>
>> Carl Karsten wrote:
>>> 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:video4linux-list-request@redhat.com?subject=unsubscribe
>>> https://www.redhat.com/mailman/listinfo/video4linux-list
>> --
>> video4linux-list mailing list
>> Unsubscribe
>> mailto:video4linux-list-request@redhat.com?subject=unsubscribe
>> https://www.redhat.com/mailman/listinfo/video4linux-list
> 
> 
> 

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: minimum v4l2 api - framework

[Carl Karsten]

Hans Verkuil wrote:
> On Monday 01 December 2008 03:32:00 Carl Karsten wrote:
>> Hans Verkuil wrote:
>>> On Sunday 30 November 2008 20:16:07 Carl Karsten wrote:
>>>> Hans Verkuil wrote:
>>>>> On Sunday 30 November 2008 18:49:45 Carl Karsten wrote:
>>>>>> Hans Verkuil wrote:
>>>>>>> On Tuesday 25 November 2008 03:24:07 Carl Karsten wrote:
>>>>>>>> Hans Verkuil wrote:
>>>>>>>>> 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."
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>> 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 :-)
>>>>>
>>>>>>> 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.
>>>>>> 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...
>>>>
>>>>>> 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.
>>>> 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.
>>>
>>> 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.
>>
>> 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,

moving this back to the list - seems appropriate

> 
> 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.

This is exactly what I was planning on.

> 
> 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

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

As a baseline for what the test app would do when used against a proper driver.

I need a driver like what I hoped vivi was: can be run by anyone (it can) and
properly implements v4l2 api (questionable.  it currently hangs my kernel, so
that seems like a problem.)

A test driver would
1) help me make sure the test app works correctly.  as the test app is modified,
the automated test run would first use the test driver to make sure  the app is
not giving false reports.

2) when the close source driver fails the test app, the developer may want to
see an example of what code should look like that doesn't fail.

3) help test v4l apps, like transcode's v4l2_import module.

4) help me develop http://code.google.com/p/python-video4linux2/


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

That is one of my goals.

I also think the v4l community needs such a thing.  Otherwise I would not be
bothering the community :)

> (And why is it closed source anyway? 

to be clear: my relation to this product is a user.  my interest in helping the
development is because I want it to work for me.  Now to answer your question:

I think it is the same reason nvidia video drivers are.  In this case I think it
is to protect the compression algorithm that moves video data over usb2.

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

I am not working with the closed source code.  I am just trying to use it, and
submit bug reports when it isn't working.  Right now I am never sure if the bug
is in the closed source driver or the app.  having both a reliable test driver
and app would help this process.

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

and be a proficient kernel hacker.  which I am not.  but I have friends that are
willing to help if I can give them a reasonable goal.

And I hope to create some sort of liveCD (bootable thumb drive really) that
would test v4l2 drivers: boot, hardware is identified, modules loaded, tests
run, results displayed with an option to send them back to a central database.

Carl K

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: minimum v4l2 api - framework

[CityK]

Carl Karsten wrote:
> Hans Verkuil wrote:
>> 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

The bread crumbs start on the front page via the "Important Notice", but
anyhow, to cut out the chase:

http://www.linuxtv.org/wiki/index.php/Main_Page   >  User Section  >  
Having Trouble?  >  V4L Test Suite

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list