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.