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
