To: Video for Linux List <video4linux-list@xxxxxxxxxx> 
Subject: V4L2 to-do list 
From: Bill Dirks <bdirks@xxxxxxxxxx> 
Date: Mon, 27 Aug 2001 19:44:15 -0700 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
Organization: Rendition 

The biggest question in my mind is should there be structural changes to
videodevX? I think there were roughly three possibilities:
1. videodevX does bare minimum, little beyond doling out minors. Drivers
export a regular fops that is called directly (except for open()) by the
kernel.
2. Drivers export a regular fops interface, but all calls go through
videodevX first. videodevX does more, like moving ioctl parameters
from/to user memory to/from kernel memory
3. Drivers export a designed-for-V4L2 interface, all calls go through
videodevX, and as much boilerplate code as makes sense is done by
videodevX

What's most Linux-like?

--
Here are my TO-DO's briefly:

+ videodevX design philosophy?

+ using user-space buffers for streaming capture

+ multiple tuners (I think the only problem here is that VIDIOC_*_FREQ
doesn't spec which tuner. there is a struct v4l2_frequency that was
never used. we can change VIDIOC_*_FREQ or make a new ioctl)

+ design /proc filesystem support

+ multiple capturing opens spec

+ interruptible streams (e.g. one program watching video, other catching
CC data; first program switches channel/input/etc. so no more CC; second
program is notified that CC stream has ended)

+ add two-plane Y/CbCr pixel formats

+ audio capture API

+ fixes for kernel internal changes in 2.5.x?

Bill.

To: video4linux-list@xxxxxxxxxx 
Subject: Re: V4L2 to-do list 
From: Gerd Knorr <kraxel@xxxxxxxxxxx> 
Date: 28 Aug 2001 08:59:54 GMT 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
Newsgroups: lists.linux.video4linux 
Organization: SuSE Labs, Außenstelle Berlin 
User-agent: slrn/0.9.7.0 (Linux) 

Bill Dirks wrote:
>  The biggest question in my mind is should there be structural changes to
>  videodevX? I think there were roughly three possibilities:
>  1. videodevX does bare minimum, little beyond doling out minors. Drivers
>  export a regular fops that is called directly (except for open()) by the
>  kernel.

This is what I'd like to see (and what the v4l2 patches used by bttv
0.8.x already do).

>  2. Drivers export a regular fops interface, but all calls go through
>  videodevX first. videodevX does more, like moving ioctl parameters
>  from/to user memory to/from kernel memory

My current v4l2 patches (the ones are used by bttv 0.8.x) have a mix of
these two:

+       /* new interface -- we will use file_operations directly
+        * like soundcore does.
+        * kernel_ioctl() will be called by video_generic_ioctl.
+        * video_generic_ioctl() does the userspace copying of the
+        * ioctl arguments */
+       struct file_operations *fops;
+       int (*kernel_ioctl)(struct inode *inode, struct file *file,
+                           unsigned int cmd, void *arg);

That isn't specific for v4l2 btw, v4l1 drivers can use
video_generic_ioctl() too to get rid of doing the userland copying
itself.

>  3. Drivers export a designed-for-V4L2 interface, all calls go through
>  videodevX, and as much boilerplate code as makes sense is done by
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  videodevX

I'd suspect that wouldn't be very much beside ioctl arg userspace
copying, the hardware supported by the available drivers is just too
different.

>  + videodevX design philosophy?

See above :-)

>  + using user-space buffers for streaming capture

A patch to do that without breaking binary compatibility is below.  On
the other hand I'm not sure whenever it is really a good idea to do
that:

 * It makes drivers and applications more complex.  We have three ways
   (read, mmap buffers, userland buffers) to do capture then.

 * Very likely not all drivers will support that, userland buffers are
   not very efficient for hardware which can not DMA directly to random
   pages (i.e. probably all USB cams).  Applications have to deal with
   the case that userland buffers are not supported by the driver.  We
   already have enought trouble with read vs. mmap today ...

 * I see very little use for it.  The classic example (MIT-SHM) is the
   _only_ application I can think of, and even in this case it will save
   the memcpy call only if there is no conversion needed.  You need
   userspace buffers only with multiple processes which are _not_
   related, for anything else it makes peformance-wise no difference
   whenever you use mmap() or userland buffers.

Comments?

>  + multiple tuners (I think the only problem here is that VIDIOC_*_FREQ
>  doesn't spec which tuner. there is a struct v4l2_frequency that was
>  never used. we can change VIDIOC_*_FREQ or make a new ioctl)

Depends whenever we want to break binary compatibility or not ...

>  + design /proc filesystem support

I'd just add some new field(s) to the existing 2.4.x procfs support
(i.e. type2 with v4l2 capabilities, ...).

>  + multiple capturing opens spec

My page about this is still online:
	http://bytesex.org/bttv/multiple-opens.html

>  + interruptible streams (e.g. one program watching video, other catching
>  CC data; first program switches channel/input/etc. so no more CC; second
>  program is notified that CC stream has ended)

Hmm.  Any idea how to do that?  return errors on system calls?  signals?

>  + add two-plane Y/CbCr pixel formats

One plane Y and one with CrCb interleaved?  i.e. just one more
V4L2_PIX_FMT_xxx?

>  + audio capture API

Why something new?  We can use either OSS or ALSA API ...

>  + fixes for kernel internal changes in 2.5.x?

I think we don't have to care about this _now_ was there is no 2.5.x yet
...

  Gerd

---------------------------- cut here -----------------------
--- my-2.4.9/include/linux/videodev2.h	Wed Aug 22 12:19:22 2001
+++ v4l2-2.4.9/include/linux/videodev2.h	Mon Aug 27 12:51:41 2001
@@ -75,6 +75,7 @@
 #define V4L2_FLAG_TUNER		0x00020 /* Can tune */
 #define V4L2_FLAG_MONOCHROME	0x00040 /* Monochrome only */
 #define V4L2_FLAG_DATA_SERVICE	0x00080 /* Has a related data service dev. */
+#define V4L2_FLAG_USERDMA       0x00100 /* Supports userspace buffers */
 
 
 /*
@@ -223,8 +224,11 @@
 {
 	int	count;
 	__u32	type;
-	__u32	reserved[2];
+	__u32	flags;
+	__u32	reserved[1];
 };
+#define V4L2_REQ_FLAG_USERDMA	0x0001
+
 struct v4l2_buffer
 {
 	int			index;
@@ -236,7 +240,14 @@
 	stamp_t			timestamp;
 	struct v4l2_timecode	timecode;
 	__u32			sequence;
-	__u32			reserved[3];
+	/* used instead of offset if V4L2_BUF_FLAG_USERDMA flag is set */
+	void                    *userptr;
+#if BITS_PER_LONG == 32
+	__u32			reserved[2];
+#endif
+#if BITS_PER_LONG == 64
+	__u32			reserved[1];
+#endif
 };
 /*  Buffer type codes and flags for 'type' field */
 #define V4L2_BUF_TYPE_field		0x00001FFF  /* Type field mask  */
@@ -273,6 +284,7 @@
 #define V4L2_BUF_FLAG_ODDFIELD	V4L2_BUF_FLAG_TOPFIELD
 #define V4L2_BUF_FLAG_EVENFIELD	V4L2_BUF_FLAG_BOTFIELD
 #define V4L2_BUF_FLAG_TIMECODE	0x0100	/* timecode field is valid */
+#define V4L2_BUF_FLAG_USERDMA	0x0200	/* userspace buffer */
 
 /*
  *	O V E R L A Y   P R E V I E W

To: video4linux-list@xxxxxxxxxx 
Subject: Re: Re: V4L2 to-do list 
From: Christopher Ross < ross@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 
Date: Tue, 28 Aug 2001 11:27:15 +0200 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
In-reply-to: < slrn9omnca.4t1.kraxel@xxxxxxxxxxx> 
Organization: Philips Research Laboratories, Eindhoven 

What's with National Semiconductor's "enhanced" version of the V4L2 API? 
Is that being merged back into the mainstream or are they doing their own 
thing?

http://www.linux4.tv/Projects/details.php?
id=2&PHPSESSID=05ad78c3e3af0500de6f190549b3e4fb

Regards,
Chris R.

On Tuesday 28 August 2001 10:59, Gerd Knorr wrote:
> Bill Dirks wrote:
> >  The biggest question in my mind is should there be structural
> > changes to videodevX? I think there were roughly three possibilities:
> >  1. videodevX does bare minimum, little beyond doling out minors.
> > Drivers export a regular fops that is called directly (except for
> > open()) by the kernel.
>
> This is what I'd like to see (and what the v4l2 patches used by bttv
> 0.8.x already do).
>
> >  2. Drivers export a regular fops interface, but all calls go through
> >  videodevX first. videodevX does more, like moving ioctl parameters
> >  from/to user memory to/from kernel memory
>
> My current v4l2 patches (the ones are used by bttv 0.8.x) have a mix of
> these two:
>
> +       /* new interface -- we will use file_operations directly
> +        * like soundcore does.
> +        * kernel_ioctl() will be called by video_generic_ioctl.
> +        * video_generic_ioctl() does the userspace copying of the
> +        * ioctl arguments */
> +       struct file_operations *fops;
> +       int (*kernel_ioctl)(struct inode *inode, struct file *file,
> +                           unsigned int cmd, void *arg);
>
> That isn't specific for v4l2 btw, v4l1 drivers can use
> video_generic_ioctl() too to get rid of doing the userland copying
> itself.
>
> >  3. Drivers export a designed-for-V4L2 interface, all calls go
> > through videodevX, and as much boilerplate code as makes sense is
> > done by
>
>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> >  videodevX
>
> I'd suspect that wouldn't be very much beside ioctl arg userspace
> copying, the hardware supported by the available drivers is just too
> different.
>
> >  + videodevX design philosophy?
>
> See above :-)
>
> >  + using user-space buffers for streaming capture
>
> A patch to do that without breaking binary compatibility is below.  On
> the other hand I'm not sure whenever it is really a good idea to do
> that:
>
>  * It makes drivers and applications more complex.  We have three ways
>    (read, mmap buffers, userland buffers) to do capture then.
>
>  * Very likely not all drivers will support that, userland buffers are
>    not very efficient for hardware which can not DMA directly to random
>    pages (i.e. probably all USB cams).  Applications have to deal with
>    the case that userland buffers are not supported by the driver.  We
>    already have enought trouble with read vs. mmap today ...
>
>  * I see very little use for it.  The classic example (MIT-SHM) is the
>    _only_ application I can think of, and even in this case it will
> save the memcpy call only if there is no conversion needed.  You need
> userspace buffers only with multiple processes which are _not_ related,
> for anything else it makes peformance-wise no difference whenever you
> use mmap() or userland buffers.
>
> Comments?
>
> >  + multiple tuners (I think the only problem here is that
> > VIDIOC_*_FREQ doesn't spec which tuner. there is a struct
> > v4l2_frequency that was never used. we can change VIDIOC_*_FREQ or
> > make a new ioctl)
>
> Depends whenever we want to break binary compatibility or not ...
>
> >  + design /proc filesystem support
>
> I'd just add some new field(s) to the existing 2.4.x procfs support
> (i.e. type2 with v4l2 capabilities, ...).
>
> >  + multiple capturing opens spec
>
> My page about this is still online:
> 	http://bytesex.org/bttv/multiple-opens.html
>
> >  + interruptible streams (e.g. one program watching video, other
> > catching CC data; first program switches channel/input/etc. so no
> > more CC; second program is notified that CC stream has ended)
>
> Hmm.  Any idea how to do that?  return errors on system calls? 
> signals?
>
> >  + add two-plane Y/CbCr pixel formats
>
> One plane Y and one with CrCb interleaved?  i.e. just one more
> V4L2_PIX_FMT_xxx?
>
> >  + audio capture API
>
> Why something new?  We can use either OSS or ALSA API ...
>
> >  + fixes for kernel internal changes in 2.5.x?
>
> I think we don't have to care about this _now_ was there is no 2.5.x
> yet ...
>
>   Gerd
>
> ---------------------------- cut here -----------------------
> --- my-2.4.9/include/linux/videodev2.h	Wed Aug 22 12:19:22 2001
> +++ v4l2-2.4.9/include/linux/videodev2.h	Mon Aug 27 12:51:41 2001
> @@ -75,6 +75,7 @@
>  #define V4L2_FLAG_TUNER		0x00020 /* Can tune */
>  #define V4L2_FLAG_MONOCHROME	0x00040 /* Monochrome only */
>  #define V4L2_FLAG_DATA_SERVICE	0x00080 /* Has a related data service
> dev. */ +#define V4L2_FLAG_USERDMA       0x00100 /* Supports userspace
> buffers */
>
>
>  /*
> @@ -223,8 +224,11 @@
>  {
>  	int	count;
>  	__u32	type;
> -	__u32	reserved[2];
> +	__u32	flags;
> +	__u32	reserved[1];
>  };
> +#define V4L2_REQ_FLAG_USERDMA	0x0001
> +
>  struct v4l2_buffer
>  {
>  	int			index;
> @@ -236,7 +240,14 @@
>  	stamp_t			timestamp;
>  	struct v4l2_timecode	timecode;
>  	__u32			sequence;
> -	__u32			reserved[3];
> +	/* used instead of offset if V4L2_BUF_FLAG_USERDMA flag is set */
> +	void                    *userptr;
> +#if BITS_PER_LONG == 32
> +	__u32			reserved[2];
> +#endif
> +#if BITS_PER_LONG == 64
> +	__u32			reserved[1];
> +#endif
>  };
>  /*  Buffer type codes and flags for 'type' field */
>  #define V4L2_BUF_TYPE_field		0x00001FFF  /* Type field mask  */
> @@ -273,6 +284,7 @@
>  #define V4L2_BUF_FLAG_ODDFIELD	V4L2_BUF_FLAG_TOPFIELD
>  #define V4L2_BUF_FLAG_EVENFIELD	V4L2_BUF_FLAG_BOTFIELD
>  #define V4L2_BUF_FLAG_TIMECODE	0x0100	/* timecode field is valid */
> +#define V4L2_BUF_FLAG_USERDMA	0x0200	/* userspace buffer */
>
>  /*
>   *	O V E R L A Y   P R E V I E W
>
>
>
> _______________________________________________
> Video4linux-list mailing list
> Video4linux-list@xxxxxxxxxx
> https://listman.redhat.com/mailman/listinfo/video4linux-list

To: video4linux-list@xxxxxxxxxx 
Subject: Re: V4L2 to-do list 
From: Gerd Knorr < kraxel@xxxxxxxxxxx> 
Date: 28 Aug 2001 10:16:41 GMT 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
Newsgroups: lists.linux.video4linux 
Organization: SuSE Labs, Außenstelle Berlin 
User-agent: slrn/0.9.7.0 (Linux) 

Christopher Ross wrote:
>  
>  What's with National Semiconductor's "enhanced" version of the V4L2 API? 

They hardly enhanced the v4l2 API, they just added a few device-specific
ioctls to setup a overlay / alpha bleeding / ...

>  Is that being merged back into the mainstream or are they doing their own 
>  thing?

I'd say they are doing their own thing.  I've never heared of them
before.  Beside that the new ioctls they added do not belong into v4l2.
That's a job for X11 (Xvideo) or the framebuffer driver (and the fbdev
folks are thinking about video overlay support).

  Gerd

To: video4linux-list@xxxxxxxxxx 
Subject: Re: Re: V4L2 to-do list 
From: Alan Cox <alan@xxxxxxxxxx> 
Date: Tue, 28 Aug 2001 06:48:33 -0400 (EDT) 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
In-reply-to: <200108280927.AA26158@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 
from "Christopher Ross" at Aug 28, 2001 11:27:15 AM 

> What's with National Semiconductor's "enhanced" version of the V4L2 API? 
> Is that being merged back into the mainstream or are they doing their own 
> thing?
> 
> http://www.linux4.tv/Projects/details.php?
> id=2&PHPSESSID=05ad78c3e3af0500de6f190549b3e4fb

Nat Semi have had no discussions with the community to my knowledge so 
whatever they are doing seems to be unrelated and pretty much irrelevant
to the real world

To: <video4linux-list@xxxxxxxxxx> 
Subject: Re: Re: V4L2 to-do list 
From: "Simon Turvey" <turveysp@xxxxxxxxxxxx> 
Date: Tue, 28 Aug 2001 11:54:03 +0100 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 

Still, it would seem churlish not to consider whether or not their work
(license permitting, as I'm sure it must) was worthy of folding back into
the mix, to misappropriate a culinary term. Unless, of course, Alan or
Bill's already looked at what they've done and dismissed it. In which
case I will defer to their far greater knowledge on such matters.


> > What's with National Semiconductor's "enhanced" version of the V4L2 API?
> > Is that being merged back into the mainstream or are they doing their
own
> > thing?
>
> Nat Semi have had no discussions with the community to my knowledge so
> whatever they are doing seems to be unrelated and pretty much irrelevant
> to the real world

To: video4linux-list@xxxxxxxxxx 
Subject: Re: V4L2 to-do list 
From: Alan Cox < alan@xxxxxxxxxx> 
Date: Tue, 28 Aug 2001 06:53:29 -0400 (EDT) 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
In-reply-to: <3B8B057F.850E2A10@xxxxxxxxxx> 
from "Bill Dirks" at Aug 27, 2001 07:44:15 PM 

> What's most Linux-like?

Reassigning file->f_ops so that after open the driver gets called
directoy, and then providing generic helpers for the common operations
in the videodev.c file - which is what I should have done from day 1 but
didnt

> + interruptible streams (e.g. one program watching video, other catching
> CC data; first program switches channel/input/etc. so no more CC; second
> program is notified that CC stream has ended)

How do you tell that from CC just going missing for a while (eg adverts)

> + audio capture API

audio capture has an API already. Its called drivers/sound/..

Alan

To: video4linux-list@xxxxxxxxxx 
Subject: Re: Re: V4L2 to-do list 
From: Alan Cox <alan@xxxxxxxxxx> 
Date: Tue, 28 Aug 2001 07:18:50 -0400 (EDT) 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
In-reply-to: <001201c12faf$c02de4e0$020ba8c0@xxxxxxxxxxx> 
from "Simon Turvey" at Aug 28, 2001 11:54:03 AM 

> Still, it would seem churlish not to consider whether or not their work
> (license permitting, as I'm sure it must) was worthy of folding back into
> the mix, to misappropriate a culinary term.  Unless, of course, Alan or
> Bill's already looked at what they've done and dismissed it.  In which
> case I will defer to their far greater knowledge on such matters.

I looked around their site briefly and what they had was all only
downloadable if you registered and stuff at that point, so I've not
bothered. I have better things to do with my time.

Alan

To: video4linux-list@xxxxxxxxxx 
Subject: Re: Re: V4L2 to-do list 
From: Christopher Ross ross@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 
Date: Tue, 28 Aug 2001 13:36:33 +0200 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
In-reply-to: < 200108281118.f7SBIo009471@xxxxxxxxxxxxxxxxxxxxxxxx> 
Organization: Philips Research Laboratories, Eindhoven 

Curious, the site didn't ask me to register or such.

I was thinking more along the lines of had *they* (Nat Semi) folded it 
back into the mix or forked a new version specifically for their machine?
Or now are we in the position of having another, different, version? One 
that works on their machine but not on anything else, but which includes 
useful stuff it would be nice if they gave back?

This is presumably a different fork from the Nokia stuff, the LinuxTV 
stuff et. al.

Chris R.

On Tuesday 28 August 2001 13:18, Alan Cox wrote:
> > Still, it would seem churlish not to consider whether or not their
> > work (license permitting, as I'm sure it must) was worthy of folding
> > back into the mix, to misappropriate a culinary term.  Unless, of
> > course, Alan or Bill's already looked at what they've done and
> > dismissed it.  In which case I will defer to their far greater
> > knowledge on such matters.
>
> I looked around their site briefly and what they had was all only
> downloadable if you registered and stuff at that point, so I've not
> bothered. I have better things to do with my time.
>
> Alan

To: video4linux-list@xxxxxxxxxx 
Subject: Re: Re: V4L2 to-do list 
From: Romain Vignes < romain@xxxxxxxxxxx> 
Date: Tue, 28 Aug 2001 14:20:11 +0200 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
Organization: eProcess 
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 

The reason why NSC (aka National Semiconductors) has been silent on their 
V4L2 project until now is that the Open Source aspect was not part of their 
initial plans. 


In order to get the same source code a few weeks ago, I had to spend some 
non-negligible time contacting NSC, obtaining and signing a NDA, describing 
my company and our projects to the NSC french representative, signing some 
more licence agreements ... 


Now, the source is available for the Open Source community and we should say 
"Bravo !" and thank NSC for this decision. They realized that the best way for 
encouraging linux developers to work on their Geode platform was the OSS way. 
Great !! 


But how to handle this specific V4L2 implementation ? Personally, I think it 
would be a bad decision to simply ignore it. In fact, they have added what was 
missing in the API for their specific needs, and now they give back their 
changes to the community. 


It is time for the "peer-review" process, ins't it ? After that, why not trying 
to establish a kind of convergence between the official V4L2 and the NSC-specific 
one ? 



Christopher Ross wrote:

> Curious, the site didn't ask me to register or such.


> I was thinking more along the lines of had *they* (Nat Semi) folded it 
> back into the mix or forked a new version specifically for their machine? 
> Or now are we in the position of having another, different, version? One 
> that works on their machine but not on anything else, but which includes 
> useful stuff it would be nice if they gave back? 


> This is presumably a different fork from the Nokia stuff, the LinuxTV 
> stuff et. al. 

> Chris R.

> On Tuesday 28 August 2001 13:18, Alan Cox wrote:


>>> Still, it would seem churlish not to consider whether or not their
>>> work (license permitting, as I'm sure it must) was worthy of folding
>>> back into the mix, to misappropriate a culinary term.  Unless, of
>>> course, Alan or Bill's already looked at what they've done and
>>> dismissed it.  In which case I will defer to their far greater
>>> knowledge on such matters.


>> I looked around their site briefly and what they had was all only
>> downloadable if you registered and stuff at that point, so I've not
>> bothered. I have better things to do with my time.

>> Alan





> _______________________________________________
> Video4linux-list mailing list
> Video4linux-list@xxxxxxxxxx
> https://listman.redhat.com/mailman/listinfo/video4linux-list





--
Romain Vignes 
Directeur Technique - eProcess
Tel: +33 (0)4 67 13 50 70

To: romain <romain@xxxxxxxxxxx>, video4linux-list@xxxxxxxxxx 
Subject: Re: Fwd: Re: Re: V4L2 to-do list] 
From: "Peter Lohmann" <Peter.Lohmann@xxxxxxx> 
Date: Tue, 28 Aug 2001 09:09:08 -0700 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 

Actually, open source was *always* the plan for our V4L2 driver (that's why we
started with a well accepted open source base API).  There are several layers
to the project, the kernel-mode layer being V4L2, the upper user-mode layer
being LinuxTV and our own middleware.  There is even application level
code witch uses a browser within Microwindows on an accellerated framebuffer.

If you look at the archive for this list you will see that we periodically sought
opinions from this forum -- and the feedback is reflected in the code.

However, you will find that there are significant architectural differences between
bttv (for example) and geode_v4l2.  First, geode_v4l2 uses a side-port video
decoder (saa7114).  It sends decoded digital video to the VIP using ITU656.
It also has a video encoder, enhanced VBI slicing support, and alpha blending,
(among many other things).  You may even think of this as somewhere between
GATOS and bttv.

Although other people here now work on this (and they have always lurked
on this list), I will tell you that we are *very* interested in your critique.  
I don't
speak for NSC (I'm just an engineer).  Most large companies are closed by
nature; and when you working within the open source community, there are
corporate cultural hurdles to be negotiated.  So, we were not being silent
to snub the community.

Thoughts?

     -- Peter





          romain@eproce
          ss.fr                To:     video4linux-list@xxxxxxxxxx@Internet
                               cc:     (bcc: Peter Lohmann/Americas/NSC)
          08/28/01             Subject:     Fwd: Re:  Re: V4L2 to-do list]


        


The reason why NSC (aka National Semiconductors) has been silent on
their V4L2 project until now is that the Open Source aspect was not part
of their initial plans.

In order to get the same source code a few weeks ago, I had to spend
some non-negligible time contacting NSC, obtaining and signing a NDA,
describing my company and our projects to the NSC french representative,
signing some more licence agreements ...

Now, the source is available for the Open Source community and we should
say "Bravo !" and thank NSC for this decision. They realized that the
best way for encouraging linux developers to work on their Geode
platform was the OSS way. Great !!

But how to handle this specific V4L2 implementation ? Personally, I
think it would be a bad decision to simply ignore it. In fact, they have
added what was missing in the API for their specific needs, and now they
give back their changes to the community.

It is time for the "peer-review" process, ins't it ? After that, why not
   trying to establish a kind of convergence between the official V4L2
and the NSC-specific one ?



Christopher Ross wrote:
 > Curious, the site didn't ask me to register or such.
 >
 > I was thinking more along the lines of had *they* (Nat Semi) folded it
 > back into the mix or forked a new version specifically for their machine?
 > Or now are we in the position of having another, different, version? One
 > that works on their machine but not on anything else, but which includes
 > useful stuff it would be nice if they gave back?
 >
 > This is presumably a different fork from the Nokia stuff, the LinuxTV
 > stuff et. al.
 >
 > Chris R.
 >
 > On Tuesday 28 August 2001 13:18, Alan Cox wrote:
 >
 >>>Still, it would seem churlish not to consider whether or not their
 >>>work (license permitting, as I'm sure it must) was worthy of folding
 >>>back into the mix, to misappropriate a culinary term.  Unless, of
 >>>course, Alan or Bill's already looked at what they've done and
 >>>dismissed it.  In which case I will defer to their far greater
 >>>knowledge on such matters.
 >>>
 >>I looked around their site briefly and what they had was all only
 >>downloadable if you registered and stuff at that point, so I've not
 >>bothered. I have better things to do with my time.
 >>
 >>Alan
 >>
 >
 >
 >
 > _______________________________________________
 > Video4linux-list mailing list
 > Video4linux-list@xxxxxxxxxx
 > https://listman.redhat.com/mailman/listinfo/video4linux-list
 >
 >


--
Romain Vignes < romain@xxxxxxxxxxx>
Directeur Technique - eProcess
Tel: +33 (0)4 67 13 50 70


--
Romain Vignes < romain@xxxxxxxxxxx>
Directeur Technique - eProcess
Tel: +33 (0)4 67 13 50 70



_______________________________________________
Video4linux-list mailing list
Video4linux-list@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/video4linux-list

To: video4linux-list@xxxxxxxxxx 
Subject: Re: Fwd: Re: Re: V4L2 to-do list] 
From: Alan Cox <alan@xxxxxxxxxx> 
Date: Tue, 28 Aug 2001 12:34:57 -0400 (EDT) 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
In-reply-to: <OF530849EA.8B9344EA-ON88256AB6.0055EF3A@xxxxxxx> 
from "Peter Lohmann" at Aug 28, 2001 09:09:08 AM 

> speak for NSC (I'm just an engineer).  Most large companies are closed by

Thanks for the background. Firstly Im curious why you would use video4linux
if the sidechannel is wired to the geode and could be driven by X11, is this
specifically a design decision that comes about though nanogui (which I'm
pleased to see is finding real users more and more now)

We do have other folks using these zv-bus and similar pixelstream inputs
but so far they have relied on X11 to do the work (indeed in many cases they
share registers with normal video ops so you'd go very rapidly mad trying to
do the locking).

A "Here is what we are adding and why" would be good to read. Mostly though
you should talk to Gerd. Video4linux for 2.5 is his ball now, although I
keep interfering when I shouldnt 

Alan

To: video4linux-list@xxxxxxxxxx 
Subject: Re: Fwd: Re: Re: V4L2 to-do list] 
From: "Peter Lohmann"  
Date: Tue, 28 Aug 2001 10:32:37 -0700 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 

To be honest, we didn't really know what we were doing (with regard to 
software peripheral
to Linux) when we started this.  We had a GTK+ application (on X) and a 
proprietary driver, neither
of which is still used.  The concensus was that X was too bloated, and 
we wanted to boot
from a disk-on-chip, if needed.  In fact, we see embedded Linux as the 
natural platform for
this hardware.  Hard drives are needed primarily for PVR in a set-top box.

So, running without X meant that we needed a good framework to do video 
and graphics.  We
saw V4L2 as better than V4L, and as a reasonable starting point for the 
kernel-mode support.
Someone here also recommended Microwindows as the user-mode interface -- 
and it has
worked well.  Many of us are familiar with the Win32 API, so this was a 
nice fit.  You will see on
the web site http://www.linux4.tv/ that Century Software has helped 
significantly with this project.

There is some documentation of the software architecture burried in the 
tar balls somewhere.
In it is where we had to deviate from the V4L2 API and why.  I agree that 
more is needed.

Because the Geode is an X86 processor, among many other things, there are 
some tricks
that we do with video to improve the quality (genlocking) and allow alpha 
blending and high
performance VBI capture.  These tricks are not supported in any existing 
API, as far as I know.
This is one of the reasons why we want to expose the code to the community 
-- so the best
solutions will eventually surface.

Thanks for your comments.

     -- Peter





          alan@xxxxxxxx
          om                   To:     video4linux-list@xxxxxxxxxx@Internet
                               cc:     romain@xxxxxxxxxxx@Internet, (bcc: Peter
          08/28/01             Lohmann/Americas/NSC)
          09:50 AM             Subject:     Re: Fwd: Re:  Re: V4L2 to-do list]
        
       



> speak for NSC (I'm just an engineer).  Most large companies are closed by

Thanks for the background. Firstly Im curious why you would use video4linux
if the sidechannel is wired to the geode and could be driven by X11, is this
specifically a design decision that comes about though nanogui (which I'm
pleased to see is finding real users more and more now)

We do have other folks using these zv-bus and similar pixelstream inputs
but so far they have relied on X11 to do the work (indeed in many cases they
share registers with normal video ops so you'd go very rapidly mad trying to
do the locking).

A "Here is what we are adding and why" would be good to read. Mostly though
you should talk to Gerd. Video4linux for 2.5 is his ball now, although I
keep interfering when I shouldnt

Alan



_______________________________________________
Video4linux-list mailing list
Video4linux-list@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/video4linux-list

To: video4linux-list@xxxxxxxxxx 
Subject: Re: Re: V4L2 to-do list 
From: Bill Dirks < bdirks@xxxxxxxxxx> 
Date: Tue, 28 Aug 2001 21:03:07 -0700 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
Organization: Rendition 

Alan Cox wrote:
> > What's with National Semiconductor's "enhanced" version of the V4L2 API?
> > Is that being merged back into the mainstream or are they doing their own
> > thing?
> Nat Semi have had no discussions with the community to my knowledge so
> whatever they are doing seems to be unrelated and pretty much irrelevant
> to the real world

They told me about it, and showed me a demo about a month ago. So far,
I'm just letting it be a driver-specific extension. I haven't looked at
the extensions in detail yet.

On their system, they're mainly just using V4L2 ioctls (plus extensions)
to route the video streams around the hardware in the box. No read(), no
mmap(), no select(). 

I am not, in principle, against incorporating STB overlay-type functions
into the API, but these devices tend to each have unique architectures
and internal routing and display-combining options. Hard to standardize.

Bill.

To: Video for Linux List <video4linux-list@xxxxxxxxxx> 
Subject: V4L2 to-do list, No.2 
From: Bill Dirks <bdirks@xxxxxxxxxx> 
Date: Tue, 28 Aug 2001 21:03:08 -0700 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
Organization: Rendition 

Again :)

+ Bring Gerd's V4L2 patches into the official release
+ Bring Gerd's multiple capturing opens into official spec
+ New FREQ ioctl for multiple tuners
+ New fields to /proc filesystem support
+ User-space buffers, Gerd's patch (?)
+ Interruptible streams (?)
+ Add two-plane Y/CbCr formats


Gerd Knorr wrote:
> >  + using user-space buffers for streaming capture
> 
> A patch to do that without breaking binary compatibility is below.  On
> the other hand I'm not sure whenever it is really a good idea to do
> that:
> 
>  * It makes drivers and applications more complex.  We have three ways
>    (read, mmap buffers, userland buffers) to do capture then.
> 
>  * Very likely not all drivers will support that, userland buffers are
>    not very efficient for hardware which can not DMA directly to random
> 
>  * I see very little use for it.  The classic example (MIT-SHM) is the
>    _only_ application I can think of, and even in this case it will save
> 
> Comments?

Looking at your patch, I see no reason not to add it. If nobody wants to
use it, then fine. But if someone is creating a application/driver pair
and has a compelling reason to use it, then there is a standardized way.

I just wonder if there is a system vulerability created by it. If a
malicious or broken app frees buffers while the driver is still hodling
them.


> >  + interruptible streams (e.g. one program watching video, other catching
> Hmm.  Any idea how to do that?  return errors on system calls?  signals?

I was thinking it could be as simple as DQBUF returns a specific error
code.


> >  + add two-plane Y/CbCr pixel formats
> One plane Y and one with CrCb interleaved?

Yes.

> i.e. just one more V4L2_PIX_FMT_xxx?

At least two: for 4:2:0 and 4:2:2. Also maybe CbCr vs. CrCb. A lot of
graphics cards are supporting these for YCbCr-space overlay, textures
and blits. Runs nicely on a dual-pipe accelerator.

Bill.

To: video4linux-list@xxxxxxxxxx 
Subject: Re: V4L2 to-do list, No.2 
From: Alan Cox < alan@xxxxxxxxxx> 
Date: Wed, 29 Aug 2001 04:22:34 -0400 (EDT) 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
In-reply-to: <3B8C697C.225BBC7D@xxxxxxxxxx> 
from "Bill Dirks" at Aug 28, 2001 09:03:08 PM 

> Looking at your patch, I see no reason not to add it. If nobody wants to
> use it, then fine. But if someone is creating a application/driver pair
> and has a compelling reason to use it, then there is a standardized way.

read() is surely the standard way 

> I just wonder if there is a system vulerability created by it. If a
> malicious or broken app frees buffers while the driver is still hodling
> them.

kiobufs handle the locking and refcounting, so providing the driver handles
its on pci posting/freeing order correctly all will be fine

To: video4linux-list@xxxxxxxxxx 
Subject: Re: V4L2 to-do list, No.2 
From: Gerd Knorr <kraxel@xxxxxxxxxxx> 
Date: 30 Aug 2001 10:47:52 GMT 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
Newsgroups: lists.linux.video4linux 
Organization: SuSE Labs, Außenstelle Berlin 
User-agent: slrn/0.9.7.0 (Linux) 

Bill Dirks wrote:
>  Again :)
>  
>  + New FREQ ioctl for multiple tuners

Also add tuners field to struct v4l2_capability?  Any good idea how to
name them?  Simply FREQ2?

>  + Add two-plane Y/CbCr formats

Which fourcc codes have these?


Uploaded new bttv releases: 0.7.77 (nice release number, isn't it?) +
0.8.25.  Also updated the v4l2 patches, they are available from
http://bytesex.org/v4l2/ now.


Short desciption of the patches:

pci64-2.4.10p2-1.patch.gz
	You need that one to build bttv 0.8.x, for highmem dma.

videodev-2.4.10-pre2.diff
	videodev changes -- adds fops and a ioctl wrapper function to
	copy userspace args.  That is the part I'd like to see in 2.4.x
	too.

v4l2-2.4.10-pre2.diff
	The v4l2 stuff (header file with all the structs + defines,
	v4l1 compatibility module, ...)

userdma-2.4.10-pre2.diff
	The userdma stuff.


Recent changes in the patches:

 * fixed build errors (due to min/max macro changes in 2.4.9).
 * use the new no_llseek everythere.
 * use do_div (see asm/div64.h) in v4l2_timestamp_divide to make that
   portable.  Left old code in with "#if 0" for reference, hope I got it
   right.


There is another application where userdma/zerocopy I/O would be useful:
When passing buffers from one to another device without memcpy()
inbetween.

This seems to work only for buffers in main memory through.  Trying to
mmap() video ram (using the framebuffer device), then pass that pointer
to bttv as destination buffer to make it start a PCI-PCI transfer does
not work.  The kiobufs code can't deal with that, I suspect because we
have no struct page* for I/O memory ...

  Gerd

-- 
Damn lot people confuse usability and eye-candy.

To: video4linux-list@xxxxxxxxxx 
Subject: Re: Re: V4L2 to-do list, No.2 
From: Alan Cox <alan@xxxxxxxxxx> 
Date: Thu, 30 Aug 2001 07:01:21 -0400 (EDT) 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
In-reply-to: <slrn9os6eo.469.kraxel@xxxxxxxxxxx> 
from "Gerd Knorr" at Aug 30, 2001 10:47:52 AM 

> This seems to work only for buffers in main memory through.  Trying to
> mmap() video ram (using the framebuffer device), then pass that pointer
> to bttv as destination buffer to make it start a PCI-PCI transfer does
> not work.  The kiobufs code can't deal with that, I suspect because we
> have no struct page* for I/O memory ...

Indeed. The pages have no physical mapping in the kernel. There is also
no guarantee a pci->pci transfer is possible as the pci devices may not
share common root bridges (I believe some sparcs have this problem)

One t ask DaveM abou for an API