List:       linux-video
Subject:    [video4linux] New API spec proposals
From:       Bill Dirks < dirks () rendition ! com>
Date:       1998-07-25 3:04:40

I am not done yet, but I think you all should see what's here so far.
Stop me if I'm on a wrong track!
I'm attaching an html file to this message. (I don't have a website.
Yet.)

Bill.
["v4lprop.htm" (text/html)]

Web page

------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.

List:       linux-video
Subject:    Re: [video4linux] New API spec proposals
From:       Gerd Knorr <kraxel () goldbach ! isdn ! cs ! tu-berlin ! de>
Date:       1998-07-26 8:58:28

Bill Dirks <dirks@rendition.com> writes:

>   Content-Base: "file:///C|/WINDOWS/Desktop/v4lprop.htm"

Hmm.

>   However, it would be really good to support two opens on a device for
>   the purpose of having one open be for capturing, and the other for a
>   GUI control panel application that can change brightness, select
>   inputs, etc. along side the capturing application.

Good point.

>   Capture Image Format - VIDIOC_G_FMT, VIDIOC_S_FMT

[ ... ]

>   Devices will not be able to support every combination of width and
>   height. The driver will find the width and height compatible with the
>   hardware which are as close as possible to the requested width and
>   height without going over in either dimension. Applications must do a
>   VIDIOC_G_FMT to get the actual dimensions granted and make sure they
>   are suitable.

The sound driver returns the granted values on the *SET* ioctl's too, so
you don't have to call both SET and GET.

[ ... ]

>   Capturing Continuously to Pre-Allocated Buffers - VIDIOC_G_STREAM,
>   VIDIOC_S_STREAM, VIDIOC_MCAPTURE, VIDIOC_SYNC
>   
>   This capture mode is supported if the VID_TYPE_STREAM flag is set in
>   the struct capture_capabilities.
>   
>   I need help on this one! I guess similar to the way the Bt848 driver
>   is doing it now is the best we can do. The driver allocates
>   page-locked buffers in kernel space. The app uses VIDIOC_S_STREAM to
>   request how many buffers it wants, and VIDIOC_G_STREAM to find out how
>   many buffers the driver agreed to allocate. The layout of the buffers
>   is defined with VIDIOC_S_FMT.

I'll suggest to use the number of buffers and the size of the buffer for
that.  Same procedure with checking return values, so the driver can round
up the size to page boundaries, reduce the number of buffers, whatever...

>   If the format changes, the buffers are freed.

Allocate on mmap(), free on munmap().  Of cource you have to call S_STREAM
first, you'll don't know how much to mmap() else...

>   Mmap is used to map the buffers to user space. Calls to
>   VIDIOC_MCAPTURE add buffers to a queue. When a buffer is filled the
>   app is notified (VIDIOC_SYNC or select() unblocks?). Somehow the
>   caller needs to know which buffer is ready. When the app has consumed
>   the data it requeues the buffer again.

Both MCAPTURE and SYNC take a struct like this:

struct video_mmap {
	int			buffer;		/* which buffer ? */
	struct video_format	format;
	struct timeval		timestamp;
	int                     size;		/* used bytes if compressed */
	int			flags;
};

MCAPTURE queues the buffer, SYNC waits on that buffer.  App has to fill
buffer + video_format (+flags?), driver will return the other values.
For video_format apply the same rules like in S_FMT:  The driver might
round them to the nearest value supported by the hardware.

   Gerd

-- 
Gerd Knorr <kraxel@cs.tu-berlin.de>
------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.