v4l2-spec: move V4L1_API.html from v4l/API to this directory.

From: Hans Verkuil <hverkuil@xs4all.nl>

It is much more logical to put the V4L1 API with the V4L2 spec, rather than
in the hidden v4l/API directory.

Priority: normal

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

2 files changed, 24 insertions, 21 deletions

diff --git a/v4l2-spec/README b/v4l2-spec/README
index 6b0a3d0f1..9fe129642 100644
--- a/v4l2-spec/README
+++ b/v4l2-spec/README
@@ -15,3 +15,6 @@ html-single	A single HTML file (default)
 html		Tree of HTML files
 pdf		A PDF file
 coffeebreak 	All of the above
+
+Note: the V4L1_API.html is here just for reference. The V4L2 API replaces
+V4L1.
diff --git a/v4l/API/V4L1_API.html b/v4l2-spec/V4L1_API.html
index 50d282140..9f717fd50 100644
--- a/v4l/API/V4L1_API.html
+++ b/v4l2-spec/V4L1_API.html
@@ -10,7 +10,7 @@
 <H3>Devices</H3>
 Video4Linux provides the following sets of device files. These live on the
 character device formerly known as "/dev/bttv". /dev/bttv should be a
-symlink to /dev/video0 for most people. 
+symlink to /dev/video0 for most people.
 <P>
 <TABLE>
 <TR><TH>Device Name</TH><TH>Minor Range</TH><TH>Function</TH>
@@ -21,7 +21,7 @@ symlink to /dev/video0 for most people.
 </TABLE>
 <P>
 Video4Linux programs open and scan the devices to find what they are looking
-for. Capability queries define what each interface supports. The 
+for. Capability queries define what each interface supports. The
 described API is only defined for video capture cards. The relevant subset
 applies to radio cards. Teletext interfaces talk the existing VTX API.
 <P>
@@ -63,17 +63,17 @@ The minimum and maximum sizes listed for a capture device do not imply all
 that all height/width ratios or sizes within the range are possible. A
 request to set a size will be honoured by the largest available capture
 size whose capture is no large than the requested rectangle in either
-direction. For example the quickcam has 3 fixed settings. 
+direction. For example the quickcam has 3 fixed settings.
 <P>
 <H3>Frame Buffer</H3>
 Capture cards that drop data directly onto the frame buffer must be told the
-base address of the frame buffer, its size and organisation. This is a 
+base address of the frame buffer, its size and organisation. This is a
 privileged ioctl and one that eventually X itself should set.
 <P>
 The <b>VIDIOCSFBUF</b> ioctl sets the frame buffer parameters for a capture
 card. If the card does not do direct writes to the frame buffer then this
 ioctl will be unsupported. The <b>VIDIOCGFBUF</b> ioctl returns the
-currently used parameters. The structure used in both cases is a 
+currently used parameters. The structure used in both cases is a
 <b>struct video_buffer</b>.
 <P>
 <TABLE>
@@ -84,7 +84,7 @@ currently used parameters. The structure used in both cases is a
 <TR><TD><b>int bytesperline</b></TD><TD>Number of bytes of memory between the start of two adjacent lines</TD>
 </TABLE>
 <P>
-Note that these values reflect the physical layout of the frame buffer. 
+Note that these values reflect the physical layout of the frame buffer.
 The visible area may be smaller. In fact under XFree86 this is commonly the
 case. XFree86 DGA can provide the parameters required to set up this ioctl.
 Setting the base address to NULL indicates there is no physical frame buffer
@@ -92,9 +92,9 @@ access.
 <P>
 <H3>Capture Windows</H3>
 The capture area is described by a <b>struct video_window</b>. This defines
-a capture area and the clipping information if relevant. The 
-<b>VIDIOCGWIN</b> ioctl recovers the current settings and the 
-<b>VIDIOCSWIN</b> sets new values. A successful call to <b>VIDIOCSWIN</b> 
+a capture area and the clipping information if relevant. The
+<b>VIDIOCGWIN</b> ioctl recovers the current settings and the
+<b>VIDIOCSWIN</b> sets new values. A successful call to <b>VIDIOCSWIN</b>
 indicates that a suitable set of parameters have been chosen. They do not
 indicate that exactly what was requested was granted. The program should
 call <b>VIDIOCGWIN</b> to check if the nearest match was suitable. The
@@ -124,7 +124,7 @@ fields available to the user.
 Merely setting the window does not enable capturing. Overlay capturing
 (i.e. PCI-PCI transfer to the frame buffer of the video card)
 is activated by passing the <b>VIDIOCCAPTURE</b> ioctl a value of 1, and
-disabled by passing it a value of 0. 
+disabled by passing it a value of 0.
 <P>
 Some capture devices can capture a subfield of the image they actually see.
 This is indicated when VIDEO_TYPE_SUBCAPTURE is defined.
@@ -148,8 +148,8 @@ The available flags are
 </TABLE>
 <P>
 <H3>Video Sources</H3>
-Each video4linux video or audio device captures from one or more 
-source <b>channels</b>. Each channel can be queries with the 
+Each video4linux video or audio device captures from one or more
+source <b>channels</b>. Each channel can be queries with the
 <b>VDIOCGCHAN</b> ioctl call. Before invoking this function the caller
 must set the channel field to the channel that is being queried. On return
 the <b>struct video_channel</b> is filled in with information about the
@@ -158,7 +158,7 @@ nature of the channel itself.
 The <b>VIDIOCSCHAN</b> ioctl takes an integer argument and switches the
 capture to this input. It is not defined whether parameters such as colour
 settings or tuning are maintained across a channel switch. The caller should
-maintain settings as desired for each channel. (This is reasonable as 
+maintain settings as desired for each channel. (This is reasonable as
 different video inputs may have different properties).
 <P>
 The <b>struct video_channel</b> consists of the following
@@ -190,9 +190,9 @@ The types defined are
 <P>
 <H3>Image Properties</H3>
 The image properties of the picture can be queried with the <b>VIDIOCGPICT</b>
-ioctl which fills in a <b>struct video_picture</b>. The <b>VIDIOCSPICT</b> 
+ioctl which fills in a <b>struct video_picture</b>. The <b>VIDIOCSPICT</b>
 ioctl allows values to be changed. All values except for the palette type
-are scaled between 0-65535. 
+are scaled between 0-65535.
 <P>
 The <b>struct video_picture</b> consists of the following fields
 <P>
@@ -232,7 +232,7 @@ tuners attached.
 <P>
 Tuners are described by a <b>struct video_tuner</b> which can be obtained by
 the <b>VIDIOCGTUNER</b> ioctl. Fill in the tuner number in the structure
-then pass the structure to the ioctl to have the data filled in. The 
+then pass the structure to the ioctl to have the data filled in. The
 tuner can be switched using <b>VIDIOCSTUNER</b> which takes an integer argument
 giving the tuner to use. A struct tuner has the following fields
 <P>
@@ -274,7 +274,7 @@ frequency is obtained as an unsigned long via the <b>VIDIOCGFREQ</b> ioctl and
 set by the <b>VIDIOCSFREQ</b> ioctl.
 <P>
 <H3>Audio</H3>
-TV and Radio devices have one or more audio inputs that may be selected. 
+TV and Radio devices have one or more audio inputs that may be selected.
 The audio properties are queried by passing a <b>struct video_audio</b> to <b>VIDIOCGAUDIO</b> ioctl. The
 <b>VIDIOCSAUDIO</b> ioctl sets audio properties.
 <P>
@@ -323,7 +323,7 @@ A second way to handle image capture is via the mmap interface if supported.
 To use the mmap interface a user first sets the desired image size and depth
 properties. Next the VIDIOCGMBUF ioctl is issued. This reports the size
 of buffer to mmap and the offset within the buffer for each frame. The
-number of frames supported is device dependent and may only be one. 
+number of frames supported is device dependent and may only be one.
 <P>
 The video_mbuf structure contains the following fields
 <P>
@@ -390,11 +390,11 @@ groups of three, as follows:
 <TR><TD>Second Octet</TD><TD>Most Significant Byte of RDS Block
 <TR><TD>Third Octet</TD><TD>Bit 7:</TD><TD>Error bit.  Indicates that
 an uncorrectable error occurred during reception of this block.</TD></TR>
-<TR><TD>&nbsp;</TD><TD>Bit 6:</TD><TD>Corrected bit.  Indicates that  
+<TR><TD>&nbsp;</TD><TD>Bit 6:</TD><TD>Corrected bit.  Indicates that
 an error was corrected for this data block.</TD></TR>
-<TR><TD>&nbsp;</TD><TD>Bits 5-3:</TD><TD>Received Offset.  Indicates the  
+<TR><TD>&nbsp;</TD><TD>Bits 5-3:</TD><TD>Received Offset.  Indicates the
 offset received by the sync system.</TD></TR>
-<TR><TD>&nbsp;</TD><TD>Bits 2-0:</TD><TD>Offset Name.  Indicates the  
+<TR><TD>&nbsp;</TD><TD>Bits 2-0:</TD><TD>Offset Name.  Indicates the
 offset applied to this data.</TD></TR>
 </TABLE>
 </BODY>