2.4.19-pre8 != bk -rv2.4.19-pre8

[andrea gelmini <andrea.gelmini@linux.it>]

hi all,
	'diff -r' between 2.4.19-pre8 downloaded from ftp.kernel.org and
	the same version extracted from bitkeeper (parent is
	bk://linux.bkbits.net/linux-2.4), produce the follow diff. it's
	not a big issue, but it's a little annoying to apply -ac
	patches.

thanks for your work,
andrea gelmini


diff -r linux/Documentation/video4linux/API.html bk2.4.18/Documentation/video4linux/API.html
108c108
< <TR><TD><b>clips</b><TD>A list of clipping rectangles. <em>(Set only)</em)</TD>
---
> <TR><TD><b>clips</b><TD>A list of clipping rectangles. <em>(Set only)</em></TD>
122a123
> (i.e. PCI-PCI transfer to the frame buffer of the video card)
313,315c314,317
< Each call to the <b>read</b> syscall returns the next available image from
< the device. It is up to the caller to set the format and then to pass a 
< suitable size buffer and length to the function. Not all devices will support
---
> Each call to the <b>read</b> syscall returns the next available image
> from the device. It is up to the caller to set format and size (using
> the VIDIOCSPICT and VIDIOCSWIN ioctls) and then to pass a suitable
> size buffer and length to the function. Not all devices will support
332,341c334,366
< Once the mmap has been made the VIDIOCMCAPTURE ioctl sets the image size
< you wish to use (which should match or be below the initial query size).
< Having done so it will begin capturing to the memory mapped buffer. Whenever
< a buffer is "used" by the program it should called VIDIOCSYNC to free this
< frame up and continue. <em>to add:</em>VIDIOCSYNC takes the frame number
< you are freeing as its argument. When the buffer is unmapped or all the
< buffers are full capture ceases. While capturing to memory the driver will
< make a "best effort" attempt to capture to screen as well if requested. This
< normally means all frames that "miss" memory mapped capture will go to the
< display.
---
> Once the mmap has been made the VIDIOCMCAPTURE ioctl starts the
> capture to a frame using the format and image size specified in the
> video_mmap (which should match or be below the initial query size).
> When the VIDIOCMCAPTURE ioctl returns the frame is <em>not</em>
> captured yet, the driver just instructed the hardware to start the
> capture.  The application has to use the VIDIOCSYNC ioctl to wait
> until the capture of a frame is finished.  VIDIOCSYNC takes the frame
> number you want to wait for as argument.
> <p>
> It is allowed to call VIDIOCMCAPTURE multiple times (with different
> frame numbers in video_mmap->frame of course) and thus have multiple
> outstanding capture requests.  A simple way do to double-buffering
> using this feature looks like this:
> <pre>
> /* setup everything */
> VIDIOCMCAPTURE(0)
> while (whatever) {
>    VIDIOCMCAPTURE(1)
>    VIDIOCSYNC(0)
>    /* process frame 0 while the hardware captures frame 1 */
>    VIDIOCMCAPTURE(0)
>    VIDIOCSYNC(1)
>    /* process frame 1 while the hardware captures frame 0 */
> }
> </pre>
> Note that you are <em>not</em> limited to only two frames.  The API
> allows up to 32 frames, the VIDIOCGMBUF ioctl returns the number of
> frames the driver granted.  Thus it is possible to build deeper queues
> to avoid loosing frames on load peaks.
> <p>
> While capturing to memory the driver will make a "best effort" attempt
> to capture to screen as well if requested. This normally means all
> frames that "miss" memory mapped capture will go to the display.
Only in linux/arch/mips: .gdbinit
Only in bk2.4.18/drivers/net/wan/8253x: build
Only in linux/drivers/sound: .indent.pro
Only in linux/drivers/sound: .version