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