DocBook: Update with the -git changes

From: Mauro Carvalho Chehab <mchehab@redhat.com>

After this patch, -git and -hg trees were updated to have the DocBook at
the kernel tree.

All duplicated info were removed.

Still pending: there are some dynamic files generated:
        media-entities.tmpl and media-indexes.tmpl:
                created from v4l and dvb *.xml files;
        *.c.xml *.h.xml:
                created from some in-trees and out-trees files.

We need a proccess to auto-generate those files every time
someone touches a file that affects the DocBook.

It would be possible to add the rules to generate some of
them at kernel's Makefile, but what to do with the out-of-tree
files? move them to kernel tree?

kernel-sync:

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

4 files changed, 11 insertions, 15 deletions

diff --git a/linux/Documentation/DocBook/v4l/common.xml b/linux/Documentation/DocBook/v4l/common.xml
index dd598ac9a..b1a81d246 100644
--- a/linux/Documentation/DocBook/v4l/common.xml
+++ b/linux/Documentation/DocBook/v4l/common.xml
@@ -506,15 +506,6 @@ are used for TV and radio devices alike. Drivers must support both
 ioctls when the tuner or modulator ioctls are supported, or
 when the device is a radio device.</para>
     </section>
-
-    <section>
-      <title>Satellite Receivers</title>
-
-      <para>To be discussed. See also <!-- private discussions of
-Peter Schlaf, BD & MHS on 23 Jun 1999 ff., subject "v4l2 and satellit" and -->
-proposals by Peter Schlaf, video4linux-list@redhat.com on 23 Oct 2002,
-subject: "Re: [V4L] Re: v4l2 api".</para>
-    </section>
   </section>
 
   <section id="standard">
@@ -802,7 +793,7 @@ optional.</para>
 a special ioctl to enumerate all image formats supported by video
 capture, overlay or output devices is available.<footnote>
 	  <para>Enumerating formats an application has no a-priori
-knowledge of (otherwise it could explicitely ask for them and need not
+knowledge of (otherwise it could explicitly ask for them and need not
 enumerate) seems useless, but there are applications serving as proxy
 between drivers and the actual video applications for which this is
 useful.</para>
diff --git a/linux/Documentation/DocBook/v4l/dev-teletext.xml b/linux/Documentation/DocBook/v4l/dev-teletext.xml
index 59f9993e1..76184e8ed 100644
--- a/linux/Documentation/DocBook/v4l/dev-teletext.xml
+++ b/linux/Documentation/DocBook/v4l/dev-teletext.xml
@@ -10,8 +10,8 @@ connected to the PC parallel port.</para>
 
   <para>The Teletext API was designed by Martin Buck. It is defined in
 the kernel header file <filename>linux/videotext.h</filename>, the
-specification is available from <ulink url="http://home.pages.de/~videotext/">
-http://home.pages.de/~videotext/</ulink>. (Videotext is the name of
+specification is available from <ulink url="ftp://ftp.gwdg.de/pub/linux/misc/videotext/">
+ftp://ftp.gwdg.de/pub/linux/misc/videotext/</ulink>. (Videotext is the name of
 the German public television Teletext service.) Conventional character
 device file names are <filename>/dev/vtx</filename> and
 <filename>/dev/vttuner</filename>, with device number 83, 0 and 83, 16
diff --git a/linux/Documentation/DocBook/v4l/pixfmt.xml b/linux/Documentation/DocBook/v4l/pixfmt.xml
index aaea55d44..ebfbed03d 100644
--- a/linux/Documentation/DocBook/v4l/pixfmt.xml
+++ b/linux/Documentation/DocBook/v4l/pixfmt.xml
@@ -157,7 +157,7 @@ used in the Windows world.</para>
     <!-- See proposal by Billy Biggs, video4linux-list@redhat.com
 on 11 Oct 2002, subject: "Re: [V4L] Re: v4l2 api", and
 http://vektor.theorem.ca/graphics/ycbcr/ and
-http://www.inforamp.net/~poynton/notes/colour_and_gamma/index.html -->
+http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html -->
 
     <para>
       <variablelist>
diff --git a/linux/Documentation/DocBook/v4l/remote_controllers.xml b/linux/Documentation/DocBook/v4l/remote_controllers.xml
index eb669537a..73f5eab09 100644
--- a/linux/Documentation/DocBook/v4l/remote_controllers.xml
+++ b/linux/Documentation/DocBook/v4l/remote_controllers.xml
@@ -2,8 +2,13 @@
 <section id="Remote_controllers_Intro">
 <title>Introduction</title>
 
-<para>Currently, most analog and digital devices have a Infrared input for remote controllers. Each manufacturer has their own type of control. It is not rare that the same manufacturer to ship different types of controls, depending on the device.</para>
-<para>Unfortunately, during several years, there weren't any effort to uniform the IR keycodes under different boards. This resulted that the same IR keyname to be mapped completely different on different IR's. Due to that, V4L2 API now specifies a standard for mapping Media keys on IR.</para>
+<para>Currently, most analog and digital devices have a Infrared input for remote controllers. Each
+manufacturer has their own type of control. It is not rare for the same manufacturer to ship different
+types of controls, depending on the device.</para>
+<para>Unfortunately, for several years, there was no effort to create uniform IR keycodes for
+different devices.  This caused the same IR keyname to be mapped completely differently on
+different IR devices. This resulted that the same IR keyname to be mapped completely different on
+different IR's. Due to that, V4L2 API now specifies a standard for mapping Media keys on IR.</para>
 <para>This standard should be used by both V4L/DVB drivers and userspace applications</para>
 <para>The modules register the remote as keyboard within the linux input layer. This means that the IR key strokes will look like normal keyboard key strokes (if CONFIG_INPUT_KEYBOARD is enabled). Using the event devices (CONFIG_INPUT_EVDEV) it is possible for applications to access the remote via /dev/input/event devices.</para>