Tech Insider					     Technology and Trends


	      Linux Video & DVD Project Mailing List Archives

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.

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO v IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/