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
