List: linux-video
Subject: bttv-v4l2, afc and others
From: Justin Schoeman <justin () suntiger ! ee ! up ! ac ! za>
Date: 1999-11-25 18:02:32
Hi everybody,
bttv-v4l2 has now moved to sourceforge.net. The new URL is:
http://bttv-v4l2.sourceforge.net
The latest release has preliminary AFC support. Could the owners of cards
with AFC problems give it a try and see if it works? Where I am, the signals
are all spot-on, so AFC has no effect.
There is also a fairly complete i2c based common components interface there,
thanks to some great work by Kyosti Malkki. It opperates on (approximately)
the following principals:
v4l2 driver -> v4l2-cc -> i2c devices
It should be possible to easily incorporate the common components interface
into most v4l2 drivers, thereby dramatically improving code re-use. It may
also be possible to do the following (I am not 100% certain though):
v4l driver -> v4l-cc ->i2c devices
This would require writing v4l-cc to handle the translation of the V4L2
ioctls, but would enable everybody to use the same i2c modules. Any
ideas/feedback would be welcome.
The old site (http://www.ee.up.ac.za/~justin/v4l2) is now dedicated to v4l2
applications. I am currently developing a v4l2 based VCR application there.
It is currently barely functional, but can be used as a VCR. It requires +/-
500Mb/hour for recording video.
Thanks, and enjoy!
-justin
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: bttv-v4l2, afc and others
From: Gerd Knorr <kraxel () goldbach ! in-berlin ! de>
Date: 1999-11-25 19:27:40
> v4l driver -> v4l-cc ->i2c devices
> This would require writing v4l-cc to handle the translation of the V4L2
> ioctls, but would enable everybody to use the same i2c modules. Any
> ideas/feedback would be welcome.
bttv-0.7.x goes into this direction. Works without some v4l-cc module
inbetween right now, and the audio modules don't understand the v4l2
ioctls yet. But once they do they should run with both bttv-0.7.x and
bttv2.
Gerd
--
<script>alert("WARNING: You have JavaScript enabled.");</script>
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: bttv-v4l2, afc and others
From: Kyösti_Mälkki <kmalkki () cc ! hut ! fi>
Date: 1999-11-25 23:02:50
On Thu, 25 Nov 1999, Gerd Knorr wrote:
> > v4l driver -> v4l-cc ->i2c devices
> > This would require writing v4l-cc to handle the translation of the V4L2
> > ioctls, but would enable everybody to use the same i2c modules. Any
> > ideas/feedback would be welcome.
>
> bttv-0.7.x goes into this direction. Works without some v4l-cc module
> inbetween right now, and the audio modules don't understand the v4l2
> ioctls yet. But once they do they should run with both bttv-0.7.x and
> bttv2.
Now my question is, if it is worth the effort. There is backwards
compatibility mode to support V4L user applications with V4L2 drivers,
but as I understand V4L drivers cannot co-exist with V4L2 API. So
is it ever going to happen that both bttv-0.7.x and bttv2 exist on a
system?
Anyway, this can be solved with the addition of i2c ioctl command subsets
I recently proposed on the i2c-linux list. It is then possible to have
bttv-0.7.x and V4L2 API style ioctls in the same driver module.
The reason for a separate v4l2-cc module is the possibility of sharing
the code with other frame grabber chips besides BT848&friends.
It's main use will be dividing a V4L2 ioctl to smaller V4L2-CC ioctls:
i.e. Processing a single VIDIOC_S_INPUT usually requires access to
two i2c devices on a card, namely video and audio multiplexers.
The optimal case is that all client devices found on a new frame grabber
(or tv-) card are already supported. Once you program the support for
the i2c host adapter and add configuration information of the different
audio&video inputs on your card, you are ready to run.
--
Kyösti Mälkki
kmalkki@cc.hut.fi
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: bttv-v4l2, afc and others
From: Justin Schoeman <justin () suntiger ! ee ! up ! ac ! za>
Date: 1999-11-26 13:53:01
> On Thu, 25 Nov 1999, Gerd Knorr wrote:
>
> > > v4l driver -> v4l-cc ->i2c devices
> > > This would require writing v4l-cc to handle the translation of the V4L2
> > > ioctls, but would enable everybody to use the same i2c modules. Any
> > > ideas/feedback would be welcome.
> >
> > bttv-0.7.x goes into this direction. Works without some v4l-cc module
> > inbetween right now, and the audio modules don't understand the v4l2
> > ioctls yet. But once they do they should run with both bttv-0.7.x and
> > bttv2.
>
> Now my question is, if it is worth the effort. There is backwards
> compatibility mode to support V4L user applications with V4L2 drivers,
> but as I understand V4L drivers cannot co-exist with V4L2 API. So
> is it ever going to happen that both bttv-0.7.x and bttv2 exist on a
> system?
v4l2 in the official kernel is still a looong way away (I understand ther is
going to be a v4l+ API first). This, together with the fact that there are 1
or 2 audio patches every week on this list, means that it will save everybody
a lot of effort in the long run.
> Anyway, this can be solved with the addition of i2c ioctl command subsets
> I recently proposed on the i2c-linux list. It is then possible to have
> bttv-0.7.x and V4L2 API style ioctls in the same driver module.
>
> The reason for a separate v4l2-cc module is the possibility of sharing
> the code with other frame grabber chips besides BT848&friends.
> It's main use will be dividing a V4L2 ioctl to smaller V4L2-CC ioctls:
> i.e. Processing a single VIDIOC_S_INPUT usually requires access to
> two i2c devices on a card, namely video and audio multiplexers.
>
> The optimal case is that all client devices found on a new frame grabber
> (or tv-) card are already supported. Once you program the support for
> the i2c host adapter and add configuration information of the different
> audio&video inputs on your card, you are ready to run.
> Kyösti Mälkki
How I thought this could happen is for v4l-cc (and the v4l2 common components)
to have a private videodev2 include file. v4l-cc would then translate V4L
ioctls into v4l2 ioctls for passing to the v4l2 common components.
This is not the most efficient way of doing it from a v4l side, but the calls
are very infrequent, so a bit of inefficiency won't hurt too much.
-justin
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.