To: video4linux <video4linux-list@xxxxxxxxxx>, bdirks@xxxxxxxxxxx,
Alan Cox <alan@xxxxxxxxxx>
Subject: [V4L] Common V4L1/V4L2 interface layer
From: Justin Schoeman <justin@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 05 Sep 2000 09:37:18 +0200
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx
Organization: University of Pretoria
Hi Everybody,
For a lot of people, the big problem with V4L2 has been the difficulty
of actually maintaining two seperate video4linux interfaces.
I have made an attempt to integrate the two interfaces in a single
layer. This layer operates in exactly the same way (in fact, for all
practical purposes, it is the same code) as the v4l1 and v4l2 videodev
layer. It allows both v4l1 and v4l2 device drivers to register, and
then based on the driver type, will use the correct interface layer to
talk between the user app and the driver.
This means that you should be able to do something like this:
1) Download and install videodevX (this package)
2) Download and install bttv2 or your favourite v4l2 driver.
3) modprobe bttv2
4) modprobe radio-cadet (or your favourite v4l1 driver).
5) run mp1e (on /dev/video0) and kradio (on /dev/radio0) at the same
time.
The interface layer SHOULD handle all the v4l1/2 specifics without any
user intervention.
Unfortunately, I only have a single Bt848 card (and no other v4l
devices), so I can't actually test this functionality - so if you have
multiple v4l1/2 devices, please test this out, and let me know!
-justin
Alan: A while ago, you said something like this was required to get
v4l2 into the kernel. Could you please have a look, and see if it was
what you were thinking of - you should be able to replace videodev.c and
videodev.h with these, without affecting the v4l1 drivers at all, but
still be able to load v4l2 drivers.
To: video4linux-list@xxxxxxxxxx
Subject: Re: [V4L] Common V4L1/V4L2 interface layer
From: kraxel@xxxxxxxxxxxxxxxxxxxxx (Gerd Knorr)
Date: 5 Sep 2000 19:10:09 GMT
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx
Newsgroups: lists.linux.v4l
Organization: Strusel 007
User-agent: slrn/0.9.6.2 (Linux)
> I have made an attempt to integrate the two interfaces in a single
> layer.
Cool.
> Alan: A while ago, you said something like this was required to get
> v4l2 into the kernel. Could you please have a look, and see if it was
> what you were thinking of - you should be able to replace videodev.c and
> videodev.h with these, without affecting the v4l1 drivers at all, but
> still be able to load v4l2 drivers.
Looks like you started with the 2.2.x videodev.c version, some stuff
which was added in 2.3/4.x is'nt there (very quick scan of the sources).
Before v4l2 can go in some minor issues should be fixed. Once
v4l2 is in the kernel (IMHO 2.5.x stuff, so we have some time...)
the API can't be changed easily, so this should be sorted first.
These come in mind:
* dma-to-userspace. For v4l1 backward compatibility the drivers
will have to support both kernel and userland buffers anyway, so
I'd extend the v4l2 interface to allow both. Adding a flag
to v4l2_buffer.flags to indicate dma-to-userspace and a
void* to v4l2_buffer for the actual pointer should work I think.
The application will still have to call VIDIOC_QUERYBUF to register
each of the userland buffers to allow the driver to lock down the
buffers between streamon and streamoff.
* multiple opens. I'd like to remove the open limitations (the no-io
opens currently in the API spec). IMHO this is just a documentation
and API spec issue.
It should be clear which ioctls will aquire + lock down ressources
(and may fail with -EBUSY if someone else uses the device) and
which ones free ressources. For capture this should be the
STREAMON/STREAMOFF ioctls I think, for overlay PREVIEW(0/1) should
do the trick.
Allowing multiple opens in the API does'nt mean that all drivers must
support it. I think this should be up to the driver. IMHO it should
be allowed for drivers to support single opens only like todays v4l1
drivers do.
Gerd
--
Protecting the children is a good way to get a lot of adults who cant
stand up for themselves. -- seen in some sig on /.
To: video4linux-list@xxxxxxxxxx, bdirks@xxxxxxxxxxx,
Gerd Knorr <kraxel@xxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [V4L] Common V4L1/V4L2 interface layer
From: Justin Schoeman <justin@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 06 Sep 2000 10:11:48 +0200
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx
Organization: University of Pretoria
Gerd Knorr wrote:
...snip...
> Looks like you started with the 2.2.x videodev.c version, some stuff
> which was added in 2.3/4.x is'nt there (very quick scan of the sources).
Yeah, I know - I just don't have the resources at the moment to keep
full 2.2 and 2.4 kernel trees. I will only do 2.4 when it is officially
released.
> Before v4l2 can go in some minor issues should be fixed. Once
> v4l2 is in the kernel (IMHO 2.5.x stuff, so we have some time...)
> the API can't be changed easily, so this should be sorted first.
> These come in mind:
>
> * dma-to-userspace. For v4l1 backward compatibility the drivers
> will have to support both kernel and userland buffers anyway, so
> I'd extend the v4l2 interface to allow both. Adding a flag
> to v4l2_buffer.flags to indicate dma-to-userspace and a
> void* to v4l2_buffer for the actual pointer should work I think.
>
> The application will still have to call VIDIOC_QUERYBUF to register
> each of the userland buffers to allow the driver to lock down the
> buffers between streamon and streamoff.
That is just what those reserved[] fields are for at the end of
v4l2_buffer. One of those can be used, and an extra flag field
implemented. Thanks to Bill Dirks, it seems v4l2 is very extensible...
(And thanks to luck/good planning DMA to userspace will work very well
with the current API!)
> * multiple opens. I'd like to remove the open limitations (the no-io
> opens currently in the API spec). IMHO this is just a documentation
> and API spec issue.
I would also like to have opens simply lock down the resources they
require.
> It should be clear which ioctls will aquire + lock down ressources
> (and may fail with -EBUSY if someone else uses the device) and
> which ones free ressources. For capture this should be the
> STREAMON/STREAMOFF ioctls I think, for overlay PREVIEW(0/1) should
> do the trick.
This goes with the point above...
> Allowing multiple opens in the API does'nt mean that all drivers must
> support it. I think this should be up to the driver. IMHO it should
> be allowed for drivers to support single opens only like todays v4l1
> drivers do.
This is allowed in the API as is currently specced.
An extra that I was think of was to take out the v4l1 backward
compatibility from v4l2, and make a separate module, a pseudo driver
which can plug in on a different minor, and provide a v4l1 interface to
another driver, and a similar module to provide a v4l2 interface to a
v4l1 driver. This way the interfaces could also be done at driver level
(ie a driver registers both a v4l1 and a v4l2 interface), to provide
optimal performance on both interfaces.
Any thoughts?
-justin
To: Justin Schoeman <justin@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: [V4L] Common V4L1/V4L2 interface layer
From: Gerd Knorr <kraxel@xxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 6 Sep 2000 22:39:30 +0200 (CEST)
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx
In-reply-to: <39B5FC44.EA6AE0E7@xxxxxxxxxxxxxxxxxxxx>
On Wed, 6 Sep 2000, Justin Schoeman wrote:
> That is just what those reserved[] fields are for at the end of
> v4l2_buffer. One of those can be used, and an extra flag field
> implemented.
It isn't *that* simple, as sizeof(void*) might be 32 or 64 bits depending
on the architecture. I'd simply add another field to avoid the ifdef mess
(because you'll need one or two if the reserved fields depending on arch)
Yes, I know, this will break (binary) compatibility of the v4l2 interface.
> > Allowing multiple opens in the API does'nt mean that all drivers must
> > support it. I think this should be up to the driver. IMHO it should
> > be allowed for drivers to support single opens only like todays v4l1
> > drivers do.
>
> This is allowed in the API as is currently specced.
Yes, of course. Last time I got responses along the lines "multiple opens
makes driver writing harder, that's why it is bad". That's why I wanted
make clear that supporting multiple opens isn't mandatory for the drivers.
> An extra that I was think of was to take out the v4l1 backward
> compatibility from v4l2, and make a separate module, a pseudo driver
> which can plug in on a different minor, and provide a v4l1 interface to
> another driver, and a similar module to provide a v4l2 interface to a
> v4l1 driver.
IHMO Bills approach (the driver has to support both, but there are some
helper functions for translating v1 <=> v2 provided by videodev.c) is
better.
> This way the interfaces could also be done at driver level
> (ie a driver registers both a v4l1 and a v4l2 interface), to provide
> optimal performance on both interfaces.
Why you want register two minors? Nothing stops a v4l2 driver to respond
to both v4l1 and v4l2 ioctls. The v4l1 ones can be handled by the driver
itself or simply passed to the helper functions in videodev.c. It can
even handle some ioctls the one and some the other way.
Gerd
--
Protecting the children is a good way to get a lot of adults who cant
stand up for themselves. -- seen in some sig on /.
To: video4linux-list@xxxxxxxxxx
Subject: Re: [V4L] Common V4L1/V4L2 interface layer
From: Bill Dirks <bdirks@xxxxxxxxxx>
Date: Wed, 06 Sep 2000 19:55:38 -0700
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx
Organization: Rendition
Gerd Knorr wrote:
> > > Allowing multiple opens in the API does'nt mean that all drivers must
> > > support it. I think this should be up to the driver. IMHO it should
> > > be allowed for drivers to support single opens only like todays v4l1
> > > drivers do.
> >
> > This is allowed in the API as is currently specced.
>
> Yes, of course. Last time I got responses along the lines "multiple opens
> makes driver writing harder, that's why it is bad". That's why I wanted
> make clear that supporting multiple opens isn't mandatory for the drivers.
Well, it does support multiple opens, but it is spec'd that only one
open can have capturing privileges.
Multiple capturing opens can produce subtle repercussions in the
sematics of various ioctls. For example, suppose an app opens a driver
and does a GET-FORMAT (or any other kind of query) while there are two
capturing opens active. The format of which open should be returned? If
the driver requires both opens to use the same format, which open gets
control, and will that mess up the app that doesn't have control?
Of course, a driver writer can do whatever he pleases behind the scenes,
as long the ioctl semantics are preserved such that apps, and therefore
users, are happy.
Bill.
To: "video4linux-list@xxxxxxxxxx" <video4linux-list@xxxxxxxxxx>
Subject: [V4L] Some thoughts about the current v4l <-> v4l2 discussion
From: M.Hunold@xxxxxxxxxxx (Michael Hunold)
Date: Sat, 09 Sep 2000 17:28:01 +0200
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx
Hello *,
I'd like to comment on the current v4l <->
v4l2 discussion, because I think that some things
are going in the wrong direction at the moment.
1) backward-compatibility layer in v4l2
I still donīt see the need of a v4l-backward
compatibility layer in v4l2. To be honest:
it's more or a less a 'bttv'-compatility layer,
trying to achive that old 'bttv'-applications
can run on the new 'bttv2'-driver, keeping
all the implicit dependencies and crappy
design.
I have written both v4l and v4l2-drivers for
my saa7146-based hardware. Although I tried
to make my v4l-driver as 'bttv' as possible,
it never worked with all applications, because
the apps used some implicit "features" of 'bttv'.
So, will my v4l2 driver work with old v4l-apps
using the compatibility layer? Most propably no.
Fact is: 'v4l' means 'bttv' in most cases. And
that's bad.
Again my suggestion is:
2) bringing v4l2 in parallel to v4l into the kernel
Why not simply assign a new major number to v4l2 and
make some new connections in /dev/?
With this, Justin's approach using a "videodevX" would
not be needed any more. You could load both "videodev.o"
and "videodev2.o" and use your old radio-drivers for
v4l and the new v4l2-driver for you video-hardware
for example.
Bringing new stuff in parallel into the kernel has
worked before, just look at the ext / ext2 - filesystem
switch.
Nobody has said: well, you have to add a compatibilty layer
to ext2, so it can work with old ext-partitions as well.
It was an complete overhaul, too.
As far as I know ext was marked obsolete and later
dropped from the kernel when nobody was using it anyway.
So, why not do this with v4l2? This would end the endless
discussion about adding stuff to the existing and working
v4l2-module. Who wants to use v4l can use v4l, but everyone
is encouraged to use v4l2. But the release of v4l2 to the
public world would not be delayed any more.
3) kiobufs
A good thing that should be added as soon as possible.
The idea is, that unswappable kernel memory is not locked
down any more when the app is not capturing at all or not
using the capture buffers at the moment.
But there were some questions, that have not been answered
in this mailing list yet:
What happens if the app releases the memory, although the
driver is still doing DMA to it? What about memory in regions
that cannot be addressed via DMA?
Have these things been solved?
4) multiple opens
To support multiple capturing opens is a good thing, when the hardware
can really deliver independent data from different sources.
For a simple tv-card, multiple capturing opens are a mess. The
discussion always states that the format of the capture should
be maintained with every open. But what about the other
parameters available?
My hardware has a tuner, 7 different audio inputs and 5 different
video inputs. (Yes, it's really asymmetrical.) What things do
I have to keep, too?
Do I have to keep everything, and whenever some app wants to access
the hardware, do I have to switch everything over and over?
I don't think that multiple capturing opens are worth the
effort. If I have different apps that are responsible for
capturing in different formats from different sources, they
can open the device, specify what they want, do the capture,
close the device and then wait for the next action. A script
+ cron can be used to do this on a regular time basis.
Why mess with multiple capturing opens that stay open for
a long while?
If I am doing serious video editing on the other hand, I simply
don't want other applications to mess with my current settings
anyway.
If multiple capturing opens should be supported, this should
be done using a userspace-library anyway. There is no need
to add the complexity to every other driver out there --
some simple hooks + userspace library are much better.
Ok, these are my thoughts. Any comments are welcome. 8-)
CU,
Michael.
To: video4linux-list@xxxxxxxxxx
Subject: Re: [V4L] Some thoughts about the current v4l <-> v4l2 discussion
From: kraxel@xxxxxxxxxxxxxxxxxxxxx (Gerd Knorr)
Date: 10 Sep 2000 07:13:16 GMT
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx
Newsgroups: lists.linux.v4l
Organization: Strusel 007
User-agent: slrn/0.9.6.2 (Linux)
> 1) backward-compatibility layer in v4l2
>
> I still donīt see the need of a v4l-backward
> compatibility layer in v4l2.
For drivers available with v4l it is mandatory
to keep compatibility. For others it is nice
to have.
> I have written both v4l and v4l2-drivers for
> my saa7146-based hardware. Although I tried
> to make my v4l-driver as 'bttv' as possible,
> it never worked with all applications, because
> the apps used some implicit "features" of 'bttv'.
They are broken then. xawtv had plenty of such
bugs too (maybe still has some).
> With this, Justin's approach using a "videodevX" would
> not be needed any more.
What is bad with this?
> You could load both "videodev.o"
> and "videodev2.o" and use your old radio-drivers for
> v4l and the new v4l2-driver for you video-hardware
> for example.
So you can with "videodevX.o".
> Nobody has said: well, you have to add a compatibilty layer
> to ext2, so it can work with old ext-partitions as well.
> It was an complete overhaul, too.
It's a different story. Your filesystem is either ext or ext2,
period. The v4l2 driver has to handle both v4l1 and v4l2
interfaces *at the same time* to be able to support both old
and new applications.
> 3) kiobufs
>
> But there were some questions, that have not been answered
> in this mailing list yet:
> What happens if the app releases the memory, although the
> driver is still doing DMA to it?
I'd expect kiobufs increase the reference counter for the page
while it is locked down so it will not be released until DMA
is done even if the application does. But I hav'nt checked the
kernel source yet.
> What about memory in regions
> that cannot be addressed via DMA?
return -EINVAL on QUERYBUF?
> Have these things been solved?
IMHO they have nothing to do with the API design.
> 4) multiple opens
>
> To support multiple capturing opens is a good thing, when the hardware
> can really deliver independent data from different sources.
>
> For a simple tv-card, multiple capturing opens are a mess. The
> discussion always states that the format of the capture should
> be maintained with every open. But what about the other
> parameters available?
Most of them need to be per-open too. Looks like I should go throuth
the API and write it down...
> I don't think that multiple capturing opens are worth the
> effort.
You don't _have_ to support multiple opens in the driver.
> Why mess with multiple capturing opens that stay open for
> a long while?
Having overlay (i.e. watch TV / check camera with xawtv) and
capture work in parallel is useful. I expect this will be
used more frequently than having two applications do capture
in parallel (at least with the common TV cards which can
capture from a single input source only).
> If multiple capturing opens should be supported, this should
> be done using a userspace-library anyway. There is no need
> to add the complexity to every other driver out there --
> some simple hooks + userspace library are much better.
(1) Supporting multiple opens is not mandatory.
(2) If a driver decides to support multiple opens it has to
keep multiple contexts anyway. I can't see how switching
them with "simple hooks" rather than with multiple
filehandles makes it easier for the driver.
Gerd
--
Protecting the children is a good way to get a lot of adults who cant
stand up for themselves. -- seen in some sig on /.
To: video4linux-list@xxxxxxxxxx
Subject: Re: [V4L] Some thoughts about the current v4l <-> v4l2 discussion
From: M.Hunold@xxxxxxxxxxx (Michael Hunold)
Date: Mon, 11 Sep 2000 11:05:52 +0200
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx
Hello Gerd,
> > With this, Justin's approach using a "videodevX" would
> > not be needed any more.
>
> What is bad with this?
>
> > You could load both "videodev.o"
> > and "videodev2.o" and use your old radio-drivers for
> > v4l and the new v4l2-driver for you video-hardware
> > for example.
>
> So you can with "videodevX.o".
Sure, but it's additional code, so it adds unnecessary
complexity.
But "videodevX.o" is not the problem -- as long as
it only dispatches apps to the right interface, that's
ok.
The thing that bothers me most is the backward
compatibility. (see below)
> > Nobody has said: well, you have to add a compatibilty layer
> > to ext2, so it can work with old ext-partitions as well.
> > It was an complete overhaul, too.
>
> It's a different story. Your filesystem is either ext or ext2,
> period. The v4l2 driver has to handle both v4l1 and v4l2
> interfaces *at the same time* to be able to support both old
> and new applications.
And that's the thing I don't understand. In my eyes it should
be either v4l or v4l2 - period. 8-)
v4l2 should not provide a half working compatibilty layer
(look at mmaping and capturing in general) for old v4l
applications. With this, you will never make a clear
statement like: v4l is obsolete, use v4l2 instead.
v4l2 should be integrated in the kernel -- I think we
all agree on that. But in my eyes it should be
as tight as possible. So, assigning a new major is
a solution or using "videodevX.o".
> > What about memory in regions
> > that cannot be addressed via DMA?
>
> return -EINVAL on QUERYBUF?
Another question: how can an application
force memory to be allocated in an DMA
accessible region?
(Perhaps this is trivial, but I never
have used such a machine...)
> > Have these things been solved?
>
> IMHO they have nothing to do with the API design.
Surely not, but if things are not working, designing
the API is unnecessary IMHO.
> Having overlay (i.e. watch TV / check camera with xawtv) and
> capture work in parallel is useful. I expect this will be
> used more frequently than having two applications do capture
> in parallel (at least with the common TV cards which can
> capture from a single input source only).
What do you mean exactly with "work in parallel"?
I can only think of this:
"capture" has a higher priority than overlay, e.g. if there
are two capturing opens (one overlay, one capture), starting
capture disables overlay. If capturing is stopped, overlay
is enabled again.
If one app is capturing, starting capturing with the other
app fails.
> > If multiple capturing opens should be supported, this should
> > be done using a userspace-library anyway. There is no need
> > to add the complexity to every other driver out there --
> > some simple hooks + userspace library are much better.
>
> (1) Supporting multiple opens is not mandatory.
> (2) If a driver decides to support multiple opens it has to
> keep multiple contexts anyway. I can't see how switching
> them with "simple hooks" rather than with multiple
> filehandles makes it easier for the driver.
The driver does not have to maintain a copy of all settings
for each open. Plus, not every driver needs to have the
necessary code for multiple opens -- only the existings
functions have to be supported.
All relevant aspects can be set via calls like S_FREQ, S_FMT,
S_CHAN. The userspace library can keep a copy of all these
parameters. Whenever an open wants to do capture, the library
checks if this is currently possible and then uses the
standard calls to set up everything according to the open.
But after thinking this over, I must admit
that this will most probably not work. One big problem is,
that the library cannot request multiple buffers and
then let the different apps mmap it. This could only be
done by heavily modifying both existing drivers plus
the existing v4l2 api. This is nothing I want either...
> Gerd
CU,
Michael.
To: video4linux < video4linux-list@xxxxxxxxxx>
Subject: [V4L] To Alan Cox: V4L1/V4L2 integration
From: Justin Schoeman < justin@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 31 Oct 2000 11:57:40 +0200
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx
Organization: University of Pretoria
Hi, Sorry for contacting you through the list like this. I have tried
sending directly to your e-mail address, but have received no reply -
I'm probably getting caught by your rather infamous mail filters...
Anyway, the subject of V4L1 and V4L2 integration is comming up very
frequently now, and I would like to get you opinion on it. Please read
the email below.
Thanks,
-justin
Hi, I am just following up on one of your emails to the v4l mailing
list a few months ago. Anyway, what you basically said was that for
V4L2 to be included in the kernel (2.5.x), it would have to be combined
with v4l1.
I have made a version (videodevX-ddmmyy.tgz at
http://bttv-v4l2.sourceforge.net/download) that does just this. It is
currently for 2.2.x kernels, but I am slowly merging in the 2.4.x
changes. Could you please have a look at this, and see if it is what
you had in mind? I would just like to make sure before I go through the
effort of getting all the 2.4.x stuff in.
Basically, v4l1 drivers register themselves with video_register_device,
and get placed in an array of v4l1 devices. v4l2 drivers register
themselves with v4l2_register_device, and get placed in an array of v4l2
devices. When a file operation is performed, it tests if the minor is a
valid v4l2 minor, if so, it is processed by the v4l2 layer, otherwise by
the v4l1 layer. It has been tested to work (at least for separate v4l1
and v4l2 devices, I have not yet had the opportunity to load a v4l1 and
v4l2 device simultaneously).
TIA,
-justin
To: video4linux-list@xxxxxxxxxx
Subject: Re: [V4L] To Alan Cox: V4L1/V4L2 integration
From: Alan Cox < alan@xxxxxxxxxx>
Date: Tue, 31 Oct 2000 07:03:24 -0500 (EST)
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx
In-reply-to: < 39FE9794.3C3C00B6@xxxxxxxxxxxxxxxxxxxx>
from "Justin Schoeman" at Oct 31, 2000 11:57:40 AM
Yes I saw that briefly. I've not had time to look at it in detail