Remove audio and video DVBv5 API

Remove audio and video DVBv5 API

[Hans Verkuil]

During the 2011 workshop we discussed replacing the decoder commands in
include/linux/dvb/video.h and audio.h by a proper V4L2 API.

This patch series does that. It adds new VIDIOC_(TRY_)DECODER_CMD
ioctls to the V4L2 API. These are identical to the VIDEO_(TRY_)COMMAND from
dvb/video.h, but the names of the fields and defines now conform to the V4L2
API conventions.

Also new controls are added to replace the remaining functionality needed
by ivtv.

The new API has been documented. The ivtv.h header has been extended with
the 'old' DVB API, making ivtv independent from the old headers.

A new av7110.h header has been created that does the same for the av7110.h
driver. All the existing relevant DocBook documentation regarding those
DVB audio and video APIs has been copied as comments to the av7110.h header.

As a final step the old headers and documentation have been removed.

Feedback is welcome.

Regards,

	Hans

[RFCv2 PATCH 01/12] v4l2: add VIDIOC_(TRY_)DECODER_CMD.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

As discussed during the 2011 V4L-DVB workshop, the API in dvb/video.h should
be replaced by a proper V4L2 API. This patch turns the VIDEO_(TRY_)DECODER_CMD
ioctls into proper V4L2 ioctls.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 drivers/media/video/v4l2-compat-ioctl32.c |    2 +
 drivers/media/video/v4l2-ioctl.c          |   28 +++++++++++++++
 include/linux/videodev2.h                 |   53 +++++++++++++++++++++++++++++
 include/media/v4l2-ioctl.h                |    4 ++
 4 files changed, 87 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/v4l2-compat-ioctl32.c b/drivers/media/video/v4l2-compat-ioctl32.c
index c68531b..ffd9b1e 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -1003,6 +1003,8 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int cmd, unsigned long arg)
 	case VIDIOC_G_ENC_INDEX:
 	case VIDIOC_ENCODER_CMD:
 	case VIDIOC_TRY_ENCODER_CMD:
+	case VIDIOC_DECODER_CMD:
+	case VIDIOC_TRY_DECODER_CMD:
 	case VIDIOC_DBG_S_REGISTER:
 	case VIDIOC_DBG_G_REGISTER:
 	case VIDIOC_DBG_G_CHIP_IDENT:
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index e1da8fc..2355510 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -258,6 +258,8 @@ static const char *v4l2_ioctls[] = {
 	[_IOC_NR(VIDIOC_ENCODER_CMD)] 	   = "VIDIOC_ENCODER_CMD",
 	[_IOC_NR(VIDIOC_TRY_ENCODER_CMD)]  = "VIDIOC_TRY_ENCODER_CMD",
 
+	[_IOC_NR(VIDIOC_DECODER_CMD)]	   = "VIDIOC_DECODER_CMD",
+	[_IOC_NR(VIDIOC_TRY_DECODER_CMD)]  = "VIDIOC_TRY_DECODER_CMD",
 	[_IOC_NR(VIDIOC_DBG_S_REGISTER)]   = "VIDIOC_DBG_S_REGISTER",
 	[_IOC_NR(VIDIOC_DBG_G_REGISTER)]   = "VIDIOC_DBG_G_REGISTER",
 
@@ -1658,6 +1660,32 @@ static long __video_do_ioctl(struct file *file,
 			dbgarg(cmd, "cmd=%d, flags=%x\n", p->cmd, p->flags);
 		break;
 	}
+	case VIDIOC_DECODER_CMD:
+	{
+		struct v4l2_decoder_cmd *p = arg;
+
+		if (!ops->vidioc_decoder_cmd)
+			break;
+		if (ret_prio) {
+			ret = ret_prio;
+			break;
+		}
+		ret = ops->vidioc_decoder_cmd(file, fh, p);
+		if (!ret)
+			dbgarg(cmd, "cmd=%d, flags=%x\n", p->cmd, p->flags);
+		break;
+	}
+	case VIDIOC_TRY_DECODER_CMD:
+	{
+		struct v4l2_decoder_cmd *p = arg;
+
+		if (!ops->vidioc_try_decoder_cmd)
+			break;
+		ret = ops->vidioc_try_decoder_cmd(file, fh, p);
+		if (!ret)
+			dbgarg(cmd, "cmd=%d, flags=%x\n", p->cmd, p->flags);
+		break;
+	}
 	case VIDIOC_G_PARM:
 	{
 		struct v4l2_streamparm *p = arg;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4b752d5..406f7f7 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1849,6 +1849,54 @@ struct v4l2_encoder_cmd {
 	};
 };
 
+/* Decoder commands */
+#define V4L2_DEC_CMD_START       (0)
+#define V4L2_DEC_CMD_STOP        (1)
+#define V4L2_DEC_CMD_PAUSE       (2)
+#define V4L2_DEC_CMD_RESUME      (3)
+
+/* Flags for V4L2_DEC_CMD_START */
+#define V4L2_DEC_CMD_START_MUTE_AUDIO	(1 << 0)
+
+/* Flags for V4L2_DEC_CMD_PAUSE */
+#define V4L2_DEC_CMD_PAUSE_TO_BLACK	(1 << 0)
+
+/* Flags for V4L2_DEC_CMD_STOP */
+#define V4L2_DEC_CMD_STOP_TO_BLACK	(1 << 0)
+#define V4L2_DEC_CMD_STOP_IMMEDIATELY	(1 << 1)
+
+/* Play format requirements (returned by the driver): */
+
+/* The decoder has no special format requirements */
+#define V4L2_DEC_START_FMT_NONE		(0)
+/* The decoder requires full GOPs */
+#define V4L2_DEC_START_FMT_GOP		(1)
+
+/* The structure must be zeroed before use by the application
+   This ensures it can be extended safely in the future. */
+struct v4l2_decoder_cmd {
+	__u32 cmd;
+	__u32 flags;
+	union {
+		struct {
+			__u64 pts;
+		} stop;
+
+		struct {
+			/* 0 or 1000 specifies normal speed,
+			   1 specifies forward single stepping,
+			   -1 specifies backward single stepping,
+			   >1: playback at speed/1000 of the normal speed,
+			   <-1: reverse playback at (-speed/1000) of the normal speed. */
+			__s32 speed;
+			__u32 format;
+		} start;
+
+		struct {
+			__u32 data[16];
+		} raw;
+	};
+};
 #endif
 
 
@@ -2255,6 +2303,11 @@ struct v4l2_create_buffers {
 #define VIDIOC_CREATE_BUFS	_IOWR('V', 92, struct v4l2_create_buffers)
 #define VIDIOC_PREPARE_BUF	_IOWR('V', 93, struct v4l2_buffer)
 
+/* Experimental, these two ioctls may change over the next couple of kernel
+   versions. */
+#define VIDIOC_DECODER_CMD	_IOWR('V', 94, struct v4l2_decoder_cmd)
+#define VIDIOC_TRY_DECODER_CMD	_IOWR('V', 95, struct v4l2_decoder_cmd)
+
 /* Reminder: when adding new ioctls please add support for them to
    drivers/media/video/v4l2-compat-ioctl32.c as well! */
 
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index 4d1c74a..46c13ba 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -207,6 +207,10 @@ struct v4l2_ioctl_ops {
 					struct v4l2_encoder_cmd *a);
 	int (*vidioc_try_encoder_cmd)  (struct file *file, void *fh,
 					struct v4l2_encoder_cmd *a);
+	int (*vidioc_decoder_cmd)      (struct file *file, void *fh,
+					struct v4l2_decoder_cmd *a);
+	int (*vidioc_try_decoder_cmd)  (struct file *file, void *fh,
+					struct v4l2_decoder_cmd *a);
 
 	/* Stream type-dependent parameter ioctls */
 	int (*vidioc_g_parm)           (struct file *file, void *fh,
-- 
1.7.7.3

[RFCv2 PATCH 02/12] v4l spec: document VIDIOC_(TRY_)DECODER_CMD.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 Documentation/DocBook/media/v4l/v4l2.xml           |    1 +
 .../DocBook/media/v4l/vidioc-decoder-cmd.xml       |  256 ++++++++++++++++++++
 .../DocBook/media/v4l/vidioc-encoder-cmd.xml       |    9 +-
 3 files changed, 262 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml

diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml
index 2ab365c..7fc11db 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -473,6 +473,7 @@ and discussions on the V4L mailing list.</revremark>
     &sub-cropcap;
     &sub-dbg-g-chip-ident;
     &sub-dbg-g-register;
+    &sub-decoder-cmd;
     &sub-dqevent;
     &sub-encoder-cmd;
     &sub-enumaudio;
diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
new file mode 100644
index 0000000..466fe27
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
@@ -0,0 +1,256 @@
+<refentry id="vidioc-decoder-cmd">
+  <refmeta>
+    <refentrytitle>ioctl VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD</refentrytitle>
+    &manvol;
+  </refmeta>
+
+  <refnamediv>
+    <refname>VIDIOC_DECODER_CMD</refname>
+    <refname>VIDIOC_TRY_DECODER_CMD</refname>
+    <refpurpose>Execute an decoder command</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcprototype>
+	<funcdef>int <function>ioctl</function></funcdef>
+	<paramdef>int <parameter>fd</parameter></paramdef>
+	<paramdef>int <parameter>request</parameter></paramdef>
+	<paramdef>struct v4l2_decoder_cmd *<parameter>argp</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Arguments</title>
+
+    <variablelist>
+      <varlistentry>
+	<term><parameter>fd</parameter></term>
+	<listitem>
+	  <para>&fd;</para>
+	</listitem>
+      </varlistentry>
+      <varlistentry>
+	<term><parameter>request</parameter></term>
+	<listitem>
+	  <para>VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD</para>
+	</listitem>
+      </varlistentry>
+      <varlistentry>
+	<term><parameter>argp</parameter></term>
+	<listitem>
+	  <para></para>
+	</listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Description</title>
+
+    <note>
+      <title>Experimental</title>
+
+      <para>This is an <link linkend="experimental">experimental</link>
+interface and may change in the future.</para>
+    </note>
+
+    <para>These ioctls control an audio/video (usually MPEG-) decoder.
+<constant>VIDIOC_DECODER_CMD</constant> sends a command to the
+decoder, <constant>VIDIOC_TRY_DECODER_CMD</constant> can be used to
+try a command without actually executing it. To send a command applications
+must initialize all fields of a &v4l2-decoder-cmd; and call
+<constant>VIDIOC_DECODER_CMD</constant> or <constant>VIDIOC_TRY_DECODER_CMD</constant>
+with a pointer to this structure.</para>
+
+    <para>The <structfield>cmd</structfield> field must contain the
+command code. Some commands use the <structfield>flags</structfield> field for
+additional information.
+</para>
+
+    <para>A <function>write</function>() or &VIDIOC-STREAMON; call sends an implicit
+START command to the decoder if it has not been started yet.
+</para>
+
+    <para>A <function>close</function>() or &VIDIOC-STREAMOFF; call of a streaming
+file descriptor sends an implicit immediate STOP command to the decoder, and all
+buffered data is discarded.</para>
+
+    <para>These ioctls are optional, not all drivers may support
+them. They were introduced in Linux 3.3.</para>
+
+    <table pgwide="1" frame="none" id="v4l2-decoder-cmd">
+      <title>struct <structname>v4l2_decoder_cmd</structname></title>
+      <tgroup cols="5">
+	&cs-str;
+	<tbody valign="top">
+	  <row>
+	    <entry>__u32</entry>
+	    <entry><structfield>cmd</structfield></entry>
+            <entry></entry>
+            <entry></entry>
+	    <entry>The decoder command, see <xref linkend="decoder-cmds" />.</entry>
+	  </row>
+	  <row>
+	    <entry>__u32</entry>
+	    <entry><structfield>flags</structfield></entry>
+            <entry></entry>
+            <entry></entry>
+	    <entry>Flags to go with the command. If no flags are defined for
+this command, drivers and applications must set this field to zero.</entry>
+	  </row>
+	  <row>
+	    <entry>union</entry>
+	    <entry>(anonymous)</entry>
+            <entry></entry>
+	    <entry></entry>
+            <entry></entry>
+	  </row>
+	  <row>
+	    <entry></entry>
+	    <entry>struct</entry>
+            <entry><structfield>start</structfield></entry>
+            <entry></entry>
+            <entry>Structure containing additional data for the
+<constant>V4L2_DEC_CMD_START</constant> command.</entry>
+	  </row>
+	  <row>
+            <entry></entry>
+            <entry></entry>
+	    <entry>__u32</entry>
+	    <entry><structfield>speed</structfield></entry>
+            <entry>Playback speed and direction. The playback speed is defined as
+<structfield>speed</structfield>/1000 of the normal speed. So 1000 is normal playback.
+Negative numbers denote reverse playback, so -1000 does reverse playback at normal
+speed. Speeds -1, 0 and 1 have special meanings: speed 0 is shorthand for 1000
+(normal playback). A speed of 1 steps just one frame forward, a speed of -1 steps
+just one frame back.
+	    </entry>
+	  </row>
+	  <row>
+            <entry></entry>
+            <entry></entry>
+	    <entry>__u32</entry>
+	    <entry><structfield>format</structfield></entry>
+            <entry>Format restrictions. This field is set by the driver, not the
+application. Possible values are <constant>V4L2_DEC_START_FMT_NONE</constant> if
+there are no format restrictions or <constant>V4L2_DEC_START_FMT_GOP</constant>
+if the decoder operates on full GOPs (<wordasword>Group Of Pictures</wordasword>).
+This is usually the case for reverse playback: the decoder needs full GOPs, which
+it can then play in reverse order. So to implement reverse playback the application
+must feed the decoder the last GOP in the video file, then the GOP before that, etc. etc.
+	    </entry>
+	  </row>
+	  <row>
+	    <entry></entry>
+	    <entry>struct</entry>
+            <entry><structfield>stop</structfield></entry>
+            <entry></entry>
+            <entry>Structure containing additional data for the
+<constant>V4L2_DEC_CMD_STOP</constant> command.</entry>
+	  </row>
+	  <row>
+            <entry></entry>
+            <entry></entry>
+	    <entry>__u64</entry>
+	    <entry><structfield>pts</structfield></entry>
+            <entry>Stop playback at this <structfield>pts</structfield> or immediately
+if the playback is already past that timestamp. Leave to 0 if you want to stop after the
+last frame was decoded.
+	    </entry>
+	  </row>
+	  <row>
+	    <entry></entry>
+	    <entry>struct</entry>
+            <entry><structfield>raw</structfield></entry>
+            <entry></entry>
+            <entry></entry>
+	  </row>
+	  <row>
+            <entry></entry>
+            <entry></entry>
+	    <entry>__u32</entry>
+	    <entry><structfield>data</structfield>[16]</entry>
+	    <entry>Reserved for future extensions. Drivers and
+applications must set the array to zero.</entry>
+	  </row>
+	</tbody>
+      </tgroup>
+    </table>
+
+    <table pgwide="1" frame="none" id="decoder-cmds">
+      <title>Decoder Commands</title>
+      <tgroup cols="3">
+	&cs-def;
+	<tbody valign="top">
+	  <row>
+	    <entry><constant>V4L2_DEC_CMD_START</constant></entry>
+	    <entry>0</entry>
+	    <entry>Start the decoder. When the decoder is already
+running or paused, this command will just change the playback speed.
+That means that calling <constant>V4L2_DEC_CMD_START</constant> when
+the decoder was paused will <emphasis>not</emphasis> resume the decoder.
+You have to explicitly call <constant>V4L2_DEC_CMD_RESUME</constant> for that.
+This command has one flag:
+<constant>V4L2_DEC_CMD_START_MUTE_AUDIO</constant>. If set, then audio will
+be muted when playing back at a non-standard speed.
+            </entry>
+	  </row>
+	  <row>
+	    <entry><constant>V4L2_DEC_CMD_STOP</constant></entry>
+	    <entry>1</entry>
+	    <entry>Stop the decoder. When the decoder is already stopped,
+this command does nothing. This command has two flags:
+if <constant>V4L2_DEC_CMD_STOP_TO_BLACK</constant> is set, then the decoder will
+set the picture to black after it stopped decoding. Otherwise the last image will
+repeat. If <constant>V4L2_DEC_CMD_STOP_IMMEDIATELY</constant> is set, then the decoder
+stops immediately (ignoring the <structfield>pts</structfield> value), otherwise it
+will keep decoding until timestamp >= pts or until the last of the pending data from
+its internal buffers was decoded.
+</entry>
+	  </row>
+	  <row>
+	    <entry><constant>V4L2_DEC_CMD_PAUSE</constant></entry>
+	    <entry>2</entry>
+	    <entry>Pause the decoder. When the decoder has not been
+started yet, the driver will return an &EPERM;. When the decoder is
+already paused, this command does nothing. This command has one flag:
+if <constant>V4L2_DEC_CMD_PAUSE_TO_BLACK</constant> is set, then set the
+decoder output to black when paused.
+</entry>
+	  </row>
+	  <row>
+	    <entry><constant>V4L2_DEC_CMD_RESUME</constant></entry>
+	    <entry>3</entry>
+	    <entry>Resume decoding after a PAUSE command. When the
+decoder has not been started yet, the driver will return an &EPERM;.
+When the decoder is already running, this command does nothing. No
+flags are defined for this command.</entry>
+	  </row>
+	</tbody>
+      </tgroup>
+    </table>
+
+  </refsect1>
+
+  <refsect1>
+    &return-value;
+
+    <variablelist>
+      <varlistentry>
+	<term><errorcode>EINVAL</errorcode></term>
+	<listitem>
+	  <para>The <structfield>cmd</structfield> field is invalid.</para>
+	</listitem>
+      </varlistentry>
+      <varlistentry>
+	<term><errorcode>EPERM</errorcode></term>
+	<listitem>
+	  <para>The application sent a PAUSE or RESUME command when
+the decoder was not running.</para>
+	</listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+</refentry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml
index af7f3f2..f431b3b 100644
--- a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml
@@ -74,15 +74,16 @@ only used by the STOP command and contains one bit: If the
 encoding will continue until the end of the current <wordasword>Group
 Of Pictures</wordasword>, otherwise it will stop immediately.</para>
 
-    <para>A <function>read</function>() call sends a START command to
-the encoder if it has not been started yet. After a STOP command,
+    <para>A <function>read</function>() or &VIDIOC-STREAMON; call sends an implicit
+START command to the encoder if it has not been started yet. After a STOP command,
 <function>read</function>() calls will read the remaining data
 buffered by the driver. When the buffer is empty,
 <function>read</function>() will return zero and the next
 <function>read</function>() call will restart the encoder.</para>
 
-    <para>A <function>close</function>() call sends an immediate STOP
-to the encoder, and all buffered data is discarded.</para>
+    <para>A <function>close</function>() or &VIDIOC-STREAMOFF; call of a streaming
+file descriptor sends an implicit immediate STOP to the encoder, and all buffered
+data is discarded.</para>
 
     <para>These ioctls are optional, not all drivers may support
 them. They were introduced in Linux 2.6.21.</para>
-- 
1.7.7.3

[RFCv2 PATCH 03/12] ivtv: implement new decoder command ioctls.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 drivers/media/video/ivtv/ivtv-driver.c  |    2 +-
 drivers/media/video/ivtv/ivtv-fileops.c |    2 +-
 drivers/media/video/ivtv/ivtv-ioctl.c   |  106 +++++++++++++++++++-----------
 drivers/media/video/ivtv/ivtv-streams.c |    4 +-
 4 files changed, 71 insertions(+), 43 deletions(-)

diff --git a/drivers/media/video/ivtv/ivtv-driver.c b/drivers/media/video/ivtv/ivtv-driver.c
index 41108a9..7ee7594 100644
--- a/drivers/media/video/ivtv/ivtv-driver.c
+++ b/drivers/media/video/ivtv/ivtv-driver.c
@@ -1378,7 +1378,7 @@ static void ivtv_remove(struct pci_dev *pdev)
 			else
 				type = IVTV_DEC_STREAM_TYPE_MPG;
 			ivtv_stop_v4l2_decode_stream(&itv->streams[type],
-				VIDEO_CMD_STOP_TO_BLACK | VIDEO_CMD_STOP_IMMEDIATELY, 0);
+				V4L2_DEC_CMD_STOP_TO_BLACK | V4L2_DEC_CMD_STOP_IMMEDIATELY, 0);
 		}
 		ivtv_halt_firmware(itv);
 	}
diff --git a/drivers/media/video/ivtv/ivtv-fileops.c b/drivers/media/video/ivtv/ivtv-fileops.c
index 38f0522..66228ee 100644
--- a/drivers/media/video/ivtv/ivtv-fileops.c
+++ b/drivers/media/video/ivtv/ivtv-fileops.c
@@ -899,7 +899,7 @@ int ivtv_v4l2_close(struct file *filp)
 	} else if (s->type >= IVTV_DEC_STREAM_TYPE_MPG) {
 		struct ivtv_stream *s_vout = &itv->streams[IVTV_DEC_STREAM_TYPE_VOUT];
 
-		ivtv_stop_decoding(id, VIDEO_CMD_STOP_TO_BLACK | VIDEO_CMD_STOP_IMMEDIATELY, 0);
+		ivtv_stop_decoding(id, V4L2_DEC_CMD_STOP_TO_BLACK | V4L2_DEC_CMD_STOP_IMMEDIATELY, 0);
 
 		/* If all output streams are closed, and if the user doesn't have
 		   IVTV_DEC_STREAM_TYPE_VOUT open, then disable CC on TV-out. */
diff --git a/drivers/media/video/ivtv/ivtv-ioctl.c b/drivers/media/video/ivtv/ivtv-ioctl.c
index ecafa69..c84e325 100644
--- a/drivers/media/video/ivtv/ivtv-ioctl.c
+++ b/drivers/media/video/ivtv/ivtv-ioctl.c
@@ -244,34 +244,40 @@ static int ivtv_validate_speed(int cur_speed, int new_speed)
 }
 
 static int ivtv_video_command(struct ivtv *itv, struct ivtv_open_id *id,
-		struct video_command *vc, int try)
+		struct v4l2_decoder_cmd *dc, int try)
 {
 	struct ivtv_stream *s = &itv->streams[IVTV_DEC_STREAM_TYPE_MPG];
 
 	if (!(itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT))
 		return -EINVAL;
 
-	switch (vc->cmd) {
-	case VIDEO_CMD_PLAY: {
-		vc->flags = 0;
-		vc->play.speed = ivtv_validate_speed(itv->speed, vc->play.speed);
-		if (vc->play.speed < 0)
-			vc->play.format = VIDEO_PLAY_FMT_GOP;
+	switch (dc->cmd) {
+	case V4L2_DEC_CMD_START: {
+		dc->flags &= V4L2_DEC_CMD_START_MUTE_AUDIO;
+		dc->start.speed = ivtv_validate_speed(itv->speed, dc->start.speed);
+		if (dc->start.speed < 0)
+			dc->start.format = V4L2_DEC_START_FMT_GOP;
+		else
+			dc->start.format = V4L2_DEC_START_FMT_NONE;
+		if (dc->start.speed != 500 && dc->start.speed != 1500)
+			dc->flags = dc->start.speed == 1000 ? 0 :
+					V4L2_DEC_CMD_START_MUTE_AUDIO;
 		if (try) break;
 
+		itv->speed_mute_audio = dc->flags & V4L2_DEC_CMD_START_MUTE_AUDIO;
 		if (ivtv_set_output_mode(itv, OUT_MPG) != OUT_MPG)
 			return -EBUSY;
 		if (test_and_clear_bit(IVTV_F_I_DEC_PAUSED, &itv->i_flags)) {
 			/* forces ivtv_set_speed to be called */
 			itv->speed = 0;
 		}
-		return ivtv_start_decoding(id, vc->play.speed);
+		return ivtv_start_decoding(id, dc->start.speed);
 	}
 
-	case VIDEO_CMD_STOP:
-		vc->flags &= VIDEO_CMD_STOP_IMMEDIATELY|VIDEO_CMD_STOP_TO_BLACK;
-		if (vc->flags & VIDEO_CMD_STOP_IMMEDIATELY)
-			vc->stop.pts = 0;
+	case V4L2_DEC_CMD_STOP:
+		dc->flags &= V4L2_DEC_CMD_STOP_IMMEDIATELY | V4L2_DEC_CMD_STOP_TO_BLACK;
+		if (dc->flags & V4L2_DEC_CMD_STOP_IMMEDIATELY)
+			dc->stop.pts = 0;
 		if (try) break;
 		if (atomic_read(&itv->decoding) == 0)
 			return 0;
@@ -279,22 +285,22 @@ static int ivtv_video_command(struct ivtv *itv, struct ivtv_open_id *id,
 			return -EBUSY;
 
 		itv->output_mode = OUT_NONE;
-		return ivtv_stop_v4l2_decode_stream(s, vc->flags, vc->stop.pts);
+		return ivtv_stop_v4l2_decode_stream(s, dc->flags, dc->stop.pts);
 
-	case VIDEO_CMD_FREEZE:
-		vc->flags &= VIDEO_CMD_FREEZE_TO_BLACK;
+	case V4L2_DEC_CMD_PAUSE:
+		dc->flags &= V4L2_DEC_CMD_PAUSE_TO_BLACK;
 		if (try) break;
 		if (itv->output_mode != OUT_MPG)
 			return -EBUSY;
 		if (atomic_read(&itv->decoding) > 0) {
 			ivtv_vapi(itv, CX2341X_DEC_PAUSE_PLAYBACK, 1,
-				(vc->flags & VIDEO_CMD_FREEZE_TO_BLACK) ? 1 : 0);
+				(dc->flags & V4L2_DEC_CMD_PAUSE_TO_BLACK) ? 1 : 0);
 			set_bit(IVTV_F_I_DEC_PAUSED, &itv->i_flags);
 		}
 		break;
 
-	case VIDEO_CMD_CONTINUE:
-		vc->flags = 0;
+	case V4L2_DEC_CMD_RESUME:
+		dc->flags = 0;
 		if (try) break;
 		if (itv->output_mode != OUT_MPG)
 			return -EBUSY;
@@ -1568,6 +1574,24 @@ static int ivtv_log_status(struct file *file, void *fh)
 	return 0;
 }
 
+static int ivtv_decoder_cmd(struct file *file, void *fh, struct v4l2_decoder_cmd *dec)
+{
+	struct ivtv_open_id *id = fh2id(file->private_data);
+	struct ivtv *itv = id->itv;
+
+	IVTV_DEBUG_IOCTL("VIDIOC_DECODER_CMD %d\n", dec->cmd);
+	return ivtv_video_command(itv, id, dec, false);
+}
+
+static int ivtv_try_decoder_cmd(struct file *file, void *fh, struct v4l2_decoder_cmd *dec)
+{
+	struct ivtv_open_id *id = fh2id(file->private_data);
+	struct ivtv *itv = id->itv;
+
+	IVTV_DEBUG_IOCTL("VIDIOC_TRY_DECODER_CMD %d\n", dec->cmd);
+	return ivtv_video_command(itv, id, dec, true);
+}
+
 static int ivtv_decoder_ioctls(struct file *filp, unsigned int cmd, void *arg)
 {
 	struct ivtv_open_id *id = fh2id(filp->private_data);
@@ -1662,52 +1686,54 @@ static int ivtv_decoder_ioctls(struct file *filp, unsigned int cmd, void *arg)
 	}
 
 	case VIDEO_PLAY: {
-		struct video_command vc;
+		struct v4l2_decoder_cmd dc;
 
 		IVTV_DEBUG_IOCTL("VIDEO_PLAY\n");
-		memset(&vc, 0, sizeof(vc));
-		vc.cmd = VIDEO_CMD_PLAY;
-		return ivtv_video_command(itv, id, &vc, 0);
+		memset(&dc, 0, sizeof(dc));
+		dc.cmd = V4L2_DEC_CMD_START;
+		return ivtv_video_command(itv, id, &dc, 0);
 	}
 
 	case VIDEO_STOP: {
-		struct video_command vc;
+		struct v4l2_decoder_cmd dc;
 
 		IVTV_DEBUG_IOCTL("VIDEO_STOP\n");
-		memset(&vc, 0, sizeof(vc));
-		vc.cmd = VIDEO_CMD_STOP;
-		vc.flags = VIDEO_CMD_STOP_TO_BLACK | VIDEO_CMD_STOP_IMMEDIATELY;
-		return ivtv_video_command(itv, id, &vc, 0);
+		memset(&dc, 0, sizeof(dc));
+		dc.cmd = V4L2_DEC_CMD_STOP;
+		dc.flags = V4L2_DEC_CMD_STOP_TO_BLACK | V4L2_DEC_CMD_STOP_IMMEDIATELY;
+		return ivtv_video_command(itv, id, &dc, 0);
 	}
 
 	case VIDEO_FREEZE: {
-		struct video_command vc;
+		struct v4l2_decoder_cmd dc;
 
 		IVTV_DEBUG_IOCTL("VIDEO_FREEZE\n");
-		memset(&vc, 0, sizeof(vc));
-		vc.cmd = VIDEO_CMD_FREEZE;
-		return ivtv_video_command(itv, id, &vc, 0);
+		memset(&dc, 0, sizeof(dc));
+		dc.cmd = V4L2_DEC_CMD_PAUSE;
+		return ivtv_video_command(itv, id, &dc, 0);
 	}
 
 	case VIDEO_CONTINUE: {
-		struct video_command vc;
+		struct v4l2_decoder_cmd dc;
 
 		IVTV_DEBUG_IOCTL("VIDEO_CONTINUE\n");
-		memset(&vc, 0, sizeof(vc));
-		vc.cmd = VIDEO_CMD_CONTINUE;
-		return ivtv_video_command(itv, id, &vc, 0);
+		memset(&dc, 0, sizeof(dc));
+		dc.cmd = V4L2_DEC_CMD_RESUME;
+		return ivtv_video_command(itv, id, &dc, 0);
 	}
 
 	case VIDEO_COMMAND:
 	case VIDEO_TRY_COMMAND: {
-		struct video_command *vc = arg;
+		/* Note: struct v4l2_decoder_cmd has the same layout as
+		   struct video_command */
+		struct v4l2_decoder_cmd *dc = arg;
 		int try = (cmd == VIDEO_TRY_COMMAND);
 
 		if (try)
-			IVTV_DEBUG_IOCTL("VIDEO_TRY_COMMAND %d\n", vc->cmd);
+			IVTV_DEBUG_IOCTL("VIDEO_TRY_COMMAND %d\n", dc->cmd);
 		else
-			IVTV_DEBUG_IOCTL("VIDEO_COMMAND %d\n", vc->cmd);
-		return ivtv_video_command(itv, id, vc, try);
+			IVTV_DEBUG_IOCTL("VIDEO_COMMAND %d\n", dc->cmd);
+		return ivtv_video_command(itv, id, dc, try);
 	}
 
 	case VIDEO_GET_EVENT: {
@@ -1901,6 +1927,8 @@ static const struct v4l2_ioctl_ops ivtv_ioctl_ops = {
 	.vidioc_enum_fmt_vid_cap 	    = ivtv_enum_fmt_vid_cap,
 	.vidioc_encoder_cmd  		    = ivtv_encoder_cmd,
 	.vidioc_try_encoder_cmd 	    = ivtv_try_encoder_cmd,
+	.vidioc_decoder_cmd		    = ivtv_decoder_cmd,
+	.vidioc_try_decoder_cmd		    = ivtv_try_decoder_cmd,
 	.vidioc_enum_fmt_vid_out 	    = ivtv_enum_fmt_vid_out,
 	.vidioc_g_fmt_vid_cap 		    = ivtv_g_fmt_vid_cap,
 	.vidioc_g_fmt_vbi_cap		    = ivtv_g_fmt_vbi_cap,
diff --git a/drivers/media/video/ivtv/ivtv-streams.c b/drivers/media/video/ivtv/ivtv-streams.c
index e7794dc..75226b7 100644
--- a/drivers/media/video/ivtv/ivtv-streams.c
+++ b/drivers/media/video/ivtv/ivtv-streams.c
@@ -891,7 +891,7 @@ int ivtv_stop_v4l2_decode_stream(struct ivtv_stream *s, int flags, u64 pts)
 	IVTV_DEBUG_INFO("Stop Decode at %llu, flags: %x\n", (unsigned long long)pts, flags);
 
 	/* Stop Decoder */
-	if (!(flags & VIDEO_CMD_STOP_IMMEDIATELY) || pts) {
+	if (!(flags & V4L2_DEC_CMD_STOP_IMMEDIATELY) || pts) {
 		u32 tmp = 0;
 
 		/* Wait until the decoder is no longer running */
@@ -911,7 +911,7 @@ int ivtv_stop_v4l2_decode_stream(struct ivtv_stream *s, int flags, u64 pts)
 				break;
 		}
 	}
-	ivtv_vapi(itv, CX2341X_DEC_STOP_PLAYBACK, 3, flags & VIDEO_CMD_STOP_TO_BLACK, 0, 0);
+	ivtv_vapi(itv, CX2341X_DEC_STOP_PLAYBACK, 3, flags & V4L2_DEC_CMD_STOP_TO_BLACK, 0, 0);
 
 	/* turn off notification of dual/stereo mode change */
 	ivtv_vapi(itv, CX2341X_DEC_SET_EVENT_NOTIFICATION, 4, 0, 0, IVTV_IRQ_DEC_AUD_MODE_CHG, -1);
-- 
1.7.7.3

[RFCv2 PATCH 04/12] v4l2-ctrls: add new controls for MPEG decoder devices.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

As discussed during the 2011 V4L-DVB workshop we want to create a proper V4L2
decoder API that replaces the DVBv5 API that has been used until now.

This adds the four controls necessary to achieve switch ivtv over to this new API.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 drivers/media/video/v4l2-ctrls.c |   23 +++++++++++++++++++++++
 include/linux/videodev2.h        |   13 +++++++++++++
 2 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 0f415da..7051e27 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -175,6 +175,15 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
 		"16-bit CRC",
 		NULL
 	};
+	static const char * const mpeg_audio_dec_playback[] = {
+		"Auto",
+		"Stereo",
+		"Left",
+		"Right",
+		"Mono",
+		"Swapped Stereo",
+		NULL
+	};
 	static const char * const mpeg_video_encoding[] = {
 		"MPEG-1",
 		"MPEG-2",
@@ -374,6 +383,9 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
 		return mpeg_audio_emphasis;
 	case V4L2_CID_MPEG_AUDIO_CRC:
 		return mpeg_audio_crc;
+	case V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK:
+	case V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK:
+		return mpeg_audio_dec_playback;
 	case V4L2_CID_MPEG_VIDEO_ENCODING:
 		return mpeg_video_encoding;
 	case V4L2_CID_MPEG_VIDEO_ASPECT:
@@ -479,6 +491,7 @@ const char *v4l2_ctrl_get_name(u32 id)
 	case V4L2_CID_MPEG_STREAM_PES_ID_AUDIO: return "Stream PES Audio ID";
 	case V4L2_CID_MPEG_STREAM_PES_ID_VIDEO: return "Stream PES Video ID";
 	case V4L2_CID_MPEG_STREAM_VBI_FMT:	return "Stream VBI Format";
+	case V4L2_CID_MPEG_STREAM_DEC_PTS:	return "Decoder PTS";
 	case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ: return "Audio Sampling Frequency";
 	case V4L2_CID_MPEG_AUDIO_ENCODING:	return "Audio Encoding";
 	case V4L2_CID_MPEG_AUDIO_L1_BITRATE:	return "Audio Layer I Bitrate";
@@ -491,6 +504,8 @@ const char *v4l2_ctrl_get_name(u32 id)
 	case V4L2_CID_MPEG_AUDIO_MUTE:		return "Audio Mute";
 	case V4L2_CID_MPEG_AUDIO_AAC_BITRATE:	return "Audio AAC Bitrate";
 	case V4L2_CID_MPEG_AUDIO_AC3_BITRATE:	return "Audio AC-3 Bitrate";
+	case V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK:	return "Audio Playback";
+	case V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK: return "Audio Multilingual Playback";
 	case V4L2_CID_MPEG_VIDEO_ENCODING:	return "Video Encoding";
 	case V4L2_CID_MPEG_VIDEO_ASPECT:	return "Video Aspect";
 	case V4L2_CID_MPEG_VIDEO_B_FRAMES:	return "Video B Frames";
@@ -545,6 +560,7 @@ const char *v4l2_ctrl_get_name(u32 id)
 	case V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MAX_MB:		return "The Number of MB in a Slice";
 	case V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE:		return "The Slice Partitioning Method";
 	case V4L2_CID_MPEG_VIDEO_VBV_SIZE:			return "VBV Buffer Size";
+	case V4L2_CID_MPEG_VIDEO_DEC_FRAME:			return "Decoder Frame Count";
 
 	/* CAMERA controls */
 	/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -673,6 +689,8 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
 	case V4L2_CID_MPEG_AUDIO_MODE_EXTENSION:
 	case V4L2_CID_MPEG_AUDIO_EMPHASIS:
 	case V4L2_CID_MPEG_AUDIO_CRC:
+	case V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK:
+	case V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK:
 	case V4L2_CID_MPEG_VIDEO_ENCODING:
 	case V4L2_CID_MPEG_VIDEO_ASPECT:
 	case V4L2_CID_MPEG_VIDEO_BITRATE_MODE:
@@ -723,6 +741,11 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
 		*type = V4L2_CTRL_TYPE_INTEGER;
 		*flags |= V4L2_CTRL_FLAG_READ_ONLY;
 		break;
+	case V4L2_CID_MPEG_VIDEO_DEC_FRAME:
+	case V4L2_CID_MPEG_STREAM_DEC_PTS:
+		*type = V4L2_CTRL_TYPE_INTEGER64;
+		*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_VOLATILE;
+		break;
 	default:
 		*type = V4L2_CTRL_TYPE_INTEGER;
 		break;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 406f7f7..99f9d5f 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1234,6 +1234,7 @@ enum v4l2_mpeg_stream_vbi_fmt {
 	V4L2_MPEG_STREAM_VBI_FMT_NONE = 0,  /* No VBI in the MPEG stream */
 	V4L2_MPEG_STREAM_VBI_FMT_IVTV = 1,  /* VBI in private packets, IVTV format */
 };
+#define V4L2_CID_MPEG_STREAM_DEC_PTS		(V4L2_CID_MPEG_BASE+8)
 
 /*  MPEG audio controls specific to multiplexed streams  */
 #define V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ 	(V4L2_CID_MPEG_BASE+100)
@@ -1350,6 +1351,16 @@ enum v4l2_mpeg_audio_ac3_bitrate {
 	V4L2_MPEG_AUDIO_AC3_BITRATE_576K = 17,
 	V4L2_MPEG_AUDIO_AC3_BITRATE_640K = 18,
 };
+#define V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK	(V4L2_CID_MPEG_BASE+112)
+enum v4l2_mpeg_audio_dec_playback {
+	V4L2_MPEG_AUDIO_DEC_PLAYBACK_AUTO	    = 0,
+	V4L2_MPEG_AUDIO_DEC_PLAYBACK_STEREO	    = 1,
+	V4L2_MPEG_AUDIO_DEC_PLAYBACK_LEFT	    = 2,
+	V4L2_MPEG_AUDIO_DEC_PLAYBACK_RIGHT	    = 3,
+	V4L2_MPEG_AUDIO_DEC_PLAYBACK_MONO	    = 4,
+	V4L2_MPEG_AUDIO_DEC_PLAYBACK_SWAPPED_STEREO = 5,
+};
+#define V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK (V4L2_CID_MPEG_BASE+113)
 
 /*  MPEG video controls specific to multiplexed streams */
 #define V4L2_CID_MPEG_VIDEO_ENCODING 		(V4L2_CID_MPEG_BASE+200)
@@ -1400,6 +1411,8 @@ enum v4l2_mpeg_video_multi_slice_mode {
 	V4L2_MPEG_VIDEO_MULTI_SICE_MODE_MAX_BYTES	= 2,
 };
 #define V4L2_CID_MPEG_VIDEO_VBV_SIZE			(V4L2_CID_MPEG_BASE+222)
+#define V4L2_CID_MPEG_VIDEO_DEC_FRAME			(V4L2_CID_MPEG_BASE+223)
+
 #define V4L2_CID_MPEG_VIDEO_H263_I_FRAME_QP		(V4L2_CID_MPEG_BASE+300)
 #define V4L2_CID_MPEG_VIDEO_H263_P_FRAME_QP		(V4L2_CID_MPEG_BASE+301)
 #define V4L2_CID_MPEG_VIDEO_H263_B_FRAME_QP		(V4L2_CID_MPEG_BASE+302)
-- 
1.7.7.3

[RFCv2 PATCH 05/12] Document decoder controls.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 Documentation/DocBook/media/v4l/controls.xml |   58 ++++++++++++++++++++++++++
 1 files changed, 58 insertions(+), 0 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml
index 3bc5ee8..411fba2 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -797,6 +797,13 @@ in the kernel sources in the file <filename>Documentation/video4linux/cx2341x/RE
 		</entrytbl>
 	      </row>
 	      <row><entry></entry></row>
+	      <row id="v4l2-mpeg-stream-dec-pts">
+		<entry spanname="id"><constant>V4L2_CID_MPEG_STREAM_DEC_PTS</constant>&nbsp;</entry>
+		<entry>integer64</entry>
+	      </row><row><entry spanname="descr">This read-only control returns the
+Program Time Stamp of the frame that is currently displayed (decoded).</entry>
+	      </row>
+	      <row><entry></entry></row>
 	      <row id="v4l2-mpeg-audio-sampling-freq">
 		<entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ</constant>&nbsp;</entry>
 		<entry>enum&nbsp;v4l2_mpeg_audio_sampling_freq</entry>
@@ -1273,6 +1280,49 @@ produce a slight hiss, but in the encoder itself, guaranteeing a fixed
 and reproducible audio bitstream. 0 = unmuted, 1 = muted.</entry>
 	      </row>
 	      <row><entry></entry></row>
+	      <row id="v4l2-mpeg-audio-dec-playback">
+		<entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK</constant>&nbsp;</entry>
+		<entry>enum&nbsp;v4l2_mpeg_audio_dec_playback</entry>
+	      </row><row><entry spanname="descr">Determines how monolingual audio should be played back.
+Possible values are:</entry>
+	      </row>
+	      <row>
+		<entrytbl spanname="descr" cols="2">
+		  <tbody valign="top">
+		    <row>
+		      <entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_AUTO</constant>&nbsp;</entry>
+		      <entry>Automatically determines the best playback mode.</entry>
+		    </row>
+		    <row>
+		      <entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_STEREO</constant>&nbsp;</entry>
+		      <entry>Stereo playback.</entry>
+		    </row>
+		    <row>
+		      <entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_LEFT</constant>&nbsp;</entry>
+		      <entry>Left channel playback.</entry>
+		    </row>
+		    <row>
+		      <entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_RIGHT</constant>&nbsp;</entry>
+		      <entry>Right channel playback.</entry>
+		    </row>
+		    <row>
+		      <entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_MONO</constant>&nbsp;</entry>
+		      <entry>Mono playback.</entry>
+		    </row>
+		    <row>
+		      <entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_SWAPPED_STEREO</constant>&nbsp;</entry>
+		      <entry>Stereo playback with swapped left and right channels.</entry>
+		    </row>
+		  </tbody>
+		</entrytbl>
+	      </row>
+	      <row><entry></entry></row>
+	      <row id="v4l2-mpeg-audio-dec-multilingual-playback">
+		<entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK</constant>&nbsp;</entry>
+		<entry>enum&nbsp;v4l2_mpeg_audio_dec_playback</entry>
+	      </row><row><entry spanname="descr">Determines how multilingual audio should be played back.</entry>
+	      </row>
+	      <row><entry></entry></row>
 	      <row id="v4l2-mpeg-video-encoding">
 		<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_ENCODING</constant>&nbsp;</entry>
 		<entry>enum&nbsp;v4l2_mpeg_video_encoding</entry>
@@ -1434,6 +1484,14 @@ of the video. The supplied 32-bit integer is interpreted as follows (bit
 		  </tbody>
 		</entrytbl>
 	      </row>
+	      <row><entry></entry></row>
+	      <row id="v4l2-mpeg-video-dec-frame">
+		<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_DEC_FRAME</constant>&nbsp;</entry>
+		<entry>integer64</entry>
+	      </row><row><entry spanname="descr">This read-only control returns the
+frame counter of the frame that is currently displayed (decoded). This value is reset to 0 whenever
+the decoder is started.</entry>
+	      </row>
 
 
 	      <row><entry></entry></row>
-- 
1.7.7.3

[RFCv2 PATCH 06/12] ivtv: implement new decoder controls.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 drivers/media/video/ivtv/ivtv-controls.c |   62 +++++++++++++++++++++++++++
 drivers/media/video/ivtv/ivtv-controls.h |    2 +
 drivers/media/video/ivtv/ivtv-driver.c   |   35 +++++++++++++++-
 drivers/media/video/ivtv/ivtv-driver.h   |   12 +++++-
 drivers/media/video/ivtv/ivtv-ioctl.c    |   67 +++++------------------------
 drivers/media/video/ivtv/ivtv-streams.c  |    5 ++-
 6 files changed, 124 insertions(+), 59 deletions(-)

diff --git a/drivers/media/video/ivtv/ivtv-controls.c b/drivers/media/video/ivtv/ivtv-controls.c
index b31ee1b..5fb91b9 100644
--- a/drivers/media/video/ivtv/ivtv-controls.c
+++ b/drivers/media/video/ivtv/ivtv-controls.c
@@ -21,6 +21,7 @@
 #include "ivtv-driver.h"
 #include "ivtv-ioctl.h"
 #include "ivtv-controls.h"
+#include "ivtv-mailbox.h"
 
 static int ivtv_s_stream_vbi_fmt(struct cx2341x_handler *cxhdl, u32 fmt)
 {
@@ -99,3 +100,64 @@ struct cx2341x_handler_ops ivtv_cxhdl_ops = {
 	.s_video_encoding = ivtv_s_video_encoding,
 	.s_stream_vbi_fmt = ivtv_s_stream_vbi_fmt,
 };
+
+int ivtv_g_pts_frame(struct ivtv *itv, s64 *pts, s64 *frame)
+{
+	u32 data[CX2341X_MBOX_MAX_DATA];
+
+	if (test_bit(IVTV_F_I_VALID_DEC_TIMINGS, &itv->i_flags)) {
+		*pts = (s64)((u64)itv->last_dec_timing[2] << 32) |
+			(u64)itv->last_dec_timing[1];
+		*frame = itv->last_dec_timing[0];
+		return 0;
+	}
+	*pts = 0;
+	*frame = 0;
+	if (atomic_read(&itv->decoding)) {
+		if (ivtv_api(itv, CX2341X_DEC_GET_TIMING_INFO, 5, data)) {
+			IVTV_DEBUG_WARN("GET_TIMING: couldn't read clock\n");
+			return -EIO;
+		}
+		memcpy(itv->last_dec_timing, data, sizeof(itv->last_dec_timing));
+		set_bit(IVTV_F_I_VALID_DEC_TIMINGS, &itv->i_flags);
+		*pts = (s64)((u64) data[2] << 32) | (u64) data[1];
+		*frame = data[0];
+		/*timing->scr = (u64) (((u64) data[4] << 32) | (u64) (data[3]));*/
+	}
+	return 0;
+}
+
+static int ivtv_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
+{
+	struct ivtv *itv = container_of(ctrl->handler, struct ivtv, hdl_out);
+
+	switch (ctrl->id) {
+	/* V4L2_CID_MPEG_STREAM_DEC_PTS and V4L2_CID_MPEG_VIDEO_DEC_FRAME
+	   control cluster */
+	case V4L2_CID_MPEG_STREAM_DEC_PTS:
+		return ivtv_g_pts_frame(itv, &itv->ctrl_pts->val64,
+					     &itv->ctrl_frame->val64);
+	}
+	return 0;
+}
+
+static int ivtv_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+	struct ivtv *itv = container_of(ctrl->handler, struct ivtv, hdl_out);
+
+	switch (ctrl->id) {
+	/* V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK and MULTILINGUAL_PLAYBACK
+	   control cluster */
+	case V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK:
+		itv->audio_stereo_mode = itv->ctrl_audio_playback->val - 1;
+		itv->audio_bilingual_mode = itv->ctrl_audio_multilingual_playback->val - 1;
+		ivtv_vapi(itv, CX2341X_DEC_SET_AUDIO_MODE, 2, itv->audio_bilingual_mode, itv->audio_stereo_mode);
+		break;
+	}
+	return 0;
+}
+
+const struct v4l2_ctrl_ops ivtv_hdl_out_ops = {
+	.s_ctrl = ivtv_s_ctrl,
+	.g_volatile_ctrl = ivtv_g_volatile_ctrl,
+};
diff --git a/drivers/media/video/ivtv/ivtv-controls.h b/drivers/media/video/ivtv/ivtv-controls.h
index d12893d..3999e63 100644
--- a/drivers/media/video/ivtv/ivtv-controls.h
+++ b/drivers/media/video/ivtv/ivtv-controls.h
@@ -22,5 +22,7 @@
 #define IVTV_CONTROLS_H
 
 extern struct cx2341x_handler_ops ivtv_cxhdl_ops;
+extern const struct v4l2_ctrl_ops ivtv_hdl_out_ops;
+int ivtv_g_pts_frame(struct ivtv *itv, s64 *pts, s64 *frame);
 
 #endif
diff --git a/drivers/media/video/ivtv/ivtv-driver.c b/drivers/media/video/ivtv/ivtv-driver.c
index 7ee7594..1464a9c 100644
--- a/drivers/media/video/ivtv/ivtv-driver.c
+++ b/drivers/media/video/ivtv/ivtv-driver.c
@@ -747,8 +747,6 @@ static int __devinit ivtv_init_struct1(struct ivtv *itv)
 
 	itv->cur_dma_stream = -1;
 	itv->cur_pio_stream = -1;
-	itv->audio_stereo_mode = AUDIO_STEREO;
-	itv->audio_bilingual_mode = AUDIO_MONO_LEFT;
 
 	/* Ctrls */
 	itv->speed = 1000;
@@ -1203,6 +1201,32 @@ static int __devinit ivtv_probe(struct pci_dev *pdev,
 	itv->tuner_std = itv->std;
 
 	if (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT) {
+		v4l2_ctrl_handler_init(&itv->hdl_out, 50);
+		itv->ctrl_pts = v4l2_ctrl_new_std(&itv->hdl_out, &ivtv_hdl_out_ops,
+				V4L2_CID_MPEG_STREAM_DEC_PTS, 0, 0, 1, 0);
+		itv->ctrl_frame = v4l2_ctrl_new_std(&itv->hdl_out, &ivtv_hdl_out_ops,
+				V4L2_CID_MPEG_VIDEO_DEC_FRAME, 0, 0x7fffffff, 1, 0);
+		/* Note: V4L2_MPEG_AUDIO_DEC_PLAYBACK_AUTO is not supported,
+		   mask that menu item. */
+		itv->ctrl_audio_playback =
+			v4l2_ctrl_new_std_menu(&itv->hdl_out, &ivtv_hdl_out_ops,
+				V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK,
+				V4L2_MPEG_AUDIO_DEC_PLAYBACK_SWAPPED_STEREO,
+				1 << V4L2_MPEG_AUDIO_DEC_PLAYBACK_AUTO,
+				V4L2_MPEG_AUDIO_DEC_PLAYBACK_STEREO);
+		itv->ctrl_audio_multilingual_playback =
+			v4l2_ctrl_new_std_menu(&itv->hdl_out, &ivtv_hdl_out_ops,
+				V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK,
+				V4L2_MPEG_AUDIO_DEC_PLAYBACK_SWAPPED_STEREO,
+				1 << V4L2_MPEG_AUDIO_DEC_PLAYBACK_AUTO,
+				V4L2_MPEG_AUDIO_DEC_PLAYBACK_LEFT);
+		v4l2_ctrl_add_handler(&itv->hdl_out, &itv->cxhdl.hdl);
+		if (itv->hdl_out.error) {
+			retval = itv->hdl_out.error;
+			goto free_i2c;
+		}
+		v4l2_ctrl_cluster(2, &itv->ctrl_pts);
+		v4l2_ctrl_cluster(2, &itv->ctrl_audio_playback);
 		ivtv_call_all(itv, video, s_std_output, itv->std);
 		/* Turn off the output signal. The mpeg decoder is not yet
 		   active so without this you would get a green image until the
@@ -1239,6 +1263,9 @@ free_streams:
 free_irq:
 	free_irq(itv->pdev->irq, (void *)itv);
 free_i2c:
+	if (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT)
+		v4l2_ctrl_handler_free(&itv->hdl_out);
+	v4l2_ctrl_handler_free(&itv->cxhdl.hdl);
 	exit_ivtv_i2c(itv);
 free_io:
 	ivtv_iounmap(itv);
@@ -1394,6 +1421,10 @@ static void ivtv_remove(struct pci_dev *pdev)
 	ivtv_streams_cleanup(itv, 1);
 	ivtv_udma_free(itv);
 
+	if (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT)
+		v4l2_ctrl_handler_free(&itv->hdl_out);
+	v4l2_ctrl_handler_free(&itv->cxhdl.hdl);
+
 	exit_ivtv_i2c(itv);
 
 	free_irq(itv->pdev->irq, (void *)itv);
diff --git a/drivers/media/video/ivtv/ivtv-driver.h b/drivers/media/video/ivtv/ivtv-driver.h
index 8f9cc17..ef5ed32 100644
--- a/drivers/media/video/ivtv/ivtv-driver.h
+++ b/drivers/media/video/ivtv/ivtv-driver.h
@@ -631,6 +631,17 @@ struct ivtv {
 
 	struct v4l2_device v4l2_dev;
 	struct cx2341x_handler cxhdl;
+	struct {
+		/* PTS/Frame count control cluster */
+		struct v4l2_ctrl *ctrl_pts;
+		struct v4l2_ctrl *ctrl_frame;
+	};
+	struct {
+		/* Audio Playback control cluster */
+		struct v4l2_ctrl *ctrl_audio_playback;
+		struct v4l2_ctrl *ctrl_audio_multilingual_playback;
+	};
+	struct v4l2_ctrl_handler hdl_out;
 	struct v4l2_ctrl_handler hdl_gpio;
 	struct v4l2_subdev sd_gpio;	/* GPIO sub-device */
 	u16 instance;
@@ -650,7 +661,6 @@ struct ivtv {
 	u8 audio_stereo_mode;           /* decoder setting how to handle stereo MPEG audio */
 	u8 audio_bilingual_mode;        /* decoder setting how to handle bilingual MPEG audio */
 
-
 	/* Locking */
 	spinlock_t lock;                /* lock access to this struct */
 	struct mutex serialize_lock;    /* mutex used to serialize open/close/start/stop/ioctl operations */
diff --git a/drivers/media/video/ivtv/ivtv-ioctl.c b/drivers/media/video/ivtv/ivtv-ioctl.c
index c84e325..736ba8e 100644
--- a/drivers/media/video/ivtv/ivtv-ioctl.c
+++ b/drivers/media/video/ivtv/ivtv-ioctl.c
@@ -1503,13 +1503,6 @@ static int ivtv_log_status(struct file *file, void *fh)
 			"YUV Frames",
 			"Passthrough",
 		};
-		static const char * const audio_modes[5] = {
-			"Stereo",
-			"Left",
-			"Right",
-			"Mono",
-			"Swapped"
-		};
 		static const char * const alpha_mode[4] = {
 			"None",
 			"Global",
@@ -1538,9 +1531,6 @@ static int ivtv_log_status(struct file *file, void *fh)
 		ivtv_get_output(itv, itv->active_output, &vidout);
 		ivtv_get_audio_output(itv, 0, &audout);
 		IVTV_INFO("Video Output: %s\n", vidout.name);
-		IVTV_INFO("Audio Output: %s (Stereo/Bilingual: %s/%s)\n", audout.name,
-			audio_modes[itv->audio_stereo_mode],
-			audio_modes[itv->audio_bilingual_mode]);
 		if (mode < 0 || mode > OUT_PASSTHROUGH)
 			mode = OUT_NONE;
 		IVTV_INFO("Output Mode:  %s\n", output_modes[mode]);
@@ -1553,7 +1543,10 @@ static int ivtv_log_status(struct file *file, void *fh)
 	}
 	IVTV_INFO("Tuner:  %s\n",
 		test_bit(IVTV_F_I_RADIO_USER, &itv->i_flags) ? "Radio" : "TV");
-	v4l2_ctrl_handler_log_status(&itv->cxhdl.hdl, itv->v4l2_dev.name);
+	if (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT)
+		v4l2_ctrl_handler_log_status(&itv->hdl_out, itv->v4l2_dev.name);
+	else
+		v4l2_ctrl_handler_log_status(&itv->cxhdl.hdl, itv->v4l2_dev.name);
 	IVTV_INFO("Status flags:    0x%08lx\n", itv->i_flags);
 	for (i = 0; i < IVTV_MAX_STREAMS; i++) {
 		struct ivtv_stream *s = &itv->streams[i];
@@ -1626,8 +1619,8 @@ static int ivtv_decoder_ioctls(struct file *filp, unsigned int cmd, void *arg)
 	}
 
 	case VIDEO_GET_PTS: {
-		u32 data[CX2341X_MBOX_MAX_DATA];
-		u64 *pts = arg;
+		s64 *pts = arg;
+		s64 frame;
 
 		IVTV_DEBUG_IOCTL("VIDEO_GET_PTS\n");
 		if (s->type < IVTV_DEC_STREAM_TYPE_MPG) {
@@ -1636,29 +1629,12 @@ static int ivtv_decoder_ioctls(struct file *filp, unsigned int cmd, void *arg)
 		}
 		if (!(itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT))
 			return -EINVAL;
-
-		if (test_bit(IVTV_F_I_VALID_DEC_TIMINGS, &itv->i_flags)) {
-			*pts = (u64) ((u64)itv->last_dec_timing[2] << 32) |
-					(u64)itv->last_dec_timing[1];
-			break;
-		}
-		*pts = 0;
-		if (atomic_read(&itv->decoding)) {
-			if (ivtv_api(itv, CX2341X_DEC_GET_TIMING_INFO, 5, data)) {
-				IVTV_DEBUG_WARN("GET_TIMING: couldn't read clock\n");
-				return -EIO;
-			}
-			memcpy(itv->last_dec_timing, data, sizeof(itv->last_dec_timing));
-			set_bit(IVTV_F_I_VALID_DEC_TIMINGS, &itv->i_flags);
-			*pts = (u64) ((u64) data[2] << 32) | (u64) data[1];
-			/*timing->scr = (u64) (((u64) data[4] << 32) | (u64) (data[3]));*/
-		}
-		break;
+		return ivtv_g_pts_frame(itv, pts, &frame);
 	}
 
 	case VIDEO_GET_FRAME_COUNT: {
-		u32 data[CX2341X_MBOX_MAX_DATA];
-		u64 *frame = arg;
+		s64 *frame = arg;
+		s64 pts;
 
 		IVTV_DEBUG_IOCTL("VIDEO_GET_FRAME_COUNT\n");
 		if (s->type < IVTV_DEC_STREAM_TYPE_MPG) {
@@ -1667,22 +1643,7 @@ static int ivtv_decoder_ioctls(struct file *filp, unsigned int cmd, void *arg)
 		}
 		if (!(itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT))
 			return -EINVAL;
-
-		if (test_bit(IVTV_F_I_VALID_DEC_TIMINGS, &itv->i_flags)) {
-			*frame = itv->last_dec_timing[0];
-			break;
-		}
-		*frame = 0;
-		if (atomic_read(&itv->decoding)) {
-			if (ivtv_api(itv, CX2341X_DEC_GET_TIMING_INFO, 5, data)) {
-				IVTV_DEBUG_WARN("GET_TIMING: couldn't read clock\n");
-				return -EIO;
-			}
-			memcpy(itv->last_dec_timing, data, sizeof(itv->last_dec_timing));
-			set_bit(IVTV_F_I_VALID_DEC_TIMINGS, &itv->i_flags);
-			*frame = data[0];
-		}
-		break;
+		return ivtv_g_pts_frame(itv, &pts, frame);
 	}
 
 	case VIDEO_PLAY: {
@@ -1797,17 +1758,13 @@ static int ivtv_decoder_ioctls(struct file *filp, unsigned int cmd, void *arg)
 		IVTV_DEBUG_IOCTL("AUDIO_CHANNEL_SELECT\n");
 		if (iarg > AUDIO_STEREO_SWAPPED)
 			return -EINVAL;
-		itv->audio_stereo_mode = iarg;
-		ivtv_vapi(itv, CX2341X_DEC_SET_AUDIO_MODE, 2, itv->audio_bilingual_mode, itv->audio_stereo_mode);
-		return 0;
+		return v4l2_ctrl_s_ctrl(itv->ctrl_audio_playback, iarg);
 
 	case AUDIO_BILINGUAL_CHANNEL_SELECT:
 		IVTV_DEBUG_IOCTL("AUDIO_BILINGUAL_CHANNEL_SELECT\n");
 		if (iarg > AUDIO_STEREO_SWAPPED)
 			return -EINVAL;
-		itv->audio_bilingual_mode = iarg;
-		ivtv_vapi(itv, CX2341X_DEC_SET_AUDIO_MODE, 2, itv->audio_bilingual_mode, itv->audio_stereo_mode);
-		return 0;
+		return v4l2_ctrl_s_ctrl(itv->ctrl_audio_multilingual_playback, iarg);
 
 	default:
 		return -EINVAL;
diff --git a/drivers/media/video/ivtv/ivtv-streams.c b/drivers/media/video/ivtv/ivtv-streams.c
index 75226b7..7b9cbb3 100644
--- a/drivers/media/video/ivtv/ivtv-streams.c
+++ b/drivers/media/video/ivtv/ivtv-streams.c
@@ -210,7 +210,10 @@ static int ivtv_prep_dev(struct ivtv *itv, int type)
 
 	s->vdev->num = num;
 	s->vdev->v4l2_dev = &itv->v4l2_dev;
-	s->vdev->ctrl_handler = itv->v4l2_dev.ctrl_handler;
+	if (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT)
+		s->vdev->ctrl_handler = &itv->hdl_out;
+	else
+		s->vdev->ctrl_handler = itv->v4l2_dev.ctrl_handler;
 	s->vdev->fops = ivtv_stream_info[type].fops;
 	s->vdev->release = video_device_release;
 	s->vdev->tvnorms = V4L2_STD_ALL;
-- 
1.7.7.3

[RFCv2 PATCH 07/12] cx18/ddbridge: remove unused headers.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

Work is in progress to deprecate include/linux/dvb/audio.h and video.h.
The cx18 and ddbridge drivers include these headers without using them.

Remove those includes.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 drivers/media/dvb/ddbridge/ddbridge.h  |    2 --
 drivers/media/video/cx18/cx18-driver.h |    2 --
 2 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb/ddbridge/ddbridge.h b/drivers/media/dvb/ddbridge/ddbridge.h
index 6d14893..8b1b41d 100644
--- a/drivers/media/dvb/ddbridge/ddbridge.h
+++ b/drivers/media/dvb/ddbridge/ddbridge.h
@@ -32,8 +32,6 @@
 #include <asm/dma.h>
 #include <linux/dvb/frontend.h>
 #include <linux/dvb/ca.h>
-#include <linux/dvb/video.h>
-#include <linux/dvb/audio.h>
 #include <linux/socket.h>
 
 #include "dmxdev.h"
diff --git a/drivers/media/video/cx18/cx18-driver.h b/drivers/media/video/cx18/cx18-driver.h
index b9a94fc..7a37e0e 100644
--- a/drivers/media/video/cx18/cx18-driver.h
+++ b/drivers/media/video/cx18/cx18-driver.h
@@ -44,8 +44,6 @@
 #include <linux/slab.h>
 #include <asm/byteorder.h>
 
-#include <linux/dvb/video.h>
-#include <linux/dvb/audio.h>
 #include <media/v4l2-common.h>
 #include <media/v4l2-ioctl.h>
 #include <media/v4l2-device.h>
-- 
1.7.7.3

[RFCv2 PATCH 08/12] ivtv: extend ivtv.h with structs and ioctls from dvb/audio.h and video.h.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

This removes the ivtv dependency on those dvb headers.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 include/linux/ivtv.h |   86 +++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 85 insertions(+), 1 deletions(-)

diff --git a/include/linux/ivtv.h b/include/linux/ivtv.h
index 062d20f..dacb712 100644
--- a/include/linux/ivtv.h
+++ b/include/linux/ivtv.h
@@ -58,7 +58,8 @@ struct ivtv_dma_frame {
 	__u32 src_height;
 };
 
-#define IVTV_IOC_DMA_FRAME  _IOW ('V', BASE_VIDIOC_PRIVATE+0, struct ivtv_dma_frame)
+#define IVTV_IOC_DMA_FRAME		_IOW ('V', BASE_VIDIOC_PRIVATE+0, struct ivtv_dma_frame)
+#define IVTV_IOC_PASSTHROUGH_MODE	_IOW ('V', BASE_VIDIOC_PRIVATE+1, int)
 
 /* Deprecated defines: applications should use the defines from videodev2.h */
 #define IVTV_SLICED_TYPE_TELETEXT_B     V4L2_MPEG_VBI_IVTV_TELETEXT_B
@@ -66,4 +67,87 @@ struct ivtv_dma_frame {
 #define IVTV_SLICED_TYPE_WSS_625        V4L2_MPEG_VBI_IVTV_WSS_625
 #define IVTV_SLICED_TYPE_VPS            V4L2_MPEG_VBI_IVTV_VPS
 
+
+/* The code below used to be part of the DVBv5 API as was defined in the
+   linux/dvb/audio.h and video.h headers.
+
+   That API was only used by av7110 and ivtv and the decision was made to
+   deprecate that decoder API and replace it with a proper V4L2 API in the
+   case of ivtv.
+
+   For the time being the part of those headers that ivtv uses is copied in
+   this header and renamed with an IVTV_ prefix. At some point in the future
+   this API will probably be removed.
+
+   The replacement V4L2 API appeared in kernel 3.3. How to convert applications
+   from the old DVBv5 API to the new V4L2 API is described below. */
+
+/* Should the audio be muted when doing playback at non-standard speeds?
+   Replaced by the V4L2_DEC_CMD_START_MUTE_AUDIO flag. */
+#define IVTV_AUDIO_SET_MUTE             _IO('o', 6)
+
+/* Channel selection during playback.
+   Replaced by the V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK and
+   V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK controls. */
+#define IVTV_AUDIO_STEREO		(0)
+#define IVTV_AUDIO_MONO_LEFT		(1)
+#define IVTV_AUDIO_MONO_RIGHT		(2)
+#define IVTV_AUDIO_MONO			(3)
+#define IVTV_AUDIO_STEREO_SWAPPED	(4)
+
+#define IVTV_AUDIO_CHANNEL_SELECT       _IO('o', 9)
+#define IVTV_AUDIO_BILINGUAL_CHANNEL_SELECT _IO('o', 20)
+
+/* Video playback. Replaced by the VIDIOC_(TRY_)DECODER_CMD ioctls. */
+#define IVTV_VIDEO_STOP                 _IO('o', 21)
+#define IVTV_VIDEO_PLAY                 _IO('o', 22)
+#define IVTV_VIDEO_FREEZE               _IO('o', 23)
+#define IVTV_VIDEO_CONTINUE             _IO('o', 24)
+#define IVTV_VIDEO_COMMAND		_IOWR('o', 59, struct v4l2_decoder_cmd)
+#define IVTV_VIDEO_TRY_COMMAND		_IOWR('o', 60, struct v4l2_decoder_cmd)
+
+/* Select passthrough mode. Replaced by the ivtv-private
+   IVTV_IOC_PASSTHROUGH_MODE ioctl. */
+#define IVTV_VIDEO_SOURCE_DEMUX		(0)
+#define IVTV_VIDEO_SOURCE_MEMORY	(1)
+#define IVTV_VIDEO_SELECT_SOURCE        _IO('o', 25)
+
+/* Event handling. Replaced by the V4L2 event API (VIDIOC_DQEVENT et al.)
+ *
+ * This ioctl call returns an event of type video_event if available. If an
+ * event is not available, the behavior depends on whether the device is in
+ * blocking or non-blocking mode. In the latter case, the call fails immediately
+ * with errno set to EWOULDBLOCK. In the former case, the call blocks until an
+ * event becomes available. The standard Linux poll() and/or select() system
+ * calls can be used with the device file descriptor to watch for new events.
+ * For select(), the file descriptor should be included in the exceptfds
+ * argument, and for poll(), POLLPRI should be specified as the wake-up
+ * condition. Read-only permissions are sufficient for this ioctl call.
+ */
+
+/* FIELD_UNKNOWN can be used if the hardware does not know whether
+   the Vsync is for an odd, even or progressive (i.e. non-interlaced)
+   field. */
+#define IVTV_VIDEO_VSYNC_FIELD_UNKNOWN		(0)
+#define IVTV_VIDEO_VSYNC_FIELD_ODD		(1)
+#define IVTV_VIDEO_VSYNC_FIELD_EVEN		(2)
+#define IVTV_VIDEO_VSYNC_FIELD_PROGRESSIVE	(3)
+
+struct ivtv_video_event {
+	__s32 type;
+#define IVTV_VIDEO_EVENT_DECODER_STOPPED	(3)
+#define IVTV_VIDEO_EVENT_VSYNC			(4)
+	__kernel_time_t timestamp;
+	union {
+		unsigned char vsync_field;	/* unknown/odd/even/progressive */
+	} u;
+};
+#define IVTV_VIDEO_GET_EVENT		_IOR('o', 28, struct ivtv_video_event)
+
+/* Returns the PTS and frame count of the frame that's being decoded or
+   displayed. Replaced by the V4L2_CID_MPEG_STREAM_DEC_PTS and
+   V4L2_CID_MPEG_VIDEO_DEC_FRAME read-only controls. */
+#define IVTV_VIDEO_GET_PTS		_IOR('o', 57, __u64)
+#define IVTV_VIDEO_GET_FRAME_COUNT	_IOR('o', 58, __u64)
+
 #endif /* _LINUX_IVTV_H */
-- 
1.7.7.3

[RFCv2 PATCH 09/12] ivtv: use the new ivtv-specific ioctls from ivtv.h.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

The ivtv driver now no longer uses dvb/audio.h and dvb/video.h.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 drivers/media/video/ivtv/ivtv-driver.h |    2 -
 drivers/media/video/ivtv/ivtv-ioctl.c  |  127 +++++++++++++++++---------------
 2 files changed, 67 insertions(+), 62 deletions(-)

diff --git a/drivers/media/video/ivtv/ivtv-driver.h b/drivers/media/video/ivtv/ivtv-driver.h
index ef5ed32..0d2f31c 100644
--- a/drivers/media/video/ivtv/ivtv-driver.h
+++ b/drivers/media/video/ivtv/ivtv-driver.h
@@ -57,8 +57,6 @@
 #include <asm/system.h>
 #include <asm/byteorder.h>
 
-#include <linux/dvb/video.h>
-#include <linux/dvb/audio.h>
 #include <media/v4l2-common.h>
 #include <media/v4l2-ioctl.h>
 #include <media/v4l2-ctrls.h>
diff --git a/drivers/media/video/ivtv/ivtv-ioctl.c b/drivers/media/video/ivtv/ivtv-ioctl.c
index 736ba8e..fb66173 100644
--- a/drivers/media/video/ivtv/ivtv-ioctl.c
+++ b/drivers/media/video/ivtv/ivtv-ioctl.c
@@ -36,7 +36,6 @@
 #include <media/tveeprom.h>
 #include <media/v4l2-chip-ident.h>
 #include <media/v4l2-event.h>
-#include <linux/dvb/audio.h>
 
 u16 ivtv_service2vbi(int type)
 {
@@ -1618,11 +1617,17 @@ static int ivtv_decoder_ioctls(struct file *filp, unsigned int cmd, void *arg)
 		return ivtv_yuv_prep_frame(itv, args);
 	}
 
-	case VIDEO_GET_PTS: {
+	case IVTV_IOC_PASSTHROUGH_MODE:
+		IVTV_DEBUG_IOCTL("IVTV_IOC_PASSTHROUGH_MODE\n");
+		if (!(itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT))
+			return -EINVAL;
+		return ivtv_passthrough_mode(itv, *(int *)arg != 0);
+
+	case IVTV_VIDEO_GET_PTS: {
 		s64 *pts = arg;
 		s64 frame;
 
-		IVTV_DEBUG_IOCTL("VIDEO_GET_PTS\n");
+		IVTV_DEBUG_IOCTL("IVTV_VIDEO_GET_PTS\n");
 		if (s->type < IVTV_DEC_STREAM_TYPE_MPG) {
 			*pts = s->dma_pts;
 			break;
@@ -1632,11 +1637,11 @@ static int ivtv_decoder_ioctls(struct file *filp, unsigned int cmd, void *arg)
 		return ivtv_g_pts_frame(itv, pts, &frame);
 	}
 
-	case VIDEO_GET_FRAME_COUNT: {
+	case IVTV_VIDEO_GET_FRAME_COUNT: {
 		s64 *frame = arg;
 		s64 pts;
 
-		IVTV_DEBUG_IOCTL("VIDEO_GET_FRAME_COUNT\n");
+		IVTV_DEBUG_IOCTL("IVTV_VIDEO_GET_FRAME_COUNT\n");
 		if (s->type < IVTV_DEC_STREAM_TYPE_MPG) {
 			*frame = 0;
 			break;
@@ -1646,62 +1651,62 @@ static int ivtv_decoder_ioctls(struct file *filp, unsigned int cmd, void *arg)
 		return ivtv_g_pts_frame(itv, &pts, frame);
 	}
 
-	case VIDEO_PLAY: {
+	case IVTV_VIDEO_PLAY: {
 		struct v4l2_decoder_cmd dc;
 
-		IVTV_DEBUG_IOCTL("VIDEO_PLAY\n");
+		IVTV_DEBUG_IOCTL("IVTV_VIDEO_PLAY\n");
 		memset(&dc, 0, sizeof(dc));
 		dc.cmd = V4L2_DEC_CMD_START;
 		return ivtv_video_command(itv, id, &dc, 0);
 	}
 
-	case VIDEO_STOP: {
+	case IVTV_VIDEO_STOP: {
 		struct v4l2_decoder_cmd dc;
 
-		IVTV_DEBUG_IOCTL("VIDEO_STOP\n");
+		IVTV_DEBUG_IOCTL("IVTV_VIDEO_STOP\n");
 		memset(&dc, 0, sizeof(dc));
 		dc.cmd = V4L2_DEC_CMD_STOP;
 		dc.flags = V4L2_DEC_CMD_STOP_TO_BLACK | V4L2_DEC_CMD_STOP_IMMEDIATELY;
 		return ivtv_video_command(itv, id, &dc, 0);
 	}
 
-	case VIDEO_FREEZE: {
+	case IVTV_VIDEO_FREEZE: {
 		struct v4l2_decoder_cmd dc;
 
-		IVTV_DEBUG_IOCTL("VIDEO_FREEZE\n");
+		IVTV_DEBUG_IOCTL("IVTV_VIDEO_FREEZE\n");
 		memset(&dc, 0, sizeof(dc));
 		dc.cmd = V4L2_DEC_CMD_PAUSE;
 		return ivtv_video_command(itv, id, &dc, 0);
 	}
 
-	case VIDEO_CONTINUE: {
+	case IVTV_VIDEO_CONTINUE: {
 		struct v4l2_decoder_cmd dc;
 
-		IVTV_DEBUG_IOCTL("VIDEO_CONTINUE\n");
+		IVTV_DEBUG_IOCTL("IVTV_VIDEO_CONTINUE\n");
 		memset(&dc, 0, sizeof(dc));
 		dc.cmd = V4L2_DEC_CMD_RESUME;
 		return ivtv_video_command(itv, id, &dc, 0);
 	}
 
-	case VIDEO_COMMAND:
-	case VIDEO_TRY_COMMAND: {
+	case IVTV_VIDEO_COMMAND:
+	case IVTV_VIDEO_TRY_COMMAND: {
 		/* Note: struct v4l2_decoder_cmd has the same layout as
 		   struct video_command */
 		struct v4l2_decoder_cmd *dc = arg;
-		int try = (cmd == VIDEO_TRY_COMMAND);
+		int try = (cmd == IVTV_VIDEO_TRY_COMMAND);
 
 		if (try)
-			IVTV_DEBUG_IOCTL("VIDEO_TRY_COMMAND %d\n", dc->cmd);
+			IVTV_DEBUG_IOCTL("IVTV_VIDEO_TRY_COMMAND %d\n", dc->cmd);
 		else
-			IVTV_DEBUG_IOCTL("VIDEO_COMMAND %d\n", dc->cmd);
+			IVTV_DEBUG_IOCTL("IVTV_VIDEO_COMMAND %d\n", dc->cmd);
 		return ivtv_video_command(itv, id, dc, try);
 	}
 
-	case VIDEO_GET_EVENT: {
-		struct video_event *ev = arg;
+	case IVTV_VIDEO_GET_EVENT: {
+		struct ivtv_video_event *ev = arg;
 		DEFINE_WAIT(wait);
 
-		IVTV_DEBUG_IOCTL("VIDEO_GET_EVENT\n");
+		IVTV_DEBUG_IOCTL("IVTV_VIDEO_GET_EVENT\n");
 		if (!(itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT))
 			return -EINVAL;
 		memset(ev, 0, sizeof(*ev));
@@ -1709,15 +1714,15 @@ static int ivtv_decoder_ioctls(struct file *filp, unsigned int cmd, void *arg)
 
 		while (1) {
 			if (test_and_clear_bit(IVTV_F_I_EV_DEC_STOPPED, &itv->i_flags))
-				ev->type = VIDEO_EVENT_DECODER_STOPPED;
+				ev->type = IVTV_VIDEO_EVENT_DECODER_STOPPED;
 			else if (test_and_clear_bit(IVTV_F_I_EV_VSYNC, &itv->i_flags)) {
-				ev->type = VIDEO_EVENT_VSYNC;
+				ev->type = IVTV_VIDEO_EVENT_VSYNC;
 				ev->u.vsync_field = test_bit(IVTV_F_I_EV_VSYNC_FIELD, &itv->i_flags) ?
-					VIDEO_VSYNC_FIELD_ODD : VIDEO_VSYNC_FIELD_EVEN;
+					IVTV_VIDEO_VSYNC_FIELD_ODD : IVTV_VIDEO_VSYNC_FIELD_EVEN;
 				if (itv->output_mode == OUT_UDMA_YUV &&
 					(itv->yuv_info.lace_mode & IVTV_YUV_MODE_MASK) ==
 								IVTV_YUV_MODE_PROGRESSIVE) {
-					ev->u.vsync_field = VIDEO_VSYNC_FIELD_PROGRESSIVE;
+					ev->u.vsync_field = IVTV_VIDEO_VSYNC_FIELD_PROGRESSIVE;
 				}
 			}
 			if (ev->type)
@@ -1743,28 +1748,28 @@ static int ivtv_decoder_ioctls(struct file *filp, unsigned int cmd, void *arg)
 		break;
 	}
 
-	case VIDEO_SELECT_SOURCE:
-		IVTV_DEBUG_IOCTL("VIDEO_SELECT_SOURCE\n");
+	case IVTV_VIDEO_SELECT_SOURCE:
+		IVTV_DEBUG_IOCTL("IVTV_VIDEO_SELECT_SOURCE\n");
 		if (!(itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT))
 			return -EINVAL;
-		return ivtv_passthrough_mode(itv, iarg == VIDEO_SOURCE_DEMUX);
+		return ivtv_passthrough_mode(itv, iarg == IVTV_VIDEO_SOURCE_DEMUX);
 
-	case AUDIO_SET_MUTE:
-		IVTV_DEBUG_IOCTL("AUDIO_SET_MUTE\n");
+	case IVTV_AUDIO_SET_MUTE:
+		IVTV_DEBUG_IOCTL("IVTV_AUDIO_SET_MUTE\n");
 		itv->speed_mute_audio = iarg;
 		return 0;
 
-	case AUDIO_CHANNEL_SELECT:
-		IVTV_DEBUG_IOCTL("AUDIO_CHANNEL_SELECT\n");
-		if (iarg > AUDIO_STEREO_SWAPPED)
+	case IVTV_AUDIO_CHANNEL_SELECT:
+		IVTV_DEBUG_IOCTL("IVTV_AUDIO_CHANNEL_SELECT\n");
+		if (iarg > IVTV_AUDIO_STEREO_SWAPPED)
 			return -EINVAL;
-		return v4l2_ctrl_s_ctrl(itv->ctrl_audio_playback, iarg);
+		return v4l2_ctrl_s_ctrl(itv->ctrl_audio_playback, iarg + 1);
 
-	case AUDIO_BILINGUAL_CHANNEL_SELECT:
-		IVTV_DEBUG_IOCTL("AUDIO_BILINGUAL_CHANNEL_SELECT\n");
-		if (iarg > AUDIO_STEREO_SWAPPED)
+	case IVTV_AUDIO_BILINGUAL_CHANNEL_SELECT:
+		IVTV_DEBUG_IOCTL("IVTV_AUDIO_BILINGUAL_CHANNEL_SELECT\n");
+		if (iarg > IVTV_AUDIO_STEREO_SWAPPED)
 			return -EINVAL;
-		return v4l2_ctrl_s_ctrl(itv->ctrl_audio_multilingual_playback, iarg);
+		return v4l2_ctrl_s_ctrl(itv->ctrl_audio_multilingual_playback, iarg + 1);
 
 	default:
 		return -EINVAL;
@@ -1779,15 +1784,16 @@ static long ivtv_default(struct file *file, void *fh, bool valid_prio,
 
 	if (!valid_prio) {
 		switch (cmd) {
-		case VIDEO_PLAY:
-		case VIDEO_STOP:
-		case VIDEO_FREEZE:
-		case VIDEO_CONTINUE:
-		case VIDEO_COMMAND:
-		case VIDEO_SELECT_SOURCE:
-		case AUDIO_SET_MUTE:
-		case AUDIO_CHANNEL_SELECT:
-		case AUDIO_BILINGUAL_CHANNEL_SELECT:
+		case IVTV_IOC_PASSTHROUGH_MODE:
+		case IVTV_VIDEO_PLAY:
+		case IVTV_VIDEO_STOP:
+		case IVTV_VIDEO_FREEZE:
+		case IVTV_VIDEO_CONTINUE:
+		case IVTV_VIDEO_COMMAND:
+		case IVTV_VIDEO_SELECT_SOURCE:
+		case IVTV_AUDIO_SET_MUTE:
+		case IVTV_AUDIO_CHANNEL_SELECT:
+		case IVTV_AUDIO_BILINGUAL_CHANNEL_SELECT:
 			return -EBUSY;
 		}
 	}
@@ -1804,19 +1810,20 @@ static long ivtv_default(struct file *file, void *fh, bool valid_prio,
 	}
 
 	case IVTV_IOC_DMA_FRAME:
-	case VIDEO_GET_PTS:
-	case VIDEO_GET_FRAME_COUNT:
-	case VIDEO_GET_EVENT:
-	case VIDEO_PLAY:
-	case VIDEO_STOP:
-	case VIDEO_FREEZE:
-	case VIDEO_CONTINUE:
-	case VIDEO_COMMAND:
-	case VIDEO_TRY_COMMAND:
-	case VIDEO_SELECT_SOURCE:
-	case AUDIO_SET_MUTE:
-	case AUDIO_CHANNEL_SELECT:
-	case AUDIO_BILINGUAL_CHANNEL_SELECT:
+	case IVTV_IOC_PASSTHROUGH_MODE:
+	case IVTV_VIDEO_GET_PTS:
+	case IVTV_VIDEO_GET_FRAME_COUNT:
+	case IVTV_VIDEO_GET_EVENT:
+	case IVTV_VIDEO_PLAY:
+	case IVTV_VIDEO_STOP:
+	case IVTV_VIDEO_FREEZE:
+	case IVTV_VIDEO_CONTINUE:
+	case IVTV_VIDEO_COMMAND:
+	case IVTV_VIDEO_TRY_COMMAND:
+	case IVTV_VIDEO_SELECT_SOURCE:
+	case IVTV_AUDIO_SET_MUTE:
+	case IVTV_AUDIO_CHANNEL_SELECT:
+	case IVTV_AUDIO_BILINGUAL_CHANNEL_SELECT:
 		return ivtv_decoder_ioctls(file, cmd, (void *)arg);
 
 	default:
-- 
1.7.7.3

[RFCv2 PATCH 10/12] av7110: replace audio.h, video.h and osd.h by av7110.h.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

Create a new public header, av7110.h, that contains all the av7110
specific audio, video and osd APIs that used to be defined in dvb/audio.h,
dvb/video.h and dvb/osd.h. These APIs are no longer part of DVBv5 but are
now av7110-specific.

This decision was taken during the 2011 Prague V4L-DVB workshop.

Ideally av7110 would be converted to use the replacement V4L2 MPEG
decoder API, but that's a huge job for such an old driver.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 drivers/media/dvb/ttpci/av7110.h |    4 +-
 include/linux/Kbuild             |    1 +
 include/linux/av7110.h           |  609 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 611 insertions(+), 3 deletions(-)
 create mode 100644 include/linux/av7110.h

diff --git a/drivers/media/dvb/ttpci/av7110.h b/drivers/media/dvb/ttpci/av7110.h
index d85b851..e36d6bd 100644
--- a/drivers/media/dvb/ttpci/av7110.h
+++ b/drivers/media/dvb/ttpci/av7110.h
@@ -7,11 +7,9 @@
 #include <linux/i2c.h>
 #include <linux/input.h>
 
-#include <linux/dvb/video.h>
-#include <linux/dvb/audio.h>
+#include <linux/av7110.h>
 #include <linux/dvb/dmx.h>
 #include <linux/dvb/ca.h>
-#include <linux/dvb/osd.h>
 #include <linux/dvb/net.h>
 #include <linux/mutex.h>
 
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index 619b565..51bd25f 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -68,6 +68,7 @@ header-y += audit.h
 header-y += auto_fs.h
 header-y += auto_fs4.h
 header-y += auxvec.h
+header-y += av7110.h
 header-y += ax25.h
 header-y += b1lli.h
 header-y += baycom.h
diff --git a/include/linux/av7110.h b/include/linux/av7110.h
new file mode 100644
index 0000000..a192480
--- /dev/null
+++ b/include/linux/av7110.h
@@ -0,0 +1,609 @@
+/*
+ * av7110.h
+ *
+ * Copyright (C) 2000 Marcus Metzler <marcus@convergence.de>
+ *                  & Ralph  Metzler <ralph@convergence.de>
+ *                    for convergence integrated media GmbH
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ *
+ */
+
+#ifndef _AV7110_API_H_
+#define _AV7110_API_H_
+
+#include <linux/types.h>
+#ifdef __KERNEL__
+#include <linux/compiler.h>
+#else
+#include <stdint.h>
+#include <time.h>
+#endif
+
+
+/* av7110 video ioctls
+ *
+ * The DVB video device controls the MPEG2 video decoder of the av7110 DVB
+ * hardware. It can be accessed through /dev/dvb/adapter0/video0.
+ *
+ * Note that the DVB video device only controls decoding of the MPEG video
+ * stream, not its presentation on the TV or computer screen. On PCs this
+ * is typically handled by an associated video4linux device, e.g. /dev/video,
+ * which allows scaling and defining output windows.
+ *
+ * Only one user can open the Video Device in O_RDWR mode. All other attempts
+ * to open the device in this mode will fail and an error code will be returned.
+ * If the Video Device is opened in O_RDONLY mode, the only ioctl call that can
+ * be used is VIDEO_GET_STATUS. All other calls will return with an error code.
+ *
+ * The write() system call can only be used if VIDEO_SOURCE_MEMORY is selected
+ * in the ioctl call VIDEO_SELECT_SOURCE. The data provided shall be in PES
+ * format. If O_NONBLOCK is not specified the function will block until buffer
+ * space is available. The amount of data to be transferred is implied by count.
+ */
+
+/** video_format_t
+ * Used in the VIDEO_SET_FORMAT ioctl to tell the driver which aspect ratio
+ * the output hardware (e.g. TV) has. It is also used in the data structures
+ * video_status returned by VIDEO_GET_STATUS and video_event returned by
+ * VIDEO_GET_EVENT which report about the display format of the current video
+ * stream.
+ */
+typedef enum {
+	VIDEO_FORMAT_4_3,     /* Select 4:3 format */
+	VIDEO_FORMAT_16_9,    /* Select 16:9 format. */
+	VIDEO_FORMAT_221_1    /* 2.21:1 */
+} video_format_t;
+
+
+/** video_displayformat_t
+ * In case the display format of the video stream and of the display hardware
+ * differ the application has to specify how to handle the cropping of the
+ * picture. This can be done using the VIDEO_SET_DISPLAY_FORMAT call.
+ */
+typedef enum {
+	VIDEO_PAN_SCAN,       /* use pan and scan format */
+	VIDEO_LETTER_BOX,     /* use letterbox format */
+	VIDEO_CENTER_CUT_OUT  /* use center cut out format */
+} video_displayformat_t;
+
+typedef struct {
+	int w;
+	int h;
+	video_format_t aspect_ratio;
+} video_size_t;
+
+/** video_stream_source_t
+ * The video stream source is set through the VIDEO_SELECT_SOURCE call and
+ * can take the following values, depending on whether we are replaying from
+ * an internal (demuxer) or external (user write) source.
+ *
+ * VIDEO_SOURCE_DEMUX selects the demultiplexer (fed either by the frontend
+ * or the DVR device) as the source of the video stream. If VIDEO_SOURCE_MEMORY
+ * is selected the stream comes from the application through the write() system call.
+ */
+typedef enum {
+	VIDEO_SOURCE_DEMUX, /* Select the demux as the main source */
+	VIDEO_SOURCE_MEMORY /* If this source is selected, the stream
+			       comes from the user through the write
+			       system call */
+} video_stream_source_t;
+
+
+/** video_play_state_t
+ * The following values can be returned by the VIDEO_GET_STATUS call
+ * representing the state of video playback.
+ */
+typedef enum {
+	VIDEO_STOPPED, /* Video is stopped */
+	VIDEO_PLAYING, /* Video is currently playing */
+	VIDEO_FREEZED  /* Video is freezed */
+} video_play_state_t;
+
+
+/* Decoder commands */
+#define VIDEO_CMD_PLAY        (0)
+#define VIDEO_CMD_STOP        (1)
+#define VIDEO_CMD_FREEZE      (2)
+#define VIDEO_CMD_CONTINUE    (3)
+
+struct video_event {
+	__s32 type;
+#define VIDEO_EVENT_SIZE_CHANGED	1
+	__kernel_time_t timestamp;
+	union {
+		video_size_t size;
+	} u;
+};
+
+
+/** struct video_status
+ * The VIDEO_GET_STATUS call returns this structure informing about various
+ * states of the playback operation.
+ *
+ * @video_blank: if set video will be blanked out if the channel is changed
+ * or if playback is stopped. Otherwise, the last picture will be displayed.
+ * @play_state: indicates if the video is currently frozen, stopped, or being
+ * played back.
+ * @stream_source: corresponds to the selected source for the
+ * video stream. It can come either from the demultiplexer or from memory.
+ * @video_format: indicates the aspect ratio (one of 4:3 or 16:9) of the
+ * currently played video stream.
+ * @display_format: corresponds to the selected cropping mode in case the
+ * source video format is not the same as the format of the output device.
+ */
+struct video_status {
+	int                   video_blank;   /* blank video on freeze? */
+	video_play_state_t    play_state;    /* current state of playback */
+	video_stream_source_t stream_source; /* current source (demux/memory) */
+	video_format_t        video_format;  /* current aspect ratio of stream*/
+	video_displayformat_t display_format;/* selected cropping mode */
+};
+
+
+/** struct video_still_picture
+ * An I-frame displayed via the VIDEO_STILLPICTURE call is passed on within the
+ * following structure.
+ */
+struct video_still_picture {
+	char __user *iFrame;        /* pointer to a single iframe in memory */
+	__s32 size;
+};
+
+typedef __u16 video_attributes_t;
+/*   bits: descr. */
+/*   15-14 Video compression mode (0=MPEG-1, 1=MPEG-2) */
+/*   13-12 TV system (0=525/60, 1=625/50) */
+/*   11-10 Aspect ratio (0=4:3, 3=16:9) */
+/*    9- 8 permitted display mode on 4:3 monitor (0=both, 1=only pan-sca */
+/*    7    line 21-1 data present in GOP (1=yes, 0=no) */
+/*    6    line 21-2 data present in GOP (1=yes, 0=no) */
+/*    5- 3 source resolution (0=720x480/576, 1=704x480/576, 2=352x480/57 */
+/*    2    source letterboxed (1=yes, 0=no) */
+/*    0    film/camera mode (0=camera, 1=film (625/50 only)) */
+
+
+/* bit definitions for capabilities: */
+/* can the hardware decode MPEG1 and/or MPEG2? */
+#define VIDEO_CAP_MPEG1   1
+#define VIDEO_CAP_MPEG2   2
+/* can you send a system and/or program stream to video device?
+   (you still have to open the video and the audio device but only
+    send the stream to the video device) */
+#define VIDEO_CAP_SYS     4
+#define VIDEO_CAP_PROG    8
+/* can the driver also handle SPU, NAVI and CSS encoded data?
+   (CSS API is not present yet) */
+#define VIDEO_CAP_SPU    16
+#define VIDEO_CAP_NAVI   32
+#define VIDEO_CAP_CSS    64
+
+/** VIDEO_STOP - Stop playing the current stream.
+ */
+#define VIDEO_STOP                 _IO('o', 21)
+
+/** VIDEO_PLAY - Start playing a video stream from the selected source.
+ * Depending on the input parameter, the screen can be blanked out (1)
+ * or displaying the last decoded frame (0).
+ */
+#define VIDEO_PLAY                 _IO('o', 22)
+
+/** VIDEO_FREEZE
+ * This ioctl call suspends the live video stream being played. Decoding and
+ * playing are frozen. It is then possible to restart the decoding and playing
+ * process of the video stream using the VIDEO_CONTINUE command. If
+ * VIDEO_SOURCE_MEMORY is selected in the ioctl call VIDEO_SELECT_SOURCE, the
+ * DVB subsystem will not decode any more data until the ioctl call
+ * VIDEO_CONTINUE or VIDEO_PLAY is performed.
+ */
+#define VIDEO_FREEZE               _IO('o', 23)
+
+/** VIDEO_CONTINUE
+ * Restarts decoding and playing processes of the video stream which was played
+ * before a call to VIDEO_FREEZE was made.
+ */
+#define VIDEO_CONTINUE             _IO('o', 24)
+
+/** VIDEO_SELECT_SOURCE
+ * This ioctl call informs the video device which source shall be used for the
+ * input data. The possible sources are demux or memory. If memory is selected,
+ * the data is fed to the video device through the write command.
+ */
+#define VIDEO_SELECT_SOURCE        _IO('o', 25)
+
+/** VIDEO_SET_BLANK
+ * Blank out the picture (1) or show last decoded frame (0).
+ */
+#define VIDEO_SET_BLANK            _IO('o', 26)
+
+/** VIDEO_GET_STATUS - Return the current status of the device.
+ */
+#define VIDEO_GET_STATUS           _IOR('o', 27, struct video_status)
+
+/** VIDEO_GET_EVENT
+ * This ioctl call returns an event of type video_event if available. If an
+ * event is not available, the behavior depends on whether the device is in
+ * blocking or non-blocking mode. In the latter case, the call fails immediately
+ * with errno set to EWOULDBLOCK. In the former case, the call blocks until an
+ * event becomes available. The standard Linux poll() and/or select() system
+ * calls can be used with the device file descriptor to watch for new events.
+ * For select(), the file descriptor should be included in the exceptfds
+ * argument, and for poll(), POLLPRI should be specified as the wake-up
+ * condition. Read-only permissions are sufficient for this ioctl call.
+ */
+#define VIDEO_GET_EVENT            _IOR('o', 28, struct video_event)
+
+/** VIDEO_SET_DISPLAY_FORMAT - Select the video format to be applied by the MPEG chip on the video.
+ */
+#define VIDEO_SET_DISPLAY_FORMAT   _IO('o', 29)
+
+/** VIDEO_STILLPICTURE
+ * This ioctl call asks the Video Device to display a still picture (I-frame).
+ * The input data shall contain an I-frame. If the pointer is NULL, then the
+ * current displayed still picture is blanked.
+ */
+#define VIDEO_STILLPICTURE         _IOW('o', 30, struct video_still_picture)
+
+/** VIDEO_FAST_FORWARD
+ * This ioctl call asks the Video Device to skip decoding of N number of
+ * I-frames. This call can only be used if VIDEO_SOURCE_MEMORY is selected.
+ */
+#define VIDEO_FAST_FORWARD         _IO('o', 31)
+
+/** VIDEO_SLOWMOTION
+ * This ioctl call asks the video device to repeat decoding frames N number
+ * of times. This call can only be used if VIDEO_SOURCE_MEMORY is selected.
+ */
+#define VIDEO_SLOWMOTION           _IO('o', 32)
+
+/** VIDEO_GET_CAPABILITIES
+ * This ioctl call asks the video device about its decoding capabilities.
+ * On success it returns an integer which has bits set according to the
+ * video capability defines.
+ */
+#define VIDEO_GET_CAPABILITIES     _IOR('o', 33, unsigned int)
+
+/** VIDEO_CLEAR_BUFFER - Clear all video buffers in the driver and in the decoder hardware.
+ */
+#define VIDEO_CLEAR_BUFFER         _IO('o',  34)
+
+/** VIDEO_SET_STREAMTYPE
+ * This ioctl tells the driver which kind of stream to expect being written
+ * to it. If this call is not used the default of video PES is used.
+ * Note: this call doesn't do anything in the av7110 driver and just returns 0.
+ */
+#define VIDEO_SET_STREAMTYPE       _IO('o', 36)
+
+/** VIDEO_SET_FORMAT
+ * This ioctl sets the screen format (aspect ratio) of the connected output
+ * device (TV) so that the output of the decoder can be adjusted accordingly.
+ */
+#define VIDEO_SET_FORMAT           _IO('o', 37)
+
+/** VIDEO_GET_SIZE
+ */
+#define VIDEO_GET_SIZE             _IOR('o', 55, video_size_t)
+
+
+
+/* av7110 audio ioctls
+ *
+ * The DVB audio device controls the MPEG2 audio decoder of the av7110 DVB
+ * hardware. It can be accessed through /dev/dvb/adapter0/audio0.
+ *
+ * Only one user can open the Audio Device in O_RDWR mode. All other attempts
+ * to open the device in this mode will fail and an error code will be returned.
+ * If the Audio Device is opened in O_RDONLY mode, the only ioctl call that can
+ * be used is AUDIO_GET_STATUS. All other calls will return with an error code.
+ *
+ * The write() system call can only be used if AUDIO_SOURCE_MEMORY is selected
+ * in the ioctl call AUDIO_SELECT_SOURCE. The data provided shall be in PES
+ * format. If O_NONBLOCK is not specified the function will block until buffer
+ * space is available. The amount of data to be transferred is implied by count.
+ */
+
+/** audio_stream_source_t
+ *
+ * The audio stream source is set through the AUDIO_SELECT_SOURCE call and can take
+ * the following values, depending on whether we are replaying from an internal (demux) or
+ * external (user write) source.
+ *
+ * AUDIO_SOURCE_DEMUX selects the demultiplexer (fed either by the frontend or the
+ * DVR device) as the source of the video stream. If AUDIO_SOURCE_MEMORY
+ * is selected the stream comes from the application through the write() system
+ * call.
+ */
+typedef enum {
+	AUDIO_SOURCE_DEMUX, /* Select the demux as the main source */
+	AUDIO_SOURCE_MEMORY /* Select internal memory as the main source */
+} audio_stream_source_t;
+
+
+/** audio_play_state_t
+ *
+ * The following values can be returned by the AUDIO_GET_STATUS call representing the
+ * state of audio playback.
+ */
+typedef enum {
+	AUDIO_STOPPED,      /* Device is stopped */
+	AUDIO_PLAYING,      /* Device is currently playing */
+	AUDIO_PAUSED        /* Device is paused */
+} audio_play_state_t;
+
+
+/** audio_channel_select_t
+ *
+ * The audio channel selected via AUDIO_CHANNEL_SELECT is determined by the
+ * following values.
+ */
+typedef enum {
+	AUDIO_STEREO,
+	AUDIO_MONO_LEFT,
+	AUDIO_MONO_RIGHT,
+	AUDIO_MONO,
+	AUDIO_STEREO_SWAPPED
+} audio_channel_select_t;
+
+
+/** struct audio_mixer
+ *
+ * The following structure is used by the AUDIO_SET_MIXER call to set the audio
+ * volume.
+ */
+typedef struct audio_mixer {
+	unsigned int volume_left;
+	unsigned int volume_right;
+  // what else do we need? bass, pass-through, ...
+} audio_mixer_t;
+
+
+/** struct audio_status
+ *
+ * The AUDIO_GET_STATUS call returns the following structure informing about various
+ * states of the playback operation.
+ */
+typedef struct audio_status {
+	int                    AV_sync_state;  /* sync audio and video? */
+	int                    mute_state;     /* audio is muted */
+	audio_play_state_t     play_state;     /* current playback state */
+	audio_stream_source_t  stream_source;  /* current stream source */
+	audio_channel_select_t channel_select; /* currently selected channel */
+	int                    bypass_mode;    /* pass on audio data to */
+	audio_mixer_t	       mixer_state;    /* current mixer state */
+} audio_status_t;                              /* separate decoder hardware */
+
+/** audio encodings
+ *
+ * A call to AUDIO_GET_CAPABILITIES returns an unsigned integer with the following
+ * bits set according to the hardware's capabilities.
+ */
+#define AUDIO_CAP_DTS    1
+#define AUDIO_CAP_LPCM   2
+#define AUDIO_CAP_MP1    4
+#define AUDIO_CAP_MP2    8
+#define AUDIO_CAP_MP3   16
+#define AUDIO_CAP_AAC   32
+#define AUDIO_CAP_OGG   64
+#define AUDIO_CAP_SDDS 128
+#define AUDIO_CAP_AC3  256
+
+/** AUDIO_STOP - Stop playing the current stream.
+ */
+#define AUDIO_STOP                 _IO('o', 1)
+
+/** AUDIO_PLAY - Start playing an audio stream from the selected source.
+ */
+#define AUDIO_PLAY                 _IO('o', 2)
+
+/** AUDIO_PAUSE
+ * Suspends the audio stream being played. Decoding and playing are paused.
+ * It is then possible to restart again decoding and playing process of the
+ * audio stream using AUDIO_CONTINUE command.
+ *
+ * If AUDIO_SOURCE_MEMORY is selected in the ioctl call AUDIO_SELECT_SOURCE,
+ * the DVB-subsystem will not decode (consume) any more data until the ioctl
+ * call AUDIO_CONTINUE or AUDIO_PLAY is performed.
+ */
+#define AUDIO_PAUSE                _IO('o', 3)
+
+/** AUDIO_CONTINUE - Restarts the decoding and playing process previously paused with AUDIO_PAUSE command.
+ *
+ * It only works if the stream were previously stopped with AUDIO_PAUSE.
+ */
+#define AUDIO_CONTINUE             _IO('o', 4)
+
+/** AUDIO_SELECT_SOURCE
+ * This ioctl call informs the audio device which source shall be used for
+ * the input data. The possible sources are demux or memory. If
+ * AUDIO_SOURCE_MEMORY is selected, the data is fed to the Audio Device
+ * through the write command.
+ */
+#define AUDIO_SELECT_SOURCE        _IO('o', 5)
+
+/** AUDIO_SET_MUTE - Mute the stream that is currently being played.
+ */
+#define AUDIO_SET_MUTE             _IO('o', 6)
+
+/** AUDIO_SET_AV_SYNC - Turn ON or OFF A/V synchronization.
+ */
+#define AUDIO_SET_AV_SYNC          _IO('o', 7)
+
+/** AUDIO_SET_BYPASS_MODE
+ * This ioctl call asks the Audio Device to bypass the Audio decoder and forward
+ * the stream without decoding. This mode shall be used if streams that can’t be
+ * handled by the DVB system shall be decoded. Dolby DigitalTM streams are
+ * automatically forwarded by the DVB subsystem if the hardware can handle it.
+ */
+#define AUDIO_SET_BYPASS_MODE      _IO('o', 8)
+
+/** AUDIO_CHANNEL_SELECT - Select the requested channel if possible.
+ */
+#define AUDIO_CHANNEL_SELECT       _IO('o', 9)
+
+/** AUDIO_GET_STATUS - Return the current state of the Audio Device.
+ */
+#define AUDIO_GET_STATUS           _IOR('o', 10, audio_status_t)
+
+/** AUDIO_GET_CAPABILITIES - Return the decoding capabilities of the audio hardware.
+ * Returns a bit array of supported sound formats.
+ */
+#define AUDIO_GET_CAPABILITIES     _IOR('o', 11, unsigned int)
+
+/** AUDIO_CLEAR_BUFFER - Clear all software and hardware buffers of the audio decoder device.
+ */
+#define AUDIO_CLEAR_BUFFER         _IO('o',  12)
+
+/** AUDIO_SET_ID
+ * This ioctl selects which sub-stream is to be decoded if a program or system
+ * stream is sent to the video device. If no audio stream type is set the id
+ * has to be in [0xC0,0xDF] for MPEG sound, in [0x80,0x87] for AC3 and in
+ * [0xA0,0xA7] for LPCM. More specifications may follow for other stream types.
+ * If the stream type is set the id just specifies the substream id of the
+ * audio stream and only the first 5 bits are recognized.
+ * Note: this call doesn't do anything in the av7110 driver and just returns 0.
+ */
+#define AUDIO_SET_ID               _IO('o', 13)
+
+/** AUDIO_SET_MIXER - Adjusts the mixer settings of the audio decoder.
+ */
+#define AUDIO_SET_MIXER            _IOW('o', 14, audio_mixer_t)
+
+/** AUDIO_SET_STREAMTYPE
+ * This ioctl tells the driver which kind of audio stream to expect. This is
+ * useful if the stream offers several audio sub-streams like LPCM and AC3.
+ * Note: this call doesn't do anything in the av7110 driver and just returns 0.
+ */
+#define AUDIO_SET_STREAMTYPE       _IO('o', 15)
+
+
+/* av7110 OSD ioctls */
+
+typedef enum {
+  // All functions return -2 on "not open"
+  OSD_Close=1,    // ()
+  // Disables OSD and releases the buffers
+  // returns 0 on success
+  OSD_Open,       // (x0,y0,x1,y1,BitPerPixel[2/4/8](color&0x0F),mix[0..15](color&0xF0))
+  // Opens OSD with this size and bit depth
+  // returns 0 on success, -1 on DRAM allocation error, -2 on "already open"
+  OSD_Show,       // ()
+  // enables OSD mode
+  // returns 0 on success
+  OSD_Hide,       // ()
+  // disables OSD mode
+  // returns 0 on success
+  OSD_Clear,      // ()
+  // Sets all pixel to color 0
+  // returns 0 on success
+  OSD_Fill,       // (color)
+  // Sets all pixel to color <col>
+  // returns 0 on success
+  OSD_SetColor,   // (color,R{x0},G{y0},B{x1},opacity{y1})
+  // set palette entry <num> to <r,g,b>, <mix> and <trans> apply
+  // R,G,B: 0..255
+  // R=Red, G=Green, B=Blue
+  // opacity=0:      pixel opacity 0% (only video pixel shows)
+  // opacity=1..254: pixel opacity as specified in header
+  // opacity=255:    pixel opacity 100% (only OSD pixel shows)
+  // returns 0 on success, -1 on error
+  OSD_SetPalette, // (firstcolor{color},lastcolor{x0},data)
+  // Set a number of entries in the palette
+  // sets the entries "firstcolor" through "lastcolor" from the array "data"
+  // data has 4 byte for each color:
+  // R,G,B, and a opacity value: 0->transparent, 1..254->mix, 255->pixel
+  OSD_SetTrans,   // (transparency{color})
+  // Sets transparency of mixed pixel (0..15)
+  // returns 0 on success
+  OSD_SetPixel,   // (x0,y0,color)
+  // sets pixel <x>,<y> to color number <col>
+  // returns 0 on success, -1 on error
+  OSD_GetPixel,   // (x0,y0)
+  // returns color number of pixel <x>,<y>,  or -1
+  OSD_SetRow,     // (x0,y0,x1,data)
+  // fills pixels x0,y through  x1,y with the content of data[]
+  // returns 0 on success, -1 on clipping all pixel (no pixel drawn)
+  OSD_SetBlock,   // (x0,y0,x1,y1,increment{color},data)
+  // fills pixels x0,y0 through  x1,y1 with the content of data[]
+  // inc contains the width of one line in the data block,
+  // inc<=0 uses blockwidth as linewidth
+  // returns 0 on success, -1 on clipping all pixel
+  OSD_FillRow,    // (x0,y0,x1,color)
+  // fills pixels x0,y through  x1,y with the color <col>
+  // returns 0 on success, -1 on clipping all pixel
+  OSD_FillBlock,  // (x0,y0,x1,y1,color)
+  // fills pixels x0,y0 through  x1,y1 with the color <col>
+  // returns 0 on success, -1 on clipping all pixel
+  OSD_Line,       // (x0,y0,x1,y1,color)
+  // draw a line from x0,y0 to x1,y1 with the color <col>
+  // returns 0 on success
+  OSD_Query,      // (x0,y0,x1,y1,xasp{color}}), yasp=11
+  // fills parameters with the picture dimensions and the pixel aspect ratio
+  // returns 0 on success
+  OSD_Test,       // ()
+  // draws a test picture. for debugging purposes only
+  // returns 0 on success
+// TODO: remove "test" in final version
+  OSD_Text,       // (x0,y0,size,color,text)
+  OSD_SetWindow, //  (x0) set window with number 0<x0<8 as current
+  OSD_MoveWindow, //  move current window to (x0, y0)
+  OSD_OpenRaw,	// Open other types of OSD windows
+} OSD_Command;
+
+typedef struct osd_cmd_s {
+	OSD_Command cmd;
+	int x0;
+	int y0;
+	int x1;
+	int y1;
+	int color;
+	void __user *data;
+} osd_cmd_t;
+
+/* OSD_OpenRaw: set 'color' to desired window type */
+typedef enum {
+	OSD_BITMAP1,           /* 1 bit bitmap */
+	OSD_BITMAP2,           /* 2 bit bitmap */
+	OSD_BITMAP4,           /* 4 bit bitmap */
+	OSD_BITMAP8,           /* 8 bit bitmap */
+	OSD_BITMAP1HR,         /* 1 Bit bitmap half resolution */
+	OSD_BITMAP2HR,         /* 2 bit bitmap half resolution */
+	OSD_BITMAP4HR,         /* 4 bit bitmap half resolution */
+	OSD_BITMAP8HR,         /* 8 bit bitmap half resolution */
+	OSD_YCRCB422,          /* 4:2:2 YCRCB Graphic Display */
+	OSD_YCRCB444,          /* 4:4:4 YCRCB Graphic Display */
+	OSD_YCRCB444HR,        /* 4:4:4 YCRCB graphic half resolution */
+	OSD_VIDEOTSIZE,        /* True Size Normal MPEG Video Display */
+	OSD_VIDEOHSIZE,        /* MPEG Video Display Half Resolution */
+	OSD_VIDEOQSIZE,        /* MPEG Video Display Quarter Resolution */
+	OSD_VIDEODSIZE,        /* MPEG Video Display Double Resolution */
+	OSD_VIDEOTHSIZE,       /* True Size MPEG Video Display Half Resolution */
+	OSD_VIDEOTQSIZE,       /* True Size MPEG Video Display Quarter Resolution*/
+	OSD_VIDEOTDSIZE,       /* True Size MPEG Video Display Double Resolution */
+	OSD_VIDEONSIZE,        /* Full Size MPEG Video Display */
+	OSD_CURSOR             /* Cursor */
+} osd_raw_window_t;
+
+typedef struct osd_cap_s {
+	int  cmd;
+#define OSD_CAP_MEMSIZE         1  /* memory size */
+	long val;
+} osd_cap_t;
+
+
+#define OSD_SEND_CMD            _IOW('o', 160, osd_cmd_t)
+#define OSD_GET_CAPABILITY      _IOR('o', 161, osd_cap_t)
+
+#endif
+
-- 
1.7.7.3

[RFCv2 PATCH 11/12] Replace audio.xml and video.xml with av.xml.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 Documentation/DocBook/media/Makefile         |   32 +-
 Documentation/DocBook/media/dvb/audio.xml    | 1203 -------------------
 Documentation/DocBook/media/dvb/av.xml       |  108 ++
 Documentation/DocBook/media/dvb/dvbapi.xml   |   16 +-
 Documentation/DocBook/media/dvb/examples.xml |    1 -
 Documentation/DocBook/media/dvb/intro.xml    |    9 -
 Documentation/DocBook/media/dvb/video.xml    | 1657 --------------------------
 7 files changed, 111 insertions(+), 2915 deletions(-)
 delete mode 100644 Documentation/DocBook/media/dvb/audio.xml
 create mode 100644 Documentation/DocBook/media/dvb/av.xml
 delete mode 100644 Documentation/DocBook/media/dvb/video.xml

diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile
index 6628b4b..fb40a52 100644
--- a/Documentation/DocBook/media/Makefile
+++ b/Documentation/DocBook/media/Makefile
@@ -11,12 +11,10 @@ MEDIA_TEMP =  media-entities.tmpl \
 	      media-indices.tmpl \
 	      videodev2.h.xml \
 	      v4l2.xml \
-	      audio.h.xml \
 	      ca.h.xml \
 	      dmx.h.xml \
 	      frontend.h.xml \
 	      net.h.xml \
-	      video.h.xml \
 
 IMGFILES := $(patsubst %.b64,%, $(notdir $(shell ls $(MEDIA_SRC_DIR)/*.b64)))
 OBJIMGFILES := $(addprefix $(MEDIA_OBJ_DIR)/, $(IMGFILES))
@@ -57,12 +55,10 @@ FUNCS = \
 
 IOCTLS = \
 	$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/videodev2.h) \
-	$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/audio.h) \
 	$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/ca.h) \
 	$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/dmx.h) \
 	$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/frontend.h) \
 	$(shell perl -ne 'print "$$1 " if /\#define\s+([A-Z][^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/net.h) \
-	$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/video.h) \
 	$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/media.h) \
 	$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/v4l2-subdev.h) \
 	VIDIOC_SUBDEV_G_FRAME_INTERVAL \
@@ -77,24 +73,20 @@ TYPES = \
 
 ENUMS = \
 	$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/videodev2.h) \
-	$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/audio.h) \
 	$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/ca.h) \
 	$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/dmx.h) \
 	$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/frontend.h) \
 	$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/net.h) \
-	$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/video.h) \
 	$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/media.h) \
 	$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/v4l2-mediabus.h) \
 	$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/v4l2-subdev.h)
 
 STRUCTS = \
 	$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/linux/videodev2.h) \
-	$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s\{]+)\s*/)' $(srctree)/include/linux/dvb/audio.h) \
 	$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/linux/dvb/ca.h) \
 	$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/linux/dvb/dmx.h) \
 	$(shell perl -ne 'print "$$1 " if (!/dtv\_cmds\_h/ && /^struct\s+([^\s]+)\s+/)' $(srctree)/include/linux/dvb/frontend.h) \
 	$(shell perl -ne 'print "$$1 " if (/^struct\s+([A-Z][^\s]+)\s+/)' $(srctree)/include/linux/dvb/net.h) \
-	$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/linux/dvb/video.h) \
 	$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/linux/media.h) \
 	$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/linux/v4l2-subdev.h) \
 	$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/linux/v4l2-mediabus.h)
@@ -183,7 +175,7 @@ DVB_DOCUMENTED = \
 	-e "s,\(define\s\+\)\(DTV_[A-Z0-9_]\+\)\(\s\+[0-9]\+\),\1\<link linkend=\"\2\">\2\<\/link\>\3,g" \
 	-e "s,<link\s\+linkend=\".*\">\(DTV_IOCTL_MAX_MSGS\|dtv_cmds_h\|__.*_old\)<\/link>,\1,g" \
 	-e ":a;s/\(linkend=\".*\)_\(.*\">\)/\1-\2/;ta" \
-	-e "s,\(audio-mixer\|audio-karaoke\|audio-status\|ca-slot-info\|ca-descr-info\|ca-caps\|ca-msg\|ca-descr\|ca-pid\|dmx-filter\|dmx-caps\|video-system\|video-highlight\|video-spu\|video-spu-palette\|video-navi-pack\)-t,\1,g" \
+	-e "s,\(ca-slot-info\|ca-descr-info\|ca-caps\|ca-msg\|ca-descr\|ca-pid\|dmx-filter\|dmx-caps\)-t,\1,g" \
 	-e "s,DTV-ISDBT-LAYER[A-C],DTV-ISDBT-LAYER,g" \
 	-e "s,\(define\s\+\)\([A-Z0-9_]\+\)\(\s\+_IO\),\1\<link linkend=\"\2\">\2\<\/link\>\3,g" \
 	-e "s,<link\s\+linkend=\".*\">\(__.*_OLD\)<\/link>,\1,g" \
@@ -214,17 +206,6 @@ $(MEDIA_OBJ_DIR)/videodev2.h.xml: $(srctree)/include/linux/videodev2.h $(MEDIA_O
 	@(					\
 	echo "</programlisting>") >> $@
 
-$(MEDIA_OBJ_DIR)/audio.h.xml: $(srctree)/include/linux/dvb/audio.h $(MEDIA_OBJ_DIR)/v4l2.xml
-	@$($(quiet)gen_xml)
-	@(					\
-	echo "<programlisting>") > $@
-	@(					\
-	expand --tabs=8 < $< |			\
-	  sed $(ESCAPE) $(DVB_DOCUMENTED) |	\
-	  sed 's/i\.e\./&ie;/') >> $@
-	@(					\
-	echo "</programlisting>") >> $@
-
 $(MEDIA_OBJ_DIR)/ca.h.xml: $(srctree)/include/linux/dvb/ca.h $(MEDIA_OBJ_DIR)/v4l2.xml
 	@$($(quiet)gen_xml)
 	@(					\
@@ -269,17 +250,6 @@ $(MEDIA_OBJ_DIR)/net.h.xml: $(srctree)/include/linux/dvb/net.h $(MEDIA_OBJ_DIR)/
 	@(					\
 	echo "</programlisting>") >> $@
 
-$(MEDIA_OBJ_DIR)/video.h.xml: $(srctree)/include/linux/dvb/video.h $(MEDIA_OBJ_DIR)/v4l2.xml
-	@$($(quiet)gen_xml)
-	@(					\
-	echo "<programlisting>") > $@
-	@(					\
-	expand --tabs=8 < $< |			\
-	  sed $(ESCAPE) $(DVB_DOCUMENTED) |	\
-	  sed 's/i\.e\./&ie;/') >> $@
-	@(					\
-	echo "</programlisting>") >> $@
-
 $(MEDIA_OBJ_DIR)/media-entities.tmpl: $(MEDIA_OBJ_DIR)/v4l2.xml
 	@$($(quiet)gen_xml)
 	@(								\
diff --git a/Documentation/DocBook/media/dvb/audio.xml b/Documentation/DocBook/media/dvb/audio.xml
deleted file mode 100644
index d643862..0000000
--- a/Documentation/DocBook/media/dvb/audio.xml
+++ /dev/null
@@ -1,1203 +0,0 @@
-<title>DVB Audio Device</title>
-<para>The DVB audio device controls the MPEG2 audio decoder of the DVB hardware. It
-can be accessed through <emphasis role="tt">/dev/dvb/adapter0/audio0</emphasis>. Data types and and
-ioctl definitions can be accessed by including <emphasis role="tt">linux/dvb/video.h</emphasis> in your
-application.
-</para>
-<para>Please note that some DVB cards don&#8217;t have their own MPEG decoder, which results in
-the omission of the audio and video device.
-</para>
-
-<section id="audio_data_types">
-<title>Audio Data Types</title>
-<para>This section describes the structures, data types and defines used when talking to the
-audio device.
-</para>
-
-<section id="audio-stream-source-t">
-<title>audio_stream_source_t</title>
-<para>The audio stream source is set through the AUDIO_SELECT_SOURCE call and can take
-the following values, depending on whether we are replaying from an internal (demux) or
-external (user write) source.
-</para>
-<programlisting>
-typedef enum {
-	AUDIO_SOURCE_DEMUX,
-	AUDIO_SOURCE_MEMORY
-} audio_stream_source_t;
-</programlisting>
-<para>AUDIO_SOURCE_DEMUX selects the demultiplexer (fed either by the frontend or the
-DVR device) as the source of the video stream. If AUDIO_SOURCE_MEMORY
-is selected the stream comes from the application through the <emphasis role="tt">write()</emphasis> system
-call.
-</para>
-
-</section>
-<section id="audio-play-state-t">
-<title>audio_play_state_t</title>
-<para>The following values can be returned by the AUDIO_GET_STATUS call representing the
-state of audio playback.
-</para>
-<programlisting>
-typedef enum {
-	AUDIO_STOPPED,
-	AUDIO_PLAYING,
-	AUDIO_PAUSED
-} audio_play_state_t;
-</programlisting>
-
-</section>
-<section id="audio-channel-select-t">
-<title>audio_channel_select_t</title>
-<para>The audio channel selected via AUDIO_CHANNEL_SELECT is determined by the
-following values.
-</para>
-<programlisting>
-typedef enum {
-	AUDIO_STEREO,
-	AUDIO_MONO_LEFT,
-	AUDIO_MONO_RIGHT,
-	AUDIO_MONO,
-	AUDIO_STEREO_SWAPPED
-} audio_channel_select_t;
-</programlisting>
-
-</section>
-<section id="audio-status">
-<title>struct audio_status</title>
-<para>The AUDIO_GET_STATUS call returns the following structure informing about various
-states of the playback operation.
-</para>
-<programlisting>
-typedef struct audio_status {
-	boolean AV_sync_state;
-	boolean mute_state;
-	audio_play_state_t play_state;
-	audio_stream_source_t stream_source;
-	audio_channel_select_t channel_select;
-	boolean bypass_mode;
-	audio_mixer_t mixer_state;
-} audio_status_t;
-</programlisting>
-
-</section>
-<section id="audio-mixer">
-<title>struct audio_mixer</title>
-<para>The following structure is used by the AUDIO_SET_MIXER call to set the audio
-volume.
-</para>
-<programlisting>
-typedef struct audio_mixer {
-	unsigned int volume_left;
-	unsigned int volume_right;
-} audio_mixer_t;
-</programlisting>
-
-</section>
-<section id="audio_encodings">
-<title>audio encodings</title>
-<para>A call to AUDIO_GET_CAPABILITIES returns an unsigned integer with the following
-bits set according to the hardwares capabilities.
-</para>
-<programlisting>
- #define AUDIO_CAP_DTS    1
- #define AUDIO_CAP_LPCM   2
- #define AUDIO_CAP_MP1    4
- #define AUDIO_CAP_MP2    8
- #define AUDIO_CAP_MP3   16
- #define AUDIO_CAP_AAC   32
- #define AUDIO_CAP_OGG   64
- #define AUDIO_CAP_SDDS 128
- #define AUDIO_CAP_AC3  256
-</programlisting>
-
-</section>
-<section id="audio-karaoke">
-<title>struct audio_karaoke</title>
-<para>The ioctl AUDIO_SET_KARAOKE uses the following format:
-</para>
-<programlisting>
-typedef
-struct audio_karaoke {
-	int vocal1;
-	int vocal2;
-	int melody;
-} audio_karaoke_t;
-</programlisting>
-<para>If Vocal1 or Vocal2 are non-zero, they get mixed into left and right t at 70% each. If both,
-Vocal1 and Vocal2 are non-zero, Vocal1 gets mixed into the left channel and Vocal2 into the
-right channel at 100% each. Ff Melody is non-zero, the melody channel gets mixed into left
-and right.
-</para>
-
-</section>
-<section id="audio-attributes-t">
-<title>audio attributes</title>
-<para>The following attributes can be set by a call to AUDIO_SET_ATTRIBUTES:
-</para>
-<programlisting>
- typedef uint16_t audio_attributes_t;
- /&#x22C6;   bits: descr. &#x22C6;/
- /&#x22C6;   15-13 audio coding mode (0=ac3, 2=mpeg1, 3=mpeg2ext, 4=LPCM, 6=DTS, &#x22C6;/
- /&#x22C6;   12    multichannel extension &#x22C6;/
- /&#x22C6;   11-10 audio type (0=not spec, 1=language included) &#x22C6;/
- /&#x22C6;    9- 8 audio application mode (0=not spec, 1=karaoke, 2=surround) &#x22C6;/
- /&#x22C6;    7- 6 Quantization / DRC (mpeg audio: 1=DRC exists)(lpcm: 0=16bit,  &#x22C6;/
- /&#x22C6;    5- 4 Sample frequency fs (0=48kHz, 1=96kHz) &#x22C6;/
- /&#x22C6;    2- 0 number of audio channels (n+1 channels) &#x22C6;/
-</programlisting>
- </section></section>
-<section id="audio_function_calls">
-<title>Audio Function Calls</title>
-
-
-<section id="audio_fopen">
-<title>open()</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This system call opens a named audio device (e.g. /dev/dvb/adapter0/audio0)
- for subsequent use. When an open() call has succeeded, the device will be ready
- for use. The significance of blocking or non-blocking mode is described in the
- documentation for functions where there is a difference. It does not affect the
- semantics of the open() call itself. A device opened in blocking mode can later
- be put into non-blocking mode (and vice versa) using the F_SETFL command
- of the fcntl system call. This is a standard system call, documented in the Linux
- manual page for fcntl. Only one user can open the Audio Device in O_RDWR
- mode. All other attempts to open the device in this mode will fail, and an error
- code will be returned. If the Audio Device is opened in O_RDONLY mode, the
- only ioctl call that can be used is AUDIO_GET_STATUS. All other call will
- return with an error code.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int open(const char &#x22C6;deviceName, int flags);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>const char
- *deviceName</para>
-</entry><entry
- align="char">
-<para>Name of specific audio device.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int flags</para>
-</entry><entry
- align="char">
-<para>A bit-wise OR of the following flags:</para>
-</entry>
- </row><row><entry
- align="char">
-</entry><entry
- align="char">
-<para>O_RDONLY read-only access</para>
-</entry>
- </row><row><entry
- align="char">
-</entry><entry
- align="char">
-<para>O_RDWR read/write access</para>
-</entry>
- </row><row><entry
- align="char">
-</entry><entry
- align="char">
-<para>O_NONBLOCK open in non-blocking mode</para>
-</entry>
- </row><row><entry
- align="char">
-</entry><entry
- align="char">
-<para>(blocking mode is the default)</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>RETURN VALUE</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>ENODEV</para>
-</entry><entry
- align="char">
-<para>Device driver not loaded/available.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>EBUSY</para>
-</entry><entry
- align="char">
-<para>Device or resource busy.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>EINVAL</para>
-</entry><entry
- align="char">
-<para>Invalid argument.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section>
-<section id="audio_fclose">
-<title>close()</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This system call closes a previously opened audio device.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int close(int fd);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>RETURN VALUE</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EBADF</para>
-</entry><entry
- align="char">
-<para>fd is not a valid open file descriptor.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section>
-<section id="audio_fwrite">
-<title>write()</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This system call can only be used if AUDIO_SOURCE_MEMORY is selected
- in the ioctl call AUDIO_SELECT_SOURCE. The data provided shall be in
- PES format. If O_NONBLOCK is not specified the function will block until
- buffer space is available. The amount of data to be transferred is implied by
- count.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>size_t write(int fd, const void &#x22C6;buf, size_t count);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>void *buf</para>
-</entry><entry
- align="char">
-<para>Pointer to the buffer containing the PES data.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>size_t count</para>
-</entry><entry
- align="char">
-<para>Size of buf.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>RETURN VALUE</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EPERM</para>
-</entry><entry
- align="char">
-<para>Mode AUDIO_SOURCE_MEMORY not selected.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>ENOMEM</para>
-</entry><entry
- align="char">
-<para>Attempted to write more data than the internal buffer can
- hold.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>EBADF</para>
-</entry><entry
- align="char">
-<para>fd is not a valid open file descriptor.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section><section id="AUDIO_STOP"
-role="subsection"><title>AUDIO_STOP</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the Audio Device to stop playing the current stream.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(int fd, int request = AUDIO_STOP);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_STOP for this command.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="AUDIO_PLAY"
-role="subsection"><title>AUDIO_PLAY</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the Audio Device to start playing an audio stream from the
- selected source.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(int fd, int request = AUDIO_PLAY);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_PLAY for this command.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="AUDIO_PAUSE"
-role="subsection"><title>AUDIO_PAUSE</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call suspends the audio stream being played. Decoding and playing
- are paused. It is then possible to restart again decoding and playing process of
- the audio stream using AUDIO_CONTINUE command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>If AUDIO_SOURCE_MEMORY is selected in the ioctl call
- AUDIO_SELECT_SOURCE, the DVB-subsystem will not decode (consume)
- any more data until the ioctl call AUDIO_CONTINUE or AUDIO_PLAY is
- performed.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(int fd, int request = AUDIO_PAUSE);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_PAUSE for this command.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="AUDIO_CONTINUE"
-role="subsection"><title>AUDIO_CONTINUE</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl restarts the decoding and playing process previously paused
-with AUDIO_PAUSE command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>It only works if the stream were previously stopped with AUDIO_PAUSE</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(int fd, int request = AUDIO_CONTINUE);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_CONTINUE for this command.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="AUDIO_SELECT_SOURCE"
-role="subsection"><title>AUDIO_SELECT_SOURCE</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call informs the audio device which source shall be used
- for the input data. The possible sources are demux or memory. If
- AUDIO_SOURCE_MEMORY is selected, the data is fed to the Audio Device
- through the write command.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(int fd, int request = AUDIO_SELECT_SOURCE,
- audio_stream_source_t source);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_SELECT_SOURCE for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>audio_stream_source_t
- source</para>
-</entry><entry
- align="char">
-<para>Indicates the source that shall be used for the Audio
- stream.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="AUDIO_SET_MUTE"
-role="subsection"><title>AUDIO_SET_MUTE</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the audio device to mute the stream that is currently being
- played.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(int fd, int request = AUDIO_SET_MUTE,
- boolean state);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_SET_MUTE for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>boolean state</para>
-</entry><entry
- align="char">
-<para>Indicates if audio device shall mute or not.</para>
-</entry>
- </row><row><entry
- align="char">
-</entry><entry
- align="char">
-<para>TRUE Audio Mute</para>
-</entry>
- </row><row><entry
- align="char">
-</entry><entry
- align="char">
-<para>FALSE Audio Un-mute</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="AUDIO_SET_AV_SYNC"
-role="subsection"><title>AUDIO_SET_AV_SYNC</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the Audio Device to turn ON or OFF A/V synchronization.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(int fd, int request = AUDIO_SET_AV_SYNC,
- boolean state);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_AV_SYNC for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>boolean state</para>
-</entry><entry
- align="char">
-<para>Tells the DVB subsystem if A/V synchronization shall be
- ON or OFF.</para>
-</entry>
- </row><row><entry
- align="char">
-</entry><entry
- align="char">
-<para>TRUE AV-sync ON</para>
-</entry>
- </row><row><entry
- align="char">
-</entry><entry
- align="char">
-<para>FALSE AV-sync OFF</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="AUDIO_SET_BYPASS_MODE"
-role="subsection"><title>AUDIO_SET_BYPASS_MODE</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the Audio Device to bypass the Audio decoder and forward
- the stream without decoding. This mode shall be used if streams that can&#8217;t be
- handled by the DVB system shall be decoded. Dolby DigitalTM streams are
- automatically forwarded by the DVB subsystem if the hardware can handle it.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(int fd, int request =
- AUDIO_SET_BYPASS_MODE, boolean mode);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_SET_BYPASS_MODE for this
- command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>boolean mode</para>
-</entry><entry
- align="char">
-<para>Enables or disables the decoding of the current Audio
- stream in the DVB subsystem.</para>
-</entry>
- </row><row><entry
- align="char">
-</entry><entry
- align="char">
-<para>TRUE Bypass is disabled</para>
-</entry>
- </row><row><entry
- align="char">
-</entry><entry
- align="char">
-<para>FALSE Bypass is enabled</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="AUDIO_CHANNEL_SELECT"
-role="subsection"><title>AUDIO_CHANNEL_SELECT</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the Audio Device to select the requested channel if possible.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(int fd, int request =
- AUDIO_CHANNEL_SELECT, audio_channel_select_t);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_CHANNEL_SELECT for this
- command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>audio_channel_select_t
- ch</para>
-</entry><entry
- align="char">
-<para>Select the output format of the audio (mono left/right,
- stereo).</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="AUDIO_GET_STATUS"
-role="subsection"><title>AUDIO_GET_STATUS</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the Audio Device to return the current state of the Audio
- Device.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(int fd, int request = AUDIO_GET_STATUS,
- struct audio_status &#x22C6;status);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_GET_STATUS for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>struct audio_status
- *status</para>
-</entry><entry
- align="char">
-<para>Returns the current state of Audio Device.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="AUDIO_GET_CAPABILITIES"
-role="subsection"><title>AUDIO_GET_CAPABILITIES</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the Audio Device to tell us about the decoding capabilities
- of the audio hardware.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(int fd, int request =
- AUDIO_GET_CAPABILITIES, unsigned int &#x22C6;cap);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_GET_CAPABILITIES for this
- command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>unsigned int *cap</para>
-</entry><entry
- align="char">
-<para>Returns a bit array of supported sound formats.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="AUDIO_CLEAR_BUFFER"
-role="subsection"><title>AUDIO_CLEAR_BUFFER</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the Audio Device to clear all software and hardware buffers
- of the audio decoder device.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(int fd, int request = AUDIO_CLEAR_BUFFER);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_CLEAR_BUFFER for this command.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="AUDIO_SET_ID"
-role="subsection"><title>AUDIO_SET_ID</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl selects which sub-stream is to be decoded if a program or system
- stream is sent to the video device. If no audio stream type is set the id has to be
- in [0xC0,0xDF] for MPEG sound, in [0x80,0x87] for AC3 and in [0xA0,0xA7]
- for LPCM. More specifications may follow for other stream types. If the stream
- type is set the id just specifies the substream id of the audio stream and only
- the first 5 bits are recognized.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(int fd, int request = AUDIO_SET_ID, int
- id);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_SET_ID for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int id</para>
-</entry><entry
- align="char">
-<para>audio sub-stream id</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="AUDIO_SET_MIXER"
-role="subsection"><title>AUDIO_SET_MIXER</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl lets you adjust the mixer settings of the audio decoder.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(int fd, int request = AUDIO_SET_MIXER,
- audio_mixer_t &#x22C6;mix);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_SET_ID for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>audio_mixer_t *mix</para>
-</entry><entry
- align="char">
-<para>mixer settings.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="AUDIO_SET_STREAMTYPE"
-role="subsection"><title>AUDIO_SET_STREAMTYPE</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl tells the driver which kind of audio stream to expect. This is useful
- if the stream offers several audio sub-streams like LPCM and AC3.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(fd, int request = AUDIO_SET_STREAMTYPE,
- int type);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_SET_STREAMTYPE for this
- command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int type</para>
-</entry><entry
- align="char">
-<para>stream type</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EINVAL</para>
-</entry><entry
- align="char">
-<para>type is not a valid or supported stream type.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section><section id="AUDIO_SET_EXT_ID"
-role="subsection"><title>AUDIO_SET_EXT_ID</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl can be used to set the extension id for MPEG streams in DVD
- playback. Only the first 3 bits are recognized.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(fd, int request = AUDIO_SET_EXT_ID, int
- id);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_SET_EXT_ID for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int id</para>
-</entry><entry
- align="char">
-<para>audio sub_stream_id</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EINVAL</para>
-</entry><entry
- align="char">
-<para>id is not a valid id.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section><section id="AUDIO_SET_ATTRIBUTES"
-role="subsection"><title>AUDIO_SET_ATTRIBUTES</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl is intended for DVD playback and allows you to set certain
- information about the audio stream.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(fd, int request = AUDIO_SET_ATTRIBUTES,
- audio_attributes_t attr );</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_SET_ATTRIBUTES for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>audio_attributes_t
- attr</para>
-</entry><entry
- align="char">
-<para>audio attributes according to section ??</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EINVAL</para>
-</entry><entry
- align="char">
-<para>attr is not a valid or supported attribute setting.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section><section id="AUDIO_SET_KARAOKE"
-role="subsection"><title>AUDIO_SET_KARAOKE</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl allows one to set the mixer settings for a karaoke DVD.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(fd, int request = AUDIO_SET_KARAOKE,
- audio_karaoke_t &#x22C6;karaoke);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals AUDIO_SET_KARAOKE for this
- command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>audio_karaoke_t
- *karaoke</para>
-</entry><entry
- align="char">
-<para>karaoke settings according to section ??.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EINVAL</para>
-</entry><entry
- align="char">
-<para>karaoke is not a valid or supported karaoke setting.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
- </section>
-</section>
diff --git a/Documentation/DocBook/media/dvb/av.xml b/Documentation/DocBook/media/dvb/av.xml
new file mode 100644
index 0000000..0a4f443
--- /dev/null
+++ b/Documentation/DocBook/media/dvb/av.xml
@@ -0,0 +1,108 @@
+<title>DVB Audio/Video Devices</title>
+<para>The original DVBv5 API defined audio and video devices to control MPEG2 decoders inside
+DVB hardware. The MPEG2 audio decoder was accessed through
+<emphasis role="tt">/dev/dvb/adapter0/audio0</emphasis> and data types and
+ioctl definitions could be accessed by including <emphasis role="tt">linux/dvb/audio.h</emphasis>.
+The MPEG2 video decoder was accessed through <emphasis role="tt">/dev/dvb/adapter0/video0</emphasis>
+and data types and ioctl definitions could be accessed by including <emphasis role="tt">linux/dvb/video.h</emphasis>.
+</para>
+<para>In practice the only drivers that ever used this API were av7110 and ivtv. During the
+Prague V4L-DVB 2011 workshop it was decided that this functionality didn't belong in the
+DVB API but should be moved to the V4L2 API. So a new V4L2 API for MPEG decoders was created
+for kernel 3.3 and the ivtv driver was converted to use that API. The existing DVB API was
+turned into an av7110-specific API which can be found in <emphasis role="tt">linux/av7110.h</emphasis>.
+</para>
+<para>The old <emphasis role="tt">linux/dvb/audio.h</emphasis>, <emphasis role="tt">linux/dvb/video.h</emphasis>
+and <emphasis role="tt">linux/dvb/osd.h</emphasis> headers were removed.
+</para>
+<para>The following table shows how to map the old DVB ioctls to the new V4L2 ioctls/controls.
+Not all of the old DVB ioctls have a V4L2 counterpart. Please contact the linux-media mailing
+list (&v4l-ml;) should new functionality be required.
+    <table frame="none" pgwide="1" id="av-mapping">
+      <title>DVB audio/video API to V4L2 API mapping</title>
+      <tgroup cols="2">
+	<colspec colname="c1" colwidth="1*" />
+	<colspec colname="c2" colwidth="5*" />
+	<tbody valign="top">
+	  <row>
+	    <entry><constant>AUDIO_SET_MUTE</constant></entry>
+	    <entry>Use the <constant>V4L2_CID_AUDIO_MUTE</constant> control and/or use the
+	    &VIDIOC-DECODER-CMD; ioctl with the <constant>V4L2_DEC_CMD_START</constant> command
+	    together with the <constant>V4L2_DEC_CMD_START_MUTE_AUDIO</constant> flag.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>AUDIO_CHANNEL_SELECT</constant></entry>
+	    <entry>Use the <constant>V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK</constant> control.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>AUDIO_BILINGUAL_CHANNEL_SELECT</constant></entry>
+	    <entry>Use the <constant>V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK</constant> control.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>AUDIO_SELECT_SOURCE</constant></entry>
+	    <entry>Use the media controller to change internal audio routing (<xref linkend="media_controller" />).</entry>
+	  </row>
+	  <row>
+	    <entry><constant>AUDIO_SET_MIXER</constant></entry>
+	    <entry>Use the <constant>V4L2_CID_AUDIO_VOLUME</constant> and <constant>V4L2_CID_AUDIO_BALANCE</constant> controls.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>VIDEO_STOP</constant></entry>
+	    <entry>Use the &VIDIOC-DECODER-CMD; ioctl with the <constant>V4L2_DEC_CMD_STOP</constant> command.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>VIDEO_PLAY</constant></entry>
+	    <entry>Use the &VIDIOC-DECODER-CMD; ioctl with the <constant>V4L2_DEC_CMD_START</constant> command.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>VIDEO_FREEZE</constant></entry>
+	    <entry>Use the &VIDIOC-DECODER-CMD; ioctl with the <constant>V4L2_DEC_CMD_PAUSE</constant> command.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>VIDEO_CONTINUE</constant></entry>
+	    <entry>Use the &VIDIOC-DECODER-CMD; ioctl with the <constant>V4L2_DEC_CMD_RESUME</constant> command.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>VIDEO_FAST_FORWARD</constant></entry>
+	    <entry>Use the &VIDIOC-DECODER-CMD; ioctl with the <constant>V4L2_DEC_CMD_START</constant> command and
+	    set the <structfield>speed</structfield> value to a value &gt; 1000.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>VIDEO_SLOWMOTION</constant></entry>
+	    <entry>Use the &VIDIOC-DECODER-CMD; ioctl with the <constant>V4L2_DEC_CMD_START</constant> command and
+	    set the <structfield>speed</structfield> value to a value &lt; 1000.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>VIDEO_SET_BLANK</constant></entry>
+	    <entry>Use the &VIDIOC-DECODER-CMD; ioctl with the <constant>V4L2_DEC_CMD_STOP</constant> command
+	    together with the <constant>V4L2_DEC_CMD_STOP_TO_BLACK</constant> flag or use the <constant>V4L2_DEC_CMD_PAUSE</constant>
+	    command together with the <constant>V4L2_DEC_CMD_PAUSE_TO_BLACK</constant> flag.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>VIDEO_COMMAND</constant></entry>
+	    <entry>Use the &VIDIOC-DECODER-CMD; ioctl.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>VIDEO_TRY_COMMAND</constant></entry>
+	    <entry>Use the &VIDIOC-TRY-DECODER-CMD; ioctl.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>VIDEO_SELECT_SOURCE</constant></entry>
+	    <entry>Use the media controller to change internal video routing (<xref linkend="media_controller" />).</entry>
+	  </row>
+	  <row>
+	    <entry><constant>VIDEO_GET_EVENT</constant></entry>
+	    <entry>Use the V4L2 event API (<xref linkend="event" />).</entry>
+	  </row>
+	  <row>
+	    <entry><constant>VIDEO_GET_PTS</constant></entry>
+	    <entry>Use the <constant>V4L2_CID_MPEG_STREAM_DEC_PTS</constant> control.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>VIDEO_GET_FRAME_COUNT</constant></entry>
+	    <entry>Use the <constant>V4L2_CID_MPEG_VIDEO_DEC_FRAME</constant> control.</entry>
+	  </row>
+	</tbody>
+      </tgroup>
+    </table>
+</para>
diff --git a/Documentation/DocBook/media/dvb/dvbapi.xml b/Documentation/DocBook/media/dvb/dvbapi.xml
index 2ab6ddc..2baea24 100644
--- a/Documentation/DocBook/media/dvb/dvbapi.xml
+++ b/Documentation/DocBook/media/dvb/dvbapi.xml
@@ -95,11 +95,8 @@ Added ISDB-T test originally written by Patrick Boettcher
   <chapter id="dvb_demux">
     &sub-demux;
   </chapter>
-  <chapter id="dvb_video">
-    &sub-video;
-  </chapter>
-  <chapter id="dvb_audio">
-    &sub-audio;
+  <chapter id="dvb_video_audio">
+    &sub-av;
   </chapter>
   <chapter id="dvb_ca">
     &sub-ca;
@@ -114,10 +111,6 @@ Added ISDB-T test originally written by Patrick Boettcher
     &sub-examples;
   </chapter>
 <!-- END OF CHAPTERS -->
-  <appendix id="audio_h">
-    <title>DVB Audio Header File</title>
-    &sub-audio-h;
-  </appendix>
   <appendix id="ca_h">
     <title>DVB Conditional Access Header File</title>
     &sub-ca-h;
@@ -134,8 +127,3 @@ Added ISDB-T test originally written by Patrick Boettcher
     <title>DVB Network Header File</title>
     &sub-net-h;
   </appendix>
-  <appendix id="video_h">
-    <title>DVB Video Header File</title>
-    &sub-video-h;
-  </appendix>
-
diff --git a/Documentation/DocBook/media/dvb/examples.xml b/Documentation/DocBook/media/dvb/examples.xml
index f037e56..a25af87 100644
--- a/Documentation/DocBook/media/dvb/examples.xml
+++ b/Documentation/DocBook/media/dvb/examples.xml
@@ -238,7 +238,6 @@ necessary.
  #include &#x003C;unistd.h&#x003E;
 
  #include &#x003C;linux/dvb/dmx.h&#x003E;
- #include &#x003C;linux/dvb/video.h&#x003E;
  #include &#x003C;sys/poll.h&#x003E;
  #define DVR "/dev/dvb/adapter0/dvr1"
  #define AUDIO "/dev/dvb/adapter0/audio1"
diff --git a/Documentation/DocBook/media/dvb/intro.xml b/Documentation/DocBook/media/dvb/intro.xml
index 170064a..3cde9a5 100644
--- a/Documentation/DocBook/media/dvb/intro.xml
+++ b/Documentation/DocBook/media/dvb/intro.xml
@@ -180,9 +180,6 @@ The DVB API include files should be included in application sources with
 a partial path like:</para>
 
 <programlisting>
-	#include &#x003C;linux/dvb/audio.h&#x003E;
-</programlisting>
-<programlisting>
 	#include &#x003C;linux/dvb/ca.h&#x003E;
 </programlisting>
 <programlisting>
@@ -194,12 +191,6 @@ a partial path like:</para>
 <programlisting>
 	#include &#x003C;linux/dvb/net.h&#x003E;
 </programlisting>
-<programlisting>
-	#include &#x003C;linux/dvb/osd.h&#x003E;
-</programlisting>
-<programlisting>
-	#include &#x003C;linux/dvb/video.h&#x003E;
-</programlisting>
 
 <para>To enable applications to support different API version, an
 additional include file <emphasis
diff --git a/Documentation/DocBook/media/dvb/video.xml b/Documentation/DocBook/media/dvb/video.xml
deleted file mode 100644
index 25fb823..0000000
--- a/Documentation/DocBook/media/dvb/video.xml
+++ /dev/null
@@ -1,1657 +0,0 @@
-<title>DVB Video Device</title>
-<para>The DVB video device controls the MPEG2 video decoder of the DVB hardware. It
-can be accessed through <emphasis role="tt">/dev/dvb/adapter0/video0</emphasis>. Data types and and
-ioctl definitions can be accessed by including <emphasis role="tt">linux/dvb/video.h</emphasis> in your
-application.
-</para>
-<para>Note that the DVB video device only controls decoding of the MPEG video stream, not
-its presentation on the TV or computer screen. On PCs this is typically handled by an
-associated video4linux device, e.g. <emphasis role="tt">/dev/video</emphasis>, which allows scaling and defining output
-windows.
-</para>
-<para>Some DVB cards don&#8217;t have their own MPEG decoder, which results in the omission of
-the audio and video device as well as the video4linux device.
-</para>
-<para>The ioctls that deal with SPUs (sub picture units) and navigation packets are only
-supported on some MPEG decoders made for DVD playback.
-</para>
-<section id="video_types">
-<title>Video Data Types</title>
-
-<section id="video-format-t">
-<title>video_format_t</title>
-<para>The <emphasis role="tt">video_format_t</emphasis> data type defined by
-</para>
-<programlisting>
-typedef enum {
-	VIDEO_FORMAT_4_3,     /&#x22C6; Select 4:3 format &#x22C6;/
-	VIDEO_FORMAT_16_9,    /&#x22C6; Select 16:9 format. &#x22C6;/
-	VIDEO_FORMAT_221_1    /&#x22C6; 2.21:1 &#x22C6;/
-} video_format_t;
-</programlisting>
-<para>is used in the VIDEO_SET_FORMAT function (??) to tell the driver which aspect ratio
-the output hardware (e.g. TV) has. It is also used in the data structures video_status
-(??) returned by VIDEO_GET_STATUS (??) and video_event (??) returned by
-VIDEO_GET_EVENT (??) which report about the display format of the current video
-stream.
-</para>
-</section>
-
-<section id="video-displayformat-t">
-<title>video_displayformat_t</title>
-<para>In case the display format of the video stream and of the display hardware differ the
-application has to specify how to handle the cropping of the picture. This can be done using
-the VIDEO_SET_DISPLAY_FORMAT call (??) which accepts
-</para>
-<programlisting>
-typedef enum {
-	VIDEO_PAN_SCAN,       /&#x22C6; use pan and scan format &#x22C6;/
-	VIDEO_LETTER_BOX,     /&#x22C6; use letterbox format &#x22C6;/
-	VIDEO_CENTER_CUT_OUT  /&#x22C6; use center cut out format &#x22C6;/
-} video_displayformat_t;
-</programlisting>
-<para>as argument.
-</para>
-</section>
-
-<section id="video-stream-source-t">
-<title>video stream source</title>
-<para>The video stream source is set through the VIDEO_SELECT_SOURCE call and can take
-the following values, depending on whether we are replaying from an internal (demuxer) or
-external (user write) source.
-</para>
-<programlisting>
-typedef enum {
-	VIDEO_SOURCE_DEMUX, /&#x22C6; Select the demux as the main source &#x22C6;/
-	VIDEO_SOURCE_MEMORY /&#x22C6; If this source is selected, the stream
-			       comes from the user through the write
-			       system call &#x22C6;/
-} video_stream_source_t;
-</programlisting>
-<para>VIDEO_SOURCE_DEMUX selects the demultiplexer (fed either by the frontend or the
-DVR device) as the source of the video stream. If VIDEO_SOURCE_MEMORY
-is selected the stream comes from the application through the <emphasis role="tt">write()</emphasis> system
-call.
-</para>
-</section>
-
-<section id="video-play-state-t">
-<title>video play state</title>
-<para>The following values can be returned by the VIDEO_GET_STATUS call representing the
-state of video playback.
-</para>
-<programlisting>
-typedef enum {
-	VIDEO_STOPPED, /&#x22C6; Video is stopped &#x22C6;/
-	VIDEO_PLAYING, /&#x22C6; Video is currently playing &#x22C6;/
-	VIDEO_FREEZED  /&#x22C6; Video is freezed &#x22C6;/
-} video_play_state_t;
-</programlisting>
-</section>
-
-<section id="video-command">
-<para>The structure must be zeroed before use by the application
-This ensures it can be extended safely in the future.</para>
-<title>struct video-command</title>
-<programlisting>
-struct video_command {
-	__u32 cmd;
-	__u32 flags;
-	union {
-		struct {
-			__u64 pts;
-		} stop;
-
-		struct {
-			/&#x22C6; 0 or 1000 specifies normal speed,
-			   1 specifies forward single stepping,
-			   -1 specifies backward single stepping,
-			   &gt;>1: playback at speed/1000 of the normal speed,
-			   &lt;-1: reverse playback at (-speed/1000) of the normal speed. &#x22C6;/
-			__s32 speed;
-			__u32 format;
-		} play;
-
-		struct {
-			__u32 data[16];
-		} raw;
-	};
-};
-</programlisting>
-</section>
-
-<section id="video-size-t">
-<title>struct video_size-t</title>
-<programlisting>
-typedef struct {
-	int w;
-	int h;
-	video_format_t aspect_ratio;
-} video_size_t;
-</programlisting>
-</section>
-
-
-<section id="video-event">
-<title>struct video_event</title>
-<para>The following is the structure of a video event as it is returned by the VIDEO_GET_EVENT
-call.
-</para>
-<programlisting>
-struct video_event {
-	__s32 type;
-#define VIDEO_EVENT_SIZE_CHANGED	1
-#define VIDEO_EVENT_FRAME_RATE_CHANGED	2
-#define VIDEO_EVENT_DECODER_STOPPED 	3
-#define VIDEO_EVENT_VSYNC 		4
-	__kernel_time_t timestamp;
-	union {
-		video_size_t size;
-		unsigned int frame_rate;	/&#x22C6; in frames per 1000sec &#x22C6;/
-		unsigned char vsync_field;	/&#x22C6; unknown/odd/even/progressive &#x22C6;/
-	} u;
-};
-</programlisting>
-</section>
-
-<section id="video-status">
-<title>struct video_status</title>
-<para>The VIDEO_GET_STATUS call returns the following structure informing about various
-states of the playback operation.
-</para>
-<programlisting>
-struct video_status {
-	int                   video_blank;   /&#x22C6; blank video on freeze? &#x22C6;/
-	video_play_state_t    play_state;    /&#x22C6; current state of playback &#x22C6;/
-	video_stream_source_t stream_source; /&#x22C6; current source (demux/memory) &#x22C6;/
-	video_format_t        video_format;  /&#x22C6; current aspect ratio of stream &#x22C6;/
-	video_displayformat_t display_format;/&#x22C6; selected cropping mode &#x22C6;/
-};
-</programlisting>
-<para>If video_blank is set video will be blanked out if the channel is changed or if playback is
-stopped. Otherwise, the last picture will be displayed. play_state indicates if the video is
-currently frozen, stopped, or being played back. The stream_source corresponds to the seleted
-source for the video stream. It can come either from the demultiplexer or from memory.
-The video_format indicates the aspect ratio (one of 4:3 or 16:9) of the currently
-played video stream. Finally, display_format corresponds to the selected cropping
-mode in case the source video format is not the same as the format of the output
-device.
-</para>
-</section>
-
-<section id="video-still-picture">
-<title>struct video_still_picture</title>
-<para>An I-frame displayed via the VIDEO_STILLPICTURE call is passed on within the
-following structure.
-</para>
-<programlisting>
-/&#x22C6; pointer to and size of a single iframe in memory &#x22C6;/
-struct video_still_picture {
-	char &#x22C6;iFrame;        /&#x22C6; pointer to a single iframe in memory &#x22C6;/
-	int32_t size;
-};
-</programlisting>
-</section>
-
-<section id="video_caps">
-<title>video capabilities</title>
-<para>A call to VIDEO_GET_CAPABILITIES returns an unsigned integer with the following
-bits set according to the hardwares capabilities.
-</para>
-<programlisting>
- /&#x22C6; bit definitions for capabilities: &#x22C6;/
- /&#x22C6; can the hardware decode MPEG1 and/or MPEG2? &#x22C6;/
- #define VIDEO_CAP_MPEG1   1
- #define VIDEO_CAP_MPEG2   2
- /&#x22C6; can you send a system and/or program stream to video device?
-    (you still have to open the video and the audio device but only
-     send the stream to the video device) &#x22C6;/
- #define VIDEO_CAP_SYS     4
- #define VIDEO_CAP_PROG    8
- /&#x22C6; can the driver also handle SPU, NAVI and CSS encoded data?
-    (CSS API is not present yet) &#x22C6;/
- #define VIDEO_CAP_SPU    16
- #define VIDEO_CAP_NAVI   32
- #define VIDEO_CAP_CSS    64
-</programlisting>
-</section>
-
-<section id="video-system">
-<title>video system</title>
-<para>A call to VIDEO_SET_SYSTEM sets the desired video system for TV output. The
-following system types can be set:
-</para>
-<programlisting>
-typedef enum {
-	 VIDEO_SYSTEM_PAL,
-	 VIDEO_SYSTEM_NTSC,
-	 VIDEO_SYSTEM_PALN,
-	 VIDEO_SYSTEM_PALNc,
-	 VIDEO_SYSTEM_PALM,
-	 VIDEO_SYSTEM_NTSC60,
-	 VIDEO_SYSTEM_PAL60,
-	 VIDEO_SYSTEM_PALM60
-} video_system_t;
-</programlisting>
-</section>
-
-<section id="video-highlight">
-<title>struct video_highlight</title>
-<para>Calling the ioctl VIDEO_SET_HIGHLIGHTS posts the SPU highlight information. The
-call expects the following format for that information:
-</para>
-<programlisting>
- typedef
- struct video_highlight {
-	 boolean active;      /&#x22C6;    1=show highlight, 0=hide highlight &#x22C6;/
-	 uint8_t contrast1;   /&#x22C6;    7- 4  Pattern pixel contrast &#x22C6;/
-			      /&#x22C6;    3- 0  Background pixel contrast &#x22C6;/
-	 uint8_t contrast2;   /&#x22C6;    7- 4  Emphasis pixel-2 contrast &#x22C6;/
-			      /&#x22C6;    3- 0  Emphasis pixel-1 contrast &#x22C6;/
-	 uint8_t color1;      /&#x22C6;    7- 4  Pattern pixel color &#x22C6;/
-			      /&#x22C6;    3- 0  Background pixel color &#x22C6;/
-	 uint8_t color2;      /&#x22C6;    7- 4  Emphasis pixel-2 color &#x22C6;/
-			      /&#x22C6;    3- 0  Emphasis pixel-1 color &#x22C6;/
-	 uint32_t ypos;       /&#x22C6;   23-22  auto action mode &#x22C6;/
-			      /&#x22C6;   21-12  start y &#x22C6;/
-			      /&#x22C6;    9- 0  end y &#x22C6;/
-	 uint32_t xpos;       /&#x22C6;   23-22  button color number &#x22C6;/
-			      /&#x22C6;   21-12  start x &#x22C6;/
-			      /&#x22C6;    9- 0  end x &#x22C6;/
- } video_highlight_t;
-</programlisting>
-
-</section>
-<section id="video-spu">
-<title>video SPU</title>
-<para>Calling VIDEO_SET_SPU deactivates or activates SPU decoding, according to the
-following format:
-</para>
-<programlisting>
- typedef
- struct video_spu {
-	 boolean active;
-	 int stream_id;
- } video_spu_t;
-</programlisting>
-
-</section>
-<section id="video-spu-palette">
-<title>video SPU palette</title>
-<para>The following structure is used to set the SPU palette by calling VIDEO_SPU_PALETTE:
-</para>
-<programlisting>
- typedef
- struct video_spu_palette{
-	 int length;
-	 uint8_t &#x22C6;palette;
- } video_spu_palette_t;
-</programlisting>
-
-</section>
-<section id="video-navi-pack">
-<title>video NAVI pack</title>
-<para>In order to get the navigational data the following structure has to be passed to the ioctl
-VIDEO_GET_NAVI:
-</para>
-<programlisting>
- typedef
- struct video_navi_pack{
-	 int length;         /&#x22C6; 0 ... 1024 &#x22C6;/
-	 uint8_t data[1024];
- } video_navi_pack_t;
-</programlisting>
-</section>
-
-
-<section id="video-attributes-t">
-<title>video attributes</title>
-<para>The following attributes can be set by a call to VIDEO_SET_ATTRIBUTES:
-</para>
-<programlisting>
- typedef uint16_t video_attributes_t;
- /&#x22C6;   bits: descr. &#x22C6;/
- /&#x22C6;   15-14 Video compression mode (0=MPEG-1, 1=MPEG-2) &#x22C6;/
- /&#x22C6;   13-12 TV system (0=525/60, 1=625/50) &#x22C6;/
- /&#x22C6;   11-10 Aspect ratio (0=4:3, 3=16:9) &#x22C6;/
- /&#x22C6;    9- 8 permitted display mode on 4:3 monitor (0=both, 1=only pan-sca &#x22C6;/
- /&#x22C6;    7    line 21-1 data present in GOP (1=yes, 0=no) &#x22C6;/
- /&#x22C6;    6    line 21-2 data present in GOP (1=yes, 0=no) &#x22C6;/
- /&#x22C6;    5- 3 source resolution (0=720x480/576, 1=704x480/576, 2=352x480/57 &#x22C6;/
- /&#x22C6;    2    source letterboxed (1=yes, 0=no) &#x22C6;/
- /&#x22C6;    0    film/camera mode (0=camera, 1=film (625/50 only)) &#x22C6;/
-</programlisting>
-</section></section>
-
-
-<section id="video_function_calls">
-<title>Video Function Calls</title>
-
-
-<section id="video_fopen">
-<title>open()</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This system call opens a named video device (e.g. /dev/dvb/adapter0/video0)
- for subsequent use.</para>
-<para>When an open() call has succeeded, the device will be ready for use.
- The significance of blocking or non-blocking mode is described in the
- documentation for functions where there is a difference. It does not affect the
- semantics of the open() call itself. A device opened in blocking mode can later
- be put into non-blocking mode (and vice versa) using the F_SETFL command
- of the fcntl system call. This is a standard system call, documented in the Linux
- manual page for fcntl. Only one user can open the Video Device in O_RDWR
- mode. All other attempts to open the device in this mode will fail, and an
- error-code will be returned. If the Video Device is opened in O_RDONLY
- mode, the only ioctl call that can be used is VIDEO_GET_STATUS. All other
- call will return an error code.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int open(const char &#x22C6;deviceName, int flags);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>const char
- *deviceName</para>
-</entry><entry
- align="char">
-<para>Name of specific video device.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int flags</para>
-</entry><entry
- align="char">
-<para>A bit-wise OR of the following flags:</para>
-</entry>
- </row><row><entry
- align="char">
-</entry><entry
- align="char">
-<para>O_RDONLY read-only access</para>
-</entry>
- </row><row><entry
- align="char">
-</entry><entry
- align="char">
-<para>O_RDWR read/write access</para>
-</entry>
- </row><row><entry
- align="char">
-</entry><entry
- align="char">
-<para>O_NONBLOCK open in non-blocking mode</para>
-</entry>
- </row><row><entry
- align="char">
-</entry><entry
- align="char">
-<para>(blocking mode is the default)</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>RETURN VALUE</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>ENODEV</para>
-</entry><entry
- align="char">
-<para>Device driver not loaded/available.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>EINTERNAL</para>
-</entry><entry
- align="char">
-<para>Internal error.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>EBUSY</para>
-</entry><entry
- align="char">
-<para>Device or resource busy.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>EINVAL</para>
-</entry><entry
- align="char">
-<para>Invalid argument.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section>
-<section id="video_fclose">
-<title>close()</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This system call closes a previously opened video device.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int close(int fd);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>RETURN VALUE</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EBADF</para>
-</entry><entry
- align="char">
-<para>fd is not a valid open file descriptor.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section>
-<section id="video_fwrite">
-<title>write()</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This system call can only be used if VIDEO_SOURCE_MEMORY is selected
- in the ioctl call VIDEO_SELECT_SOURCE. The data provided shall be in
- PES format, unless the capability allows other formats. If O_NONBLOCK is
- not specified the function will block until buffer space is available. The amount
- of data to be transferred is implied by count.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>size_t write(int fd, const void &#x22C6;buf, size_t count);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>void *buf</para>
-</entry><entry
- align="char">
-<para>Pointer to the buffer containing the PES data.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>size_t count</para>
-</entry><entry
- align="char">
-<para>Size of buf.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>RETURN VALUE</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EPERM</para>
-</entry><entry
- align="char">
-<para>Mode VIDEO_SOURCE_MEMORY not selected.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>ENOMEM</para>
-</entry><entry
- align="char">
-<para>Attempted to write more data than the internal buffer can
- hold.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>EBADF</para>
-</entry><entry
- align="char">
-<para>fd is not a valid open file descriptor.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section><section id="VIDEO_STOP"
-role="subsection"><title>VIDEO_STOP</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the Video Device to stop playing the current stream.
- Depending on the input parameter, the screen can be blanked out or displaying
- the last decoded frame.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(fd, int request = VIDEO_STOP, boolean
- mode);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_STOP for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>Boolean mode</para>
-</entry><entry
- align="char">
-<para>Indicates how the screen shall be handled.</para>
-</entry>
- </row><row><entry
- align="char">
-</entry><entry
- align="char">
-<para>TRUE: Blank screen when stop.</para>
-</entry>
- </row><row><entry
- align="char">
-</entry><entry
- align="char">
-<para>FALSE: Show last decoded frame.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="VIDEO_PLAY"
-role="subsection"><title>VIDEO_PLAY</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the Video Device to start playing a video stream from the
- selected source.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(fd, int request = VIDEO_PLAY);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_PLAY for this command.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="VIDEO_FREEZE"
-role="subsection"><title>VIDEO_FREEZE</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call suspends the live video stream being played. Decoding
- and playing are frozen. It is then possible to restart the decoding
- and playing process of the video stream using the VIDEO_CONTINUE
- command. If VIDEO_SOURCE_MEMORY is selected in the ioctl call
- VIDEO_SELECT_SOURCE, the DVB subsystem will not decode any more
- data until the ioctl call VIDEO_CONTINUE or VIDEO_PLAY is performed.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(fd, int request = VIDEO_FREEZE);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_FREEZE for this command.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="VIDEO_CONTINUE"
-role="subsection"><title>VIDEO_CONTINUE</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call restarts decoding and playing processes of the video stream
- which was played before a call to VIDEO_FREEZE was made.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(fd, int request = VIDEO_CONTINUE);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_CONTINUE for this command.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="VIDEO_SELECT_SOURCE"
-role="subsection"><title>VIDEO_SELECT_SOURCE</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call informs the video device which source shall be used for the input
- data. The possible sources are demux or memory. If memory is selected, the
- data is fed to the video device through the write command.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(fd, int request = VIDEO_SELECT_SOURCE,
- video_stream_source_t source);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_SELECT_SOURCE for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>video_stream_source_t
- source</para>
-</entry><entry
- align="char">
-<para>Indicates which source shall be used for the Video stream.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="VIDEO_SET_BLANK"
-role="subsection"><title>VIDEO_SET_BLANK</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the Video Device to blank out the picture.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(fd, int request = VIDEO_SET_BLANK, boolean
- mode);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_SET_BLANK for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>boolean mode</para>
-</entry><entry
- align="char">
-<para>TRUE: Blank screen when stop.</para>
-</entry>
- </row><row><entry
- align="char">
-</entry><entry
- align="char">
-<para>FALSE: Show last decoded frame.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="VIDEO_GET_STATUS"
-role="subsection"><title>VIDEO_GET_STATUS</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the Video Device to return the current status of the device.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para> int ioctl(fd, int request = VIDEO_GET_STATUS, struct
- video_status &#x22C6;status);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_GET_STATUS for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>struct video_status
- *status</para>
-</entry><entry
- align="char">
-<para>Returns the current status of the Video Device.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="VIDEO_GET_EVENT"
-role="subsection"><title>VIDEO_GET_EVENT</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call returns an event of type video_event if available. If an event is
- not available, the behavior depends on whether the device is in blocking or
- non-blocking mode. In the latter case, the call fails immediately with errno
- set to EWOULDBLOCK. In the former case, the call blocks until an event
- becomes available. The standard Linux poll() and/or select() system calls can
- be used with the device file descriptor to watch for new events. For select(),
- the file descriptor should be included in the exceptfds argument, and for
- poll(), POLLPRI should be specified as the wake-up condition. Read-only
- permissions are sufficient for this ioctl call.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para> int ioctl(fd, int request = VIDEO_GET_EVENT, struct
- video_event &#x22C6;ev);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_GET_EVENT for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>struct video_event
- *ev</para>
-</entry><entry
- align="char">
-<para>Points to the location where the event, if any, is to be
- stored.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EWOULDBLOCK</para>
-</entry><entry
- align="char">
-<para>There is no event pending, and the device is in
- non-blocking mode.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>EOVERFLOW</para>
-</entry><entry
- align="char">
-<para>Overflow in event queue - one or more events were lost.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section><section id="VIDEO_SET_DISPLAY_FORMAT"
-role="subsection"><title>VIDEO_SET_DISPLAY_FORMAT</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the Video Device to select the video format to be applied
- by the MPEG chip on the video.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para> int ioctl(fd, int request =
- VIDEO_SET_DISPLAY_FORMAT, video_display_format_t
- format);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_SET_DISPLAY_FORMAT for this
- command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>video_display_format_t
- format</para>
-</entry><entry
- align="char">
-<para>Selects the video format to be used.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="VIDEO_STILLPICTURE"
-role="subsection"><title>VIDEO_STILLPICTURE</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the Video Device to display a still picture (I-frame). The
- input data shall contain an I-frame. If the pointer is NULL, then the current
- displayed still picture is blanked.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(fd, int request = VIDEO_STILLPICTURE,
- struct video_still_picture &#x22C6;sp);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_STILLPICTURE for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>struct
- video_still_picture
- *sp</para>
-</entry><entry
- align="char">
-<para>Pointer to a location where an I-frame and size is stored.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="VIDEO_FAST_FORWARD"
-role="subsection"><title>VIDEO_FAST_FORWARD</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the Video Device to skip decoding of N number of I-frames.
- This call can only be used if VIDEO_SOURCE_MEMORY is selected.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(fd, int request = VIDEO_FAST_FORWARD, int
- nFrames);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_FAST_FORWARD for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int nFrames</para>
-</entry><entry
- align="char">
-<para>The number of frames to skip.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EPERM</para>
-</entry><entry
- align="char">
-<para>Mode VIDEO_SOURCE_MEMORY not selected.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section><section id="VIDEO_SLOWMOTION"
-role="subsection"><title>VIDEO_SLOWMOTION</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the video device to repeat decoding frames N number of
- times. This call can only be used if VIDEO_SOURCE_MEMORY is selected.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(fd, int request = VIDEO_SLOWMOTION, int
- nFrames);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_SLOWMOTION for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int nFrames</para>
-</entry><entry
- align="char">
-<para>The number of times to repeat each frame.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EPERM</para>
-</entry><entry
- align="char">
-<para>Mode VIDEO_SOURCE_MEMORY not selected.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section><section id="VIDEO_GET_CAPABILITIES"
-role="subsection"><title>VIDEO_GET_CAPABILITIES</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call asks the video device about its decoding capabilities. On success
- it returns and integer which has bits set according to the defines in section ??.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(fd, int request = VIDEO_GET_CAPABILITIES,
- unsigned int &#x22C6;cap);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_GET_CAPABILITIES for this
- command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>unsigned int *cap</para>
-</entry><entry
- align="char">
-<para>Pointer to a location where to store the capability
- information.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="VIDEO_SET_ID"
-role="subsection"><title>VIDEO_SET_ID</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl selects which sub-stream is to be decoded if a program or system
- stream is sent to the video device.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(int fd, int request = VIDEO_SET_ID, int
- id);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_SET_ID for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int id</para>
-</entry><entry
- align="char">
-<para>video sub-stream id</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EINVAL</para>
-</entry><entry
- align="char">
-<para>Invalid sub-stream id.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section><section id="VIDEO_CLEAR_BUFFER"
-role="subsection"><title>VIDEO_CLEAR_BUFFER</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl call clears all video buffers in the driver and in the decoder hardware.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(fd, int request = VIDEO_CLEAR_BUFFER);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_CLEAR_BUFFER for this command.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="VIDEO_SET_STREAMTYPE"
-role="subsection"><title>VIDEO_SET_STREAMTYPE</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl tells the driver which kind of stream to expect being written to it. If
- this call is not used the default of video PES is used. Some drivers might not
- support this call and always expect PES.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>int ioctl(fd, int request = VIDEO_SET_STREAMTYPE,
- int type);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_SET_STREAMTYPE for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int type</para>
-</entry><entry
- align="char">
-<para>stream type</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="VIDEO_SET_FORMAT"
-role="subsection"><title>VIDEO_SET_FORMAT</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl sets the screen format (aspect ratio) of the connected output device
- (TV) so that the output of the decoder can be adjusted accordingly.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para> int ioctl(fd, int request = VIDEO_SET_FORMAT,
- video_format_t format);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_SET_FORMAT for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>video_format_t
- format</para>
-</entry><entry
- align="char">
-<para>video format of TV as defined in section ??.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EINVAL</para>
-</entry><entry
- align="char">
-<para>format is not a valid video format.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section><section id="VIDEO_SET_SYSTEM"
-role="subsection"><title>VIDEO_SET_SYSTEM</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl sets the television output format. The format (see section ??) may
- vary from the color format of the displayed MPEG stream. If the hardware is
- not able to display the requested format the call will return an error.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para> int ioctl(fd, int request = VIDEO_SET_SYSTEM ,
- video_system_t system);</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_SET_FORMAT for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>video_system_t
- system</para>
-</entry><entry
- align="char">
-<para>video system of TV output.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EINVAL</para>
-</entry><entry
- align="char">
-<para>system is not a valid or supported video system.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section><section id="VIDEO_SET_HIGHLIGHT"
-role="subsection"><title>VIDEO_SET_HIGHLIGHT</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl sets the SPU highlight information for the menu access of a DVD.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para> int ioctl(fd, int request = VIDEO_SET_HIGHLIGHT
- ,video_highlight_t &#x22C6;vhilite)</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_SET_HIGHLIGHT for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>video_highlight_t
- *vhilite</para>
-</entry><entry
- align="char">
-<para>SPU Highlight information according to section ??.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-
-</section><section id="VIDEO_SET_SPU"
-role="subsection"><title>VIDEO_SET_SPU</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl activates or deactivates SPU decoding in a DVD input stream. It can
- only be used, if the driver is able to handle a DVD stream.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para> int ioctl(fd, int request = VIDEO_SET_SPU ,
- video_spu_t &#x22C6;spu)</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_SET_SPU for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>video_spu_t *spu</para>
-</entry><entry
- align="char">
-<para>SPU decoding (de)activation and subid setting according
- to section ??.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EINVAL</para>
-</entry><entry
- align="char">
-<para>input is not a valid spu setting or driver cannot handle
- SPU.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section><section id="VIDEO_SET_SPU_PALETTE"
-role="subsection"><title>VIDEO_SET_SPU_PALETTE</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl sets the SPU color palette.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para> int ioctl(fd, int request = VIDEO_SET_SPU_PALETTE
- ,video_spu_palette_t &#x22C6;palette )</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_SET_SPU_PALETTE for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>video_spu_palette_t
- *palette</para>
-</entry><entry
- align="char">
-<para>SPU palette according to section ??.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EINVAL</para>
-</entry><entry
- align="char">
-<para>input is not a valid palette or driver doesn&#8217;t handle SPU.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section><section id="VIDEO_GET_NAVI"
-role="subsection"><title>VIDEO_GET_NAVI</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl returns navigational information from the DVD stream. This is
- especially needed if an encoded stream has to be decoded by the hardware.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para> int ioctl(fd, int request = VIDEO_GET_NAVI ,
- video_navi_pack_t &#x22C6;navipack)</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_GET_NAVI for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>video_navi_pack_t
- *navipack</para>
-</entry><entry
- align="char">
-<para>PCI or DSI pack (private stream 2) according to section
- ??.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EFAULT</para>
-</entry><entry
- align="char">
-<para>driver is not able to return navigational information</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-
-</section><section id="VIDEO_SET_ATTRIBUTES"
-role="subsection"><title>VIDEO_SET_ATTRIBUTES</title>
-<para>DESCRIPTION
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para>This ioctl is intended for DVD playback and allows you to set certain
- information about the stream. Some hardware may not need this information,
- but the call also tells the hardware to prepare for DVD playback.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>SYNOPSIS
-</para>
-<informaltable><tgroup cols="1"><tbody><row><entry
- align="char">
-<para> int ioctl(fd, int request = VIDEO_SET_ATTRIBUTE
- ,video_attributes_t vattr)</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-<para>PARAMETERS
-</para>
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>int fd</para>
-</entry><entry
- align="char">
-<para>File descriptor returned by a previous call to open().</para>
-</entry>
- </row><row><entry
- align="char">
-<para>int request</para>
-</entry><entry
- align="char">
-<para>Equals VIDEO_SET_ATTRIBUTE for this command.</para>
-</entry>
- </row><row><entry
- align="char">
-<para>video_attributes_t
- vattr</para>
-</entry><entry
- align="char">
-<para>video attributes according to section ??.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
-&return-value-dvb;
-<informaltable><tgroup cols="2"><tbody><row><entry
- align="char">
-<para>EINVAL</para>
-</entry><entry
- align="char">
-<para>input is not a valid attribute setting.</para>
-</entry>
- </row></tbody></tgroup></informaltable>
- </section></section>
-- 
1.7.7.3

[RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 fs/compat_ioctl.c         |   41 +-------
 include/linux/dvb/Kbuild  |    3 -
 include/linux/dvb/audio.h |  135 ----------------------
 include/linux/dvb/osd.h   |  144 -----------------------
 include/linux/dvb/video.h |  276 ---------------------------------------------
 5 files changed, 1 insertions(+), 598 deletions(-)
 delete mode 100644 include/linux/dvb/audio.h
 delete mode 100644 include/linux/dvb/osd.h
 delete mode 100644 include/linux/dvb/video.h

diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 51352de..71adea1 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -105,10 +105,9 @@
 
 #include <linux/hiddev.h>
 
-#include <linux/dvb/audio.h>
+#include <linux/av7110.h>
 #include <linux/dvb/dmx.h>
 #include <linux/dvb/frontend.h>
-#include <linux/dvb/video.h>
 
 #include <linux/sort.h>
 
@@ -196,32 +195,6 @@ static int do_video_stillpicture(unsigned int fd, unsigned int cmd,
 	return err;
 }
 
-struct compat_video_spu_palette {
-	int length;
-	compat_uptr_t palette;
-};
-
-static int do_video_set_spu_palette(unsigned int fd, unsigned int cmd,
-		struct compat_video_spu_palette __user *up)
-{
-	struct video_spu_palette __user *up_native;
-	compat_uptr_t palp;
-	int length, err;
-
-	err  = get_user(palp, &up->palette);
-	err |= get_user(length, &up->length);
-
-	up_native = compat_alloc_user_space(sizeof(struct video_spu_palette));
-	err  = put_user(compat_ptr(palp), &up_native->palette);
-	err |= put_user(length, &up_native->length);
-	if (err)
-		return -EFAULT;
-
-	err = sys_ioctl(fd, cmd, (unsigned long) up_native);
-
-	return err;
-}
-
 #ifdef CONFIG_BLOCK
 typedef struct sg_io_hdr32 {
 	compat_int_t interface_id;	/* [i] 'S' for SCSI generic (required) */
@@ -1317,9 +1290,6 @@ COMPATIBLE_IOCTL(AUDIO_CLEAR_BUFFER)
 COMPATIBLE_IOCTL(AUDIO_SET_ID)
 COMPATIBLE_IOCTL(AUDIO_SET_MIXER)
 COMPATIBLE_IOCTL(AUDIO_SET_STREAMTYPE)
-COMPATIBLE_IOCTL(AUDIO_SET_EXT_ID)
-COMPATIBLE_IOCTL(AUDIO_SET_ATTRIBUTES)
-COMPATIBLE_IOCTL(AUDIO_SET_KARAOKE)
 COMPATIBLE_IOCTL(DMX_START)
 COMPATIBLE_IOCTL(DMX_STOP)
 COMPATIBLE_IOCTL(DMX_SET_FILTER)
@@ -1358,16 +1328,9 @@ COMPATIBLE_IOCTL(VIDEO_FAST_FORWARD)
 COMPATIBLE_IOCTL(VIDEO_SLOWMOTION)
 COMPATIBLE_IOCTL(VIDEO_GET_CAPABILITIES)
 COMPATIBLE_IOCTL(VIDEO_CLEAR_BUFFER)
-COMPATIBLE_IOCTL(VIDEO_SET_ID)
 COMPATIBLE_IOCTL(VIDEO_SET_STREAMTYPE)
 COMPATIBLE_IOCTL(VIDEO_SET_FORMAT)
-COMPATIBLE_IOCTL(VIDEO_SET_SYSTEM)
-COMPATIBLE_IOCTL(VIDEO_SET_HIGHLIGHT)
-COMPATIBLE_IOCTL(VIDEO_SET_SPU)
-COMPATIBLE_IOCTL(VIDEO_GET_NAVI)
-COMPATIBLE_IOCTL(VIDEO_SET_ATTRIBUTES)
 COMPATIBLE_IOCTL(VIDEO_GET_SIZE)
-COMPATIBLE_IOCTL(VIDEO_GET_FRAME_RATE)
 
 /* joystick */
 COMPATIBLE_IOCTL(JSIOCGVERSION)
@@ -1468,8 +1431,6 @@ static long do_ioctl_trans(int fd, unsigned int cmd,
 		return do_video_get_event(fd, cmd, argp);
 	case VIDEO_STILLPICTURE:
 		return do_video_stillpicture(fd, cmd, argp);
-	case VIDEO_SET_SPU_PALETTE:
-		return do_video_set_spu_palette(fd, cmd, argp);
 	}
 
 	/*
diff --git a/include/linux/dvb/Kbuild b/include/linux/dvb/Kbuild
index f4dba86..f5aa137 100644
--- a/include/linux/dvb/Kbuild
+++ b/include/linux/dvb/Kbuild
@@ -1,8 +1,5 @@
-header-y += audio.h
 header-y += ca.h
 header-y += dmx.h
 header-y += frontend.h
 header-y += net.h
-header-y += osd.h
 header-y += version.h
-header-y += video.h
diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h
deleted file mode 100644
index d47bccd..0000000
--- a/include/linux/dvb/audio.h
+++ /dev/null
@@ -1,135 +0,0 @@
-/*
- * audio.h
- *
- * Copyright (C) 2000 Ralph  Metzler <ralph@convergence.de>
- *                  & Marcus Metzler <marcus@convergence.de>
- *                    for convergence integrated media GmbH
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Lesser Public License
- * as published by the Free Software Foundation; either version 2.1
- * of the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
- *
- */
-
-#ifndef _DVBAUDIO_H_
-#define _DVBAUDIO_H_
-
-#include <linux/types.h>
-
-typedef enum {
-	AUDIO_SOURCE_DEMUX, /* Select the demux as the main source */
-	AUDIO_SOURCE_MEMORY /* Select internal memory as the main source */
-} audio_stream_source_t;
-
-
-typedef enum {
-	AUDIO_STOPPED,      /* Device is stopped */
-	AUDIO_PLAYING,      /* Device is currently playing */
-	AUDIO_PAUSED        /* Device is paused */
-} audio_play_state_t;
-
-
-typedef enum {
-	AUDIO_STEREO,
-	AUDIO_MONO_LEFT,
-	AUDIO_MONO_RIGHT,
-	AUDIO_MONO,
-	AUDIO_STEREO_SWAPPED
-} audio_channel_select_t;
-
-
-typedef struct audio_mixer {
-	unsigned int volume_left;
-	unsigned int volume_right;
-  // what else do we need? bass, pass-through, ...
-} audio_mixer_t;
-
-
-typedef struct audio_status {
-	int                    AV_sync_state;  /* sync audio and video? */
-	int                    mute_state;     /* audio is muted */
-	audio_play_state_t     play_state;     /* current playback state */
-	audio_stream_source_t  stream_source;  /* current stream source */
-	audio_channel_select_t channel_select; /* currently selected channel */
-	int                    bypass_mode;    /* pass on audio data to */
-	audio_mixer_t	       mixer_state;    /* current mixer state */
-} audio_status_t;                              /* separate decoder hardware */
-
-
-typedef
-struct audio_karaoke {  /* if Vocal1 or Vocal2 are non-zero, they get mixed  */
-	int vocal1;    /* into left and right t at 70% each */
-	int vocal2;    /* if both, Vocal1 and Vocal2 are non-zero, Vocal1 gets*/
-	int melody;    /* mixed into the left channel and */
-		       /* Vocal2 into the right channel at 100% each. */
-		       /* if Melody is non-zero, the melody channel gets mixed*/
-} audio_karaoke_t;     /* into left and right  */
-
-
-typedef __u16 audio_attributes_t;
-/*   bits: descr. */
-/*   15-13 audio coding mode (0=ac3, 2=mpeg1, 3=mpeg2ext, 4=LPCM, 6=DTS, */
-/*   12    multichannel extension */
-/*   11-10 audio type (0=not spec, 1=language included) */
-/*    9- 8 audio application mode (0=not spec, 1=karaoke, 2=surround) */
-/*    7- 6 Quantization / DRC (mpeg audio: 1=DRC exists)(lpcm: 0=16bit,  */
-/*    5- 4 Sample frequency fs (0=48kHz, 1=96kHz) */
-/*    2- 0 number of audio channels (n+1 channels) */
-
-
-/* for GET_CAPABILITIES and SET_FORMAT, the latter should only set one bit */
-#define AUDIO_CAP_DTS    1
-#define AUDIO_CAP_LPCM   2
-#define AUDIO_CAP_MP1    4
-#define AUDIO_CAP_MP2    8
-#define AUDIO_CAP_MP3   16
-#define AUDIO_CAP_AAC   32
-#define AUDIO_CAP_OGG   64
-#define AUDIO_CAP_SDDS 128
-#define AUDIO_CAP_AC3  256
-
-#define AUDIO_STOP                 _IO('o', 1)
-#define AUDIO_PLAY                 _IO('o', 2)
-#define AUDIO_PAUSE                _IO('o', 3)
-#define AUDIO_CONTINUE             _IO('o', 4)
-#define AUDIO_SELECT_SOURCE        _IO('o', 5)
-#define AUDIO_SET_MUTE             _IO('o', 6)
-#define AUDIO_SET_AV_SYNC          _IO('o', 7)
-#define AUDIO_SET_BYPASS_MODE      _IO('o', 8)
-#define AUDIO_CHANNEL_SELECT       _IO('o', 9)
-#define AUDIO_GET_STATUS           _IOR('o', 10, audio_status_t)
-
-#define AUDIO_GET_CAPABILITIES     _IOR('o', 11, unsigned int)
-#define AUDIO_CLEAR_BUFFER         _IO('o',  12)
-#define AUDIO_SET_ID               _IO('o', 13)
-#define AUDIO_SET_MIXER            _IOW('o', 14, audio_mixer_t)
-#define AUDIO_SET_STREAMTYPE       _IO('o', 15)
-#define AUDIO_SET_EXT_ID           _IO('o', 16)
-#define AUDIO_SET_ATTRIBUTES       _IOW('o', 17, audio_attributes_t)
-#define AUDIO_SET_KARAOKE          _IOW('o', 18, audio_karaoke_t)
-
-/**
- * AUDIO_GET_PTS
- *
- * Read the 33 bit presentation time stamp as defined
- * in ITU T-REC-H.222.0 / ISO/IEC 13818-1.
- *
- * The PTS should belong to the currently played
- * frame if possible, but may also be a value close to it
- * like the PTS of the last decoded frame or the last PTS
- * extracted by the PES parser.
- */
-#define AUDIO_GET_PTS              _IOR('o', 19, __u64)
-#define AUDIO_BILINGUAL_CHANNEL_SELECT _IO('o', 20)
-
-#endif /* _DVBAUDIO_H_ */
diff --git a/include/linux/dvb/osd.h b/include/linux/dvb/osd.h
deleted file mode 100644
index 880e684..0000000
--- a/include/linux/dvb/osd.h
+++ /dev/null
@@ -1,144 +0,0 @@
-/*
- * osd.h
- *
- * Copyright (C) 2001 Ralph  Metzler <ralph@convergence.de>
- *                  & Marcus Metzler <marcus@convergence.de>
- *                    for convergence integrated media GmbH
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Lesser Public License
- * as published by the Free Software Foundation; either version 2.1
- * of the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
- *
- */
-
-#ifndef _DVBOSD_H_
-#define _DVBOSD_H_
-
-#include <linux/compiler.h>
-
-typedef enum {
-  // All functions return -2 on "not open"
-  OSD_Close=1,    // ()
-  // Disables OSD and releases the buffers
-  // returns 0 on success
-  OSD_Open,       // (x0,y0,x1,y1,BitPerPixel[2/4/8](color&0x0F),mix[0..15](color&0xF0))
-  // Opens OSD with this size and bit depth
-  // returns 0 on success, -1 on DRAM allocation error, -2 on "already open"
-  OSD_Show,       // ()
-  // enables OSD mode
-  // returns 0 on success
-  OSD_Hide,       // ()
-  // disables OSD mode
-  // returns 0 on success
-  OSD_Clear,      // ()
-  // Sets all pixel to color 0
-  // returns 0 on success
-  OSD_Fill,       // (color)
-  // Sets all pixel to color <col>
-  // returns 0 on success
-  OSD_SetColor,   // (color,R{x0},G{y0},B{x1},opacity{y1})
-  // set palette entry <num> to <r,g,b>, <mix> and <trans> apply
-  // R,G,B: 0..255
-  // R=Red, G=Green, B=Blue
-  // opacity=0:      pixel opacity 0% (only video pixel shows)
-  // opacity=1..254: pixel opacity as specified in header
-  // opacity=255:    pixel opacity 100% (only OSD pixel shows)
-  // returns 0 on success, -1 on error
-  OSD_SetPalette, // (firstcolor{color},lastcolor{x0},data)
-  // Set a number of entries in the palette
-  // sets the entries "firstcolor" through "lastcolor" from the array "data"
-  // data has 4 byte for each color:
-  // R,G,B, and a opacity value: 0->transparent, 1..254->mix, 255->pixel
-  OSD_SetTrans,   // (transparency{color})
-  // Sets transparency of mixed pixel (0..15)
-  // returns 0 on success
-  OSD_SetPixel,   // (x0,y0,color)
-  // sets pixel <x>,<y> to color number <col>
-  // returns 0 on success, -1 on error
-  OSD_GetPixel,   // (x0,y0)
-  // returns color number of pixel <x>,<y>,  or -1
-  OSD_SetRow,     // (x0,y0,x1,data)
-  // fills pixels x0,y through  x1,y with the content of data[]
-  // returns 0 on success, -1 on clipping all pixel (no pixel drawn)
-  OSD_SetBlock,   // (x0,y0,x1,y1,increment{color},data)
-  // fills pixels x0,y0 through  x1,y1 with the content of data[]
-  // inc contains the width of one line in the data block,
-  // inc<=0 uses blockwidth as linewidth
-  // returns 0 on success, -1 on clipping all pixel
-  OSD_FillRow,    // (x0,y0,x1,color)
-  // fills pixels x0,y through  x1,y with the color <col>
-  // returns 0 on success, -1 on clipping all pixel
-  OSD_FillBlock,  // (x0,y0,x1,y1,color)
-  // fills pixels x0,y0 through  x1,y1 with the color <col>
-  // returns 0 on success, -1 on clipping all pixel
-  OSD_Line,       // (x0,y0,x1,y1,color)
-  // draw a line from x0,y0 to x1,y1 with the color <col>
-  // returns 0 on success
-  OSD_Query,      // (x0,y0,x1,y1,xasp{color}}), yasp=11
-  // fills parameters with the picture dimensions and the pixel aspect ratio
-  // returns 0 on success
-  OSD_Test,       // ()
-  // draws a test picture. for debugging purposes only
-  // returns 0 on success
-// TODO: remove "test" in final version
-  OSD_Text,       // (x0,y0,size,color,text)
-  OSD_SetWindow, //  (x0) set window with number 0<x0<8 as current
-  OSD_MoveWindow, //  move current window to (x0, y0)
-  OSD_OpenRaw,	// Open other types of OSD windows
-} OSD_Command;
-
-typedef struct osd_cmd_s {
-	OSD_Command cmd;
-	int x0;
-	int y0;
-	int x1;
-	int y1;
-	int color;
-	void __user *data;
-} osd_cmd_t;
-
-/* OSD_OpenRaw: set 'color' to desired window type */
-typedef enum {
-	OSD_BITMAP1,           /* 1 bit bitmap */
-	OSD_BITMAP2,           /* 2 bit bitmap */
-	OSD_BITMAP4,           /* 4 bit bitmap */
-	OSD_BITMAP8,           /* 8 bit bitmap */
-	OSD_BITMAP1HR,         /* 1 Bit bitmap half resolution */
-	OSD_BITMAP2HR,         /* 2 bit bitmap half resolution */
-	OSD_BITMAP4HR,         /* 4 bit bitmap half resolution */
-	OSD_BITMAP8HR,         /* 8 bit bitmap half resolution */
-	OSD_YCRCB422,          /* 4:2:2 YCRCB Graphic Display */
-	OSD_YCRCB444,          /* 4:4:4 YCRCB Graphic Display */
-	OSD_YCRCB444HR,        /* 4:4:4 YCRCB graphic half resolution */
-	OSD_VIDEOTSIZE,        /* True Size Normal MPEG Video Display */
-	OSD_VIDEOHSIZE,        /* MPEG Video Display Half Resolution */
-	OSD_VIDEOQSIZE,        /* MPEG Video Display Quarter Resolution */
-	OSD_VIDEODSIZE,        /* MPEG Video Display Double Resolution */
-	OSD_VIDEOTHSIZE,       /* True Size MPEG Video Display Half Resolution */
-	OSD_VIDEOTQSIZE,       /* True Size MPEG Video Display Quarter Resolution*/
-	OSD_VIDEOTDSIZE,       /* True Size MPEG Video Display Double Resolution */
-	OSD_VIDEONSIZE,        /* Full Size MPEG Video Display */
-	OSD_CURSOR             /* Cursor */
-} osd_raw_window_t;
-
-typedef struct osd_cap_s {
-	int  cmd;
-#define OSD_CAP_MEMSIZE         1  /* memory size */
-	long val;
-} osd_cap_t;
-
-
-#define OSD_SEND_CMD            _IOW('o', 160, osd_cmd_t)
-#define OSD_GET_CAPABILITY      _IOR('o', 161, osd_cap_t)
-
-#endif
diff --git a/include/linux/dvb/video.h b/include/linux/dvb/video.h
deleted file mode 100644
index 1d750c0..0000000
--- a/include/linux/dvb/video.h
+++ /dev/null
@@ -1,276 +0,0 @@
-/*
- * video.h
- *
- * Copyright (C) 2000 Marcus Metzler <marcus@convergence.de>
- *                  & Ralph  Metzler <ralph@convergence.de>
- *                    for convergence integrated media GmbH
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public License
- * as published by the Free Software Foundation; either version 2.1
- * of the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
- *
- */
-
-#ifndef _DVBVIDEO_H_
-#define _DVBVIDEO_H_
-
-#include <linux/types.h>
-#ifdef __KERNEL__
-#include <linux/compiler.h>
-#else
-#include <stdint.h>
-#include <time.h>
-#endif
-
-typedef enum {
-	VIDEO_FORMAT_4_3,     /* Select 4:3 format */
-	VIDEO_FORMAT_16_9,    /* Select 16:9 format. */
-	VIDEO_FORMAT_221_1    /* 2.21:1 */
-} video_format_t;
-
-
-typedef enum {
-	 VIDEO_SYSTEM_PAL,
-	 VIDEO_SYSTEM_NTSC,
-	 VIDEO_SYSTEM_PALN,
-	 VIDEO_SYSTEM_PALNc,
-	 VIDEO_SYSTEM_PALM,
-	 VIDEO_SYSTEM_NTSC60,
-	 VIDEO_SYSTEM_PAL60,
-	 VIDEO_SYSTEM_PALM60
-} video_system_t;
-
-
-typedef enum {
-	VIDEO_PAN_SCAN,       /* use pan and scan format */
-	VIDEO_LETTER_BOX,     /* use letterbox format */
-	VIDEO_CENTER_CUT_OUT  /* use center cut out format */
-} video_displayformat_t;
-
-typedef struct {
-	int w;
-	int h;
-	video_format_t aspect_ratio;
-} video_size_t;
-
-typedef enum {
-	VIDEO_SOURCE_DEMUX, /* Select the demux as the main source */
-	VIDEO_SOURCE_MEMORY /* If this source is selected, the stream
-			       comes from the user through the write
-			       system call */
-} video_stream_source_t;
-
-
-typedef enum {
-	VIDEO_STOPPED, /* Video is stopped */
-	VIDEO_PLAYING, /* Video is currently playing */
-	VIDEO_FREEZED  /* Video is freezed */
-} video_play_state_t;
-
-
-/* Decoder commands */
-#define VIDEO_CMD_PLAY        (0)
-#define VIDEO_CMD_STOP        (1)
-#define VIDEO_CMD_FREEZE      (2)
-#define VIDEO_CMD_CONTINUE    (3)
-
-/* Flags for VIDEO_CMD_FREEZE */
-#define VIDEO_CMD_FREEZE_TO_BLACK     	(1 << 0)
-
-/* Flags for VIDEO_CMD_STOP */
-#define VIDEO_CMD_STOP_TO_BLACK      	(1 << 0)
-#define VIDEO_CMD_STOP_IMMEDIATELY     	(1 << 1)
-
-/* Play input formats: */
-/* The decoder has no special format requirements */
-#define VIDEO_PLAY_FMT_NONE         (0)
-/* The decoder requires full GOPs */
-#define VIDEO_PLAY_FMT_GOP          (1)
-
-/* The structure must be zeroed before use by the application
-   This ensures it can be extended safely in the future. */
-struct video_command {
-	__u32 cmd;
-	__u32 flags;
-	union {
-		struct {
-			__u64 pts;
-		} stop;
-
-		struct {
-			/* 0 or 1000 specifies normal speed,
-			   1 specifies forward single stepping,
-			   -1 specifies backward single stepping,
-			   >1: playback at speed/1000 of the normal speed,
-			   <-1: reverse playback at (-speed/1000) of the normal speed. */
-			__s32 speed;
-			__u32 format;
-		} play;
-
-		struct {
-			__u32 data[16];
-		} raw;
-	};
-};
-
-/* FIELD_UNKNOWN can be used if the hardware does not know whether
-   the Vsync is for an odd, even or progressive (i.e. non-interlaced)
-   field. */
-#define VIDEO_VSYNC_FIELD_UNKNOWN  	(0)
-#define VIDEO_VSYNC_FIELD_ODD 		(1)
-#define VIDEO_VSYNC_FIELD_EVEN		(2)
-#define VIDEO_VSYNC_FIELD_PROGRESSIVE	(3)
-
-struct video_event {
-	__s32 type;
-#define VIDEO_EVENT_SIZE_CHANGED	1
-#define VIDEO_EVENT_FRAME_RATE_CHANGED	2
-#define VIDEO_EVENT_DECODER_STOPPED 	3
-#define VIDEO_EVENT_VSYNC 		4
-	__kernel_time_t timestamp;
-	union {
-		video_size_t size;
-		unsigned int frame_rate;	/* in frames per 1000sec */
-		unsigned char vsync_field;	/* unknown/odd/even/progressive */
-	} u;
-};
-
-
-struct video_status {
-	int                   video_blank;   /* blank video on freeze? */
-	video_play_state_t    play_state;    /* current state of playback */
-	video_stream_source_t stream_source; /* current source (demux/memory) */
-	video_format_t        video_format;  /* current aspect ratio of stream*/
-	video_displayformat_t display_format;/* selected cropping mode */
-};
-
-
-struct video_still_picture {
-	char __user *iFrame;        /* pointer to a single iframe in memory */
-	__s32 size;
-};
-
-
-typedef
-struct video_highlight {
-	int     active;      /*    1=show highlight, 0=hide highlight */
-	__u8    contrast1;   /*    7- 4  Pattern pixel contrast */
-			     /*    3- 0  Background pixel contrast */
-	__u8    contrast2;   /*    7- 4  Emphasis pixel-2 contrast */
-			     /*    3- 0  Emphasis pixel-1 contrast */
-	__u8    color1;      /*    7- 4  Pattern pixel color */
-			     /*    3- 0  Background pixel color */
-	__u8    color2;      /*    7- 4  Emphasis pixel-2 color */
-			     /*    3- 0  Emphasis pixel-1 color */
-	__u32    ypos;       /*   23-22  auto action mode */
-			     /*   21-12  start y */
-			     /*    9- 0  end y */
-	__u32    xpos;       /*   23-22  button color number */
-			     /*   21-12  start x */
-			     /*    9- 0  end x */
-} video_highlight_t;
-
-
-typedef struct video_spu {
-	int active;
-	int stream_id;
-} video_spu_t;
-
-
-typedef struct video_spu_palette {      /* SPU Palette information */
-	int length;
-	__u8 __user *palette;
-} video_spu_palette_t;
-
-
-typedef struct video_navi_pack {
-	int length;          /* 0 ... 1024 */
-	__u8 data[1024];
-} video_navi_pack_t;
-
-
-typedef __u16 video_attributes_t;
-/*   bits: descr. */
-/*   15-14 Video compression mode (0=MPEG-1, 1=MPEG-2) */
-/*   13-12 TV system (0=525/60, 1=625/50) */
-/*   11-10 Aspect ratio (0=4:3, 3=16:9) */
-/*    9- 8 permitted display mode on 4:3 monitor (0=both, 1=only pan-sca */
-/*    7    line 21-1 data present in GOP (1=yes, 0=no) */
-/*    6    line 21-2 data present in GOP (1=yes, 0=no) */
-/*    5- 3 source resolution (0=720x480/576, 1=704x480/576, 2=352x480/57 */
-/*    2    source letterboxed (1=yes, 0=no) */
-/*    0    film/camera mode (0=camera, 1=film (625/50 only)) */
-
-
-/* bit definitions for capabilities: */
-/* can the hardware decode MPEG1 and/or MPEG2? */
-#define VIDEO_CAP_MPEG1   1
-#define VIDEO_CAP_MPEG2   2
-/* can you send a system and/or program stream to video device?
-   (you still have to open the video and the audio device but only
-    send the stream to the video device) */
-#define VIDEO_CAP_SYS     4
-#define VIDEO_CAP_PROG    8
-/* can the driver also handle SPU, NAVI and CSS encoded data?
-   (CSS API is not present yet) */
-#define VIDEO_CAP_SPU    16
-#define VIDEO_CAP_NAVI   32
-#define VIDEO_CAP_CSS    64
-
-
-#define VIDEO_STOP                 _IO('o', 21)
-#define VIDEO_PLAY                 _IO('o', 22)
-#define VIDEO_FREEZE               _IO('o', 23)
-#define VIDEO_CONTINUE             _IO('o', 24)
-#define VIDEO_SELECT_SOURCE        _IO('o', 25)
-#define VIDEO_SET_BLANK            _IO('o', 26)
-#define VIDEO_GET_STATUS           _IOR('o', 27, struct video_status)
-#define VIDEO_GET_EVENT            _IOR('o', 28, struct video_event)
-#define VIDEO_SET_DISPLAY_FORMAT   _IO('o', 29)
-#define VIDEO_STILLPICTURE         _IOW('o', 30, struct video_still_picture)
-#define VIDEO_FAST_FORWARD         _IO('o', 31)
-#define VIDEO_SLOWMOTION           _IO('o', 32)
-#define VIDEO_GET_CAPABILITIES     _IOR('o', 33, unsigned int)
-#define VIDEO_CLEAR_BUFFER         _IO('o',  34)
-#define VIDEO_SET_ID               _IO('o', 35)
-#define VIDEO_SET_STREAMTYPE       _IO('o', 36)
-#define VIDEO_SET_FORMAT           _IO('o', 37)
-#define VIDEO_SET_SYSTEM           _IO('o', 38)
-#define VIDEO_SET_HIGHLIGHT        _IOW('o', 39, video_highlight_t)
-#define VIDEO_SET_SPU              _IOW('o', 50, video_spu_t)
-#define VIDEO_SET_SPU_PALETTE      _IOW('o', 51, video_spu_palette_t)
-#define VIDEO_GET_NAVI             _IOR('o', 52, video_navi_pack_t)
-#define VIDEO_SET_ATTRIBUTES       _IO('o', 53)
-#define VIDEO_GET_SIZE             _IOR('o', 55, video_size_t)
-#define VIDEO_GET_FRAME_RATE       _IOR('o', 56, unsigned int)
-
-/**
- * VIDEO_GET_PTS
- *
- * Read the 33 bit presentation time stamp as defined
- * in ITU T-REC-H.222.0 / ISO/IEC 13818-1.
- *
- * The PTS should belong to the currently played
- * frame if possible, but may also be a value close to it
- * like the PTS of the last decoded frame or the last PTS
- * extracted by the PES parser.
- */
-#define VIDEO_GET_PTS              _IOR('o', 57, __u64)
-
-/* Read the number of displayed frames since the decoder was started */
-#define VIDEO_GET_FRAME_COUNT  	   _IOR('o', 58, __u64)
-
-#define VIDEO_COMMAND     	   _IOWR('o', 59, struct video_command)
-#define VIDEO_TRY_COMMAND 	   _IOWR('o', 60, struct video_command)
-
-#endif /*_DVBVIDEO_H_*/
-- 
1.7.7.3

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Andreas Oberritter]

Don't break existing Userspace APIs for no reason! It's OK to add the
new API, but - pretty please - don't just blindly remove audio.h and
video.h. They are in use since many years by av7110, out-of-tree drivers
*and more importantly* by applications. Yes, I know, you'd like to see
those out-of-tree drivers merged, but it isn't possible for many
reasons. And even if they were merged, you'd say "Port them and your
apps to V4L". No! That's not an option.

Regards,
Andreas

On 24.11.2011 14:39, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
> 
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> ---
>  fs/compat_ioctl.c         |   41 +-------
>  include/linux/dvb/Kbuild  |    3 -
>  include/linux/dvb/audio.h |  135 ----------------------
>  include/linux/dvb/osd.h   |  144 -----------------------
>  include/linux/dvb/video.h |  276 ---------------------------------------------
>  5 files changed, 1 insertions(+), 598 deletions(-)
>  delete mode 100644 include/linux/dvb/audio.h
>  delete mode 100644 include/linux/dvb/osd.h
>  delete mode 100644 include/linux/dvb/video.h
> 
> diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
> index 51352de..71adea1 100644
> --- a/fs/compat_ioctl.c
> +++ b/fs/compat_ioctl.c
> @@ -105,10 +105,9 @@
>  
>  #include <linux/hiddev.h>
>  
> -#include <linux/dvb/audio.h>
> +#include <linux/av7110.h>
>  #include <linux/dvb/dmx.h>
>  #include <linux/dvb/frontend.h>
> -#include <linux/dvb/video.h>
>  
>  #include <linux/sort.h>
>  
> @@ -196,32 +195,6 @@ static int do_video_stillpicture(unsigned int fd, unsigned int cmd,
>  	return err;
>  }
>  
> -struct compat_video_spu_palette {
> -	int length;
> -	compat_uptr_t palette;
> -};
> -
> -static int do_video_set_spu_palette(unsigned int fd, unsigned int cmd,
> -		struct compat_video_spu_palette __user *up)
> -{
> -	struct video_spu_palette __user *up_native;
> -	compat_uptr_t palp;
> -	int length, err;
> -
> -	err  = get_user(palp, &up->palette);
> -	err |= get_user(length, &up->length);
> -
> -	up_native = compat_alloc_user_space(sizeof(struct video_spu_palette));
> -	err  = put_user(compat_ptr(palp), &up_native->palette);
> -	err |= put_user(length, &up_native->length);
> -	if (err)
> -		return -EFAULT;
> -
> -	err = sys_ioctl(fd, cmd, (unsigned long) up_native);
> -
> -	return err;
> -}
> -
>  #ifdef CONFIG_BLOCK
>  typedef struct sg_io_hdr32 {
>  	compat_int_t interface_id;	/* [i] 'S' for SCSI generic (required) */
> @@ -1317,9 +1290,6 @@ COMPATIBLE_IOCTL(AUDIO_CLEAR_BUFFER)
>  COMPATIBLE_IOCTL(AUDIO_SET_ID)
>  COMPATIBLE_IOCTL(AUDIO_SET_MIXER)
>  COMPATIBLE_IOCTL(AUDIO_SET_STREAMTYPE)
> -COMPATIBLE_IOCTL(AUDIO_SET_EXT_ID)
> -COMPATIBLE_IOCTL(AUDIO_SET_ATTRIBUTES)
> -COMPATIBLE_IOCTL(AUDIO_SET_KARAOKE)
>  COMPATIBLE_IOCTL(DMX_START)
>  COMPATIBLE_IOCTL(DMX_STOP)
>  COMPATIBLE_IOCTL(DMX_SET_FILTER)
> @@ -1358,16 +1328,9 @@ COMPATIBLE_IOCTL(VIDEO_FAST_FORWARD)
>  COMPATIBLE_IOCTL(VIDEO_SLOWMOTION)
>  COMPATIBLE_IOCTL(VIDEO_GET_CAPABILITIES)
>  COMPATIBLE_IOCTL(VIDEO_CLEAR_BUFFER)
> -COMPATIBLE_IOCTL(VIDEO_SET_ID)
>  COMPATIBLE_IOCTL(VIDEO_SET_STREAMTYPE)
>  COMPATIBLE_IOCTL(VIDEO_SET_FORMAT)
> -COMPATIBLE_IOCTL(VIDEO_SET_SYSTEM)
> -COMPATIBLE_IOCTL(VIDEO_SET_HIGHLIGHT)
> -COMPATIBLE_IOCTL(VIDEO_SET_SPU)
> -COMPATIBLE_IOCTL(VIDEO_GET_NAVI)
> -COMPATIBLE_IOCTL(VIDEO_SET_ATTRIBUTES)
>  COMPATIBLE_IOCTL(VIDEO_GET_SIZE)
> -COMPATIBLE_IOCTL(VIDEO_GET_FRAME_RATE)
>  
>  /* joystick */
>  COMPATIBLE_IOCTL(JSIOCGVERSION)
> @@ -1468,8 +1431,6 @@ static long do_ioctl_trans(int fd, unsigned int cmd,
>  		return do_video_get_event(fd, cmd, argp);
>  	case VIDEO_STILLPICTURE:
>  		return do_video_stillpicture(fd, cmd, argp);
> -	case VIDEO_SET_SPU_PALETTE:
> -		return do_video_set_spu_palette(fd, cmd, argp);
>  	}
>  
>  	/*
> diff --git a/include/linux/dvb/Kbuild b/include/linux/dvb/Kbuild
> index f4dba86..f5aa137 100644
> --- a/include/linux/dvb/Kbuild
> +++ b/include/linux/dvb/Kbuild
> @@ -1,8 +1,5 @@
> -header-y += audio.h
>  header-y += ca.h
>  header-y += dmx.h
>  header-y += frontend.h
>  header-y += net.h
> -header-y += osd.h
>  header-y += version.h
> -header-y += video.h
> diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h
> deleted file mode 100644
> index d47bccd..0000000
> --- a/include/linux/dvb/audio.h
> +++ /dev/null
> @@ -1,135 +0,0 @@
> -/*
> - * audio.h
> - *
> - * Copyright (C) 2000 Ralph  Metzler <ralph@convergence.de>
> - *                  & Marcus Metzler <marcus@convergence.de>
> - *                    for convergence integrated media GmbH
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Lesser Public License
> - * as published by the Free Software Foundation; either version 2.1
> - * of the License, or (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU Lesser General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
> - *
> - */
> -
> -#ifndef _DVBAUDIO_H_
> -#define _DVBAUDIO_H_
> -
> -#include <linux/types.h>
> -
> -typedef enum {
> -	AUDIO_SOURCE_DEMUX, /* Select the demux as the main source */
> -	AUDIO_SOURCE_MEMORY /* Select internal memory as the main source */
> -} audio_stream_source_t;
> -
> -
> -typedef enum {
> -	AUDIO_STOPPED,      /* Device is stopped */
> -	AUDIO_PLAYING,      /* Device is currently playing */
> -	AUDIO_PAUSED        /* Device is paused */
> -} audio_play_state_t;
> -
> -
> -typedef enum {
> -	AUDIO_STEREO,
> -	AUDIO_MONO_LEFT,
> -	AUDIO_MONO_RIGHT,
> -	AUDIO_MONO,
> -	AUDIO_STEREO_SWAPPED
> -} audio_channel_select_t;
> -
> -
> -typedef struct audio_mixer {
> -	unsigned int volume_left;
> -	unsigned int volume_right;
> -  // what else do we need? bass, pass-through, ...
> -} audio_mixer_t;
> -
> -
> -typedef struct audio_status {
> -	int                    AV_sync_state;  /* sync audio and video? */
> -	int                    mute_state;     /* audio is muted */
> -	audio_play_state_t     play_state;     /* current playback state */
> -	audio_stream_source_t  stream_source;  /* current stream source */
> -	audio_channel_select_t channel_select; /* currently selected channel */
> -	int                    bypass_mode;    /* pass on audio data to */
> -	audio_mixer_t	       mixer_state;    /* current mixer state */
> -} audio_status_t;                              /* separate decoder hardware */
> -
> -
> -typedef
> -struct audio_karaoke {  /* if Vocal1 or Vocal2 are non-zero, they get mixed  */
> -	int vocal1;    /* into left and right t at 70% each */
> -	int vocal2;    /* if both, Vocal1 and Vocal2 are non-zero, Vocal1 gets*/
> -	int melody;    /* mixed into the left channel and */
> -		       /* Vocal2 into the right channel at 100% each. */
> -		       /* if Melody is non-zero, the melody channel gets mixed*/
> -} audio_karaoke_t;     /* into left and right  */
> -
> -
> -typedef __u16 audio_attributes_t;
> -/*   bits: descr. */
> -/*   15-13 audio coding mode (0=ac3, 2=mpeg1, 3=mpeg2ext, 4=LPCM, 6=DTS, */
> -/*   12    multichannel extension */
> -/*   11-10 audio type (0=not spec, 1=language included) */
> -/*    9- 8 audio application mode (0=not spec, 1=karaoke, 2=surround) */
> -/*    7- 6 Quantization / DRC (mpeg audio: 1=DRC exists)(lpcm: 0=16bit,  */
> -/*    5- 4 Sample frequency fs (0=48kHz, 1=96kHz) */
> -/*    2- 0 number of audio channels (n+1 channels) */
> -
> -
> -/* for GET_CAPABILITIES and SET_FORMAT, the latter should only set one bit */
> -#define AUDIO_CAP_DTS    1
> -#define AUDIO_CAP_LPCM   2
> -#define AUDIO_CAP_MP1    4
> -#define AUDIO_CAP_MP2    8
> -#define AUDIO_CAP_MP3   16
> -#define AUDIO_CAP_AAC   32
> -#define AUDIO_CAP_OGG   64
> -#define AUDIO_CAP_SDDS 128
> -#define AUDIO_CAP_AC3  256
> -
> -#define AUDIO_STOP                 _IO('o', 1)
> -#define AUDIO_PLAY                 _IO('o', 2)
> -#define AUDIO_PAUSE                _IO('o', 3)
> -#define AUDIO_CONTINUE             _IO('o', 4)
> -#define AUDIO_SELECT_SOURCE        _IO('o', 5)
> -#define AUDIO_SET_MUTE             _IO('o', 6)
> -#define AUDIO_SET_AV_SYNC          _IO('o', 7)
> -#define AUDIO_SET_BYPASS_MODE      _IO('o', 8)
> -#define AUDIO_CHANNEL_SELECT       _IO('o', 9)
> -#define AUDIO_GET_STATUS           _IOR('o', 10, audio_status_t)
> -
> -#define AUDIO_GET_CAPABILITIES     _IOR('o', 11, unsigned int)
> -#define AUDIO_CLEAR_BUFFER         _IO('o',  12)
> -#define AUDIO_SET_ID               _IO('o', 13)
> -#define AUDIO_SET_MIXER            _IOW('o', 14, audio_mixer_t)
> -#define AUDIO_SET_STREAMTYPE       _IO('o', 15)
> -#define AUDIO_SET_EXT_ID           _IO('o', 16)
> -#define AUDIO_SET_ATTRIBUTES       _IOW('o', 17, audio_attributes_t)
> -#define AUDIO_SET_KARAOKE          _IOW('o', 18, audio_karaoke_t)
> -
> -/**
> - * AUDIO_GET_PTS
> - *
> - * Read the 33 bit presentation time stamp as defined
> - * in ITU T-REC-H.222.0 / ISO/IEC 13818-1.
> - *
> - * The PTS should belong to the currently played
> - * frame if possible, but may also be a value close to it
> - * like the PTS of the last decoded frame or the last PTS
> - * extracted by the PES parser.
> - */
> -#define AUDIO_GET_PTS              _IOR('o', 19, __u64)
> -#define AUDIO_BILINGUAL_CHANNEL_SELECT _IO('o', 20)
> -
> -#endif /* _DVBAUDIO_H_ */
> diff --git a/include/linux/dvb/osd.h b/include/linux/dvb/osd.h
> deleted file mode 100644
> index 880e684..0000000
> --- a/include/linux/dvb/osd.h
> +++ /dev/null
> @@ -1,144 +0,0 @@
> -/*
> - * osd.h
> - *
> - * Copyright (C) 2001 Ralph  Metzler <ralph@convergence.de>
> - *                  & Marcus Metzler <marcus@convergence.de>
> - *                    for convergence integrated media GmbH
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Lesser Public License
> - * as published by the Free Software Foundation; either version 2.1
> - * of the License, or (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU Lesser General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
> - *
> - */
> -
> -#ifndef _DVBOSD_H_
> -#define _DVBOSD_H_
> -
> -#include <linux/compiler.h>
> -
> -typedef enum {
> -  // All functions return -2 on "not open"
> -  OSD_Close=1,    // ()
> -  // Disables OSD and releases the buffers
> -  // returns 0 on success
> -  OSD_Open,       // (x0,y0,x1,y1,BitPerPixel[2/4/8](color&0x0F),mix[0..15](color&0xF0))
> -  // Opens OSD with this size and bit depth
> -  // returns 0 on success, -1 on DRAM allocation error, -2 on "already open"
> -  OSD_Show,       // ()
> -  // enables OSD mode
> -  // returns 0 on success
> -  OSD_Hide,       // ()
> -  // disables OSD mode
> -  // returns 0 on success
> -  OSD_Clear,      // ()
> -  // Sets all pixel to color 0
> -  // returns 0 on success
> -  OSD_Fill,       // (color)
> -  // Sets all pixel to color <col>
> -  // returns 0 on success
> -  OSD_SetColor,   // (color,R{x0},G{y0},B{x1},opacity{y1})
> -  // set palette entry <num> to <r,g,b>, <mix> and <trans> apply
> -  // R,G,B: 0..255
> -  // R=Red, G=Green, B=Blue
> -  // opacity=0:      pixel opacity 0% (only video pixel shows)
> -  // opacity=1..254: pixel opacity as specified in header
> -  // opacity=255:    pixel opacity 100% (only OSD pixel shows)
> -  // returns 0 on success, -1 on error
> -  OSD_SetPalette, // (firstcolor{color},lastcolor{x0},data)
> -  // Set a number of entries in the palette
> -  // sets the entries "firstcolor" through "lastcolor" from the array "data"
> -  // data has 4 byte for each color:
> -  // R,G,B, and a opacity value: 0->transparent, 1..254->mix, 255->pixel
> -  OSD_SetTrans,   // (transparency{color})
> -  // Sets transparency of mixed pixel (0..15)
> -  // returns 0 on success
> -  OSD_SetPixel,   // (x0,y0,color)
> -  // sets pixel <x>,<y> to color number <col>
> -  // returns 0 on success, -1 on error
> -  OSD_GetPixel,   // (x0,y0)
> -  // returns color number of pixel <x>,<y>,  or -1
> -  OSD_SetRow,     // (x0,y0,x1,data)
> -  // fills pixels x0,y through  x1,y with the content of data[]
> -  // returns 0 on success, -1 on clipping all pixel (no pixel drawn)
> -  OSD_SetBlock,   // (x0,y0,x1,y1,increment{color},data)
> -  // fills pixels x0,y0 through  x1,y1 with the content of data[]
> -  // inc contains the width of one line in the data block,
> -  // inc<=0 uses blockwidth as linewidth
> -  // returns 0 on success, -1 on clipping all pixel
> -  OSD_FillRow,    // (x0,y0,x1,color)
> -  // fills pixels x0,y through  x1,y with the color <col>
> -  // returns 0 on success, -1 on clipping all pixel
> -  OSD_FillBlock,  // (x0,y0,x1,y1,color)
> -  // fills pixels x0,y0 through  x1,y1 with the color <col>
> -  // returns 0 on success, -1 on clipping all pixel
> -  OSD_Line,       // (x0,y0,x1,y1,color)
> -  // draw a line from x0,y0 to x1,y1 with the color <col>
> -  // returns 0 on success
> -  OSD_Query,      // (x0,y0,x1,y1,xasp{color}}), yasp=11
> -  // fills parameters with the picture dimensions and the pixel aspect ratio
> -  // returns 0 on success
> -  OSD_Test,       // ()
> -  // draws a test picture. for debugging purposes only
> -  // returns 0 on success
> -// TODO: remove "test" in final version
> -  OSD_Text,       // (x0,y0,size,color,text)
> -  OSD_SetWindow, //  (x0) set window with number 0<x0<8 as current
> -  OSD_MoveWindow, //  move current window to (x0, y0)
> -  OSD_OpenRaw,	// Open other types of OSD windows
> -} OSD_Command;
> -
> -typedef struct osd_cmd_s {
> -	OSD_Command cmd;
> -	int x0;
> -	int y0;
> -	int x1;
> -	int y1;
> -	int color;
> -	void __user *data;
> -} osd_cmd_t;
> -
> -/* OSD_OpenRaw: set 'color' to desired window type */
> -typedef enum {
> -	OSD_BITMAP1,           /* 1 bit bitmap */
> -	OSD_BITMAP2,           /* 2 bit bitmap */
> -	OSD_BITMAP4,           /* 4 bit bitmap */
> -	OSD_BITMAP8,           /* 8 bit bitmap */
> -	OSD_BITMAP1HR,         /* 1 Bit bitmap half resolution */
> -	OSD_BITMAP2HR,         /* 2 bit bitmap half resolution */
> -	OSD_BITMAP4HR,         /* 4 bit bitmap half resolution */
> -	OSD_BITMAP8HR,         /* 8 bit bitmap half resolution */
> -	OSD_YCRCB422,          /* 4:2:2 YCRCB Graphic Display */
> -	OSD_YCRCB444,          /* 4:4:4 YCRCB Graphic Display */
> -	OSD_YCRCB444HR,        /* 4:4:4 YCRCB graphic half resolution */
> -	OSD_VIDEOTSIZE,        /* True Size Normal MPEG Video Display */
> -	OSD_VIDEOHSIZE,        /* MPEG Video Display Half Resolution */
> -	OSD_VIDEOQSIZE,        /* MPEG Video Display Quarter Resolution */
> -	OSD_VIDEODSIZE,        /* MPEG Video Display Double Resolution */
> -	OSD_VIDEOTHSIZE,       /* True Size MPEG Video Display Half Resolution */
> -	OSD_VIDEOTQSIZE,       /* True Size MPEG Video Display Quarter Resolution*/
> -	OSD_VIDEOTDSIZE,       /* True Size MPEG Video Display Double Resolution */
> -	OSD_VIDEONSIZE,        /* Full Size MPEG Video Display */
> -	OSD_CURSOR             /* Cursor */
> -} osd_raw_window_t;
> -
> -typedef struct osd_cap_s {
> -	int  cmd;
> -#define OSD_CAP_MEMSIZE         1  /* memory size */
> -	long val;
> -} osd_cap_t;
> -
> -
> -#define OSD_SEND_CMD            _IOW('o', 160, osd_cmd_t)
> -#define OSD_GET_CAPABILITY      _IOR('o', 161, osd_cap_t)
> -
> -#endif
> diff --git a/include/linux/dvb/video.h b/include/linux/dvb/video.h
> deleted file mode 100644
> index 1d750c0..0000000
> --- a/include/linux/dvb/video.h
> +++ /dev/null
> @@ -1,276 +0,0 @@
> -/*
> - * video.h
> - *
> - * Copyright (C) 2000 Marcus Metzler <marcus@convergence.de>
> - *                  & Ralph  Metzler <ralph@convergence.de>
> - *                    for convergence integrated media GmbH
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU Lesser General Public License
> - * as published by the Free Software Foundation; either version 2.1
> - * of the License, or (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU Lesser General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
> - *
> - */
> -
> -#ifndef _DVBVIDEO_H_
> -#define _DVBVIDEO_H_
> -
> -#include <linux/types.h>
> -#ifdef __KERNEL__
> -#include <linux/compiler.h>
> -#else
> -#include <stdint.h>
> -#include <time.h>
> -#endif
> -
> -typedef enum {
> -	VIDEO_FORMAT_4_3,     /* Select 4:3 format */
> -	VIDEO_FORMAT_16_9,    /* Select 16:9 format. */
> -	VIDEO_FORMAT_221_1    /* 2.21:1 */
> -} video_format_t;
> -
> -
> -typedef enum {
> -	 VIDEO_SYSTEM_PAL,
> -	 VIDEO_SYSTEM_NTSC,
> -	 VIDEO_SYSTEM_PALN,
> -	 VIDEO_SYSTEM_PALNc,
> -	 VIDEO_SYSTEM_PALM,
> -	 VIDEO_SYSTEM_NTSC60,
> -	 VIDEO_SYSTEM_PAL60,
> -	 VIDEO_SYSTEM_PALM60
> -} video_system_t;
> -
> -
> -typedef enum {
> -	VIDEO_PAN_SCAN,       /* use pan and scan format */
> -	VIDEO_LETTER_BOX,     /* use letterbox format */
> -	VIDEO_CENTER_CUT_OUT  /* use center cut out format */
> -} video_displayformat_t;
> -
> -typedef struct {
> -	int w;
> -	int h;
> -	video_format_t aspect_ratio;
> -} video_size_t;
> -
> -typedef enum {
> -	VIDEO_SOURCE_DEMUX, /* Select the demux as the main source */
> -	VIDEO_SOURCE_MEMORY /* If this source is selected, the stream
> -			       comes from the user through the write
> -			       system call */
> -} video_stream_source_t;
> -
> -
> -typedef enum {
> -	VIDEO_STOPPED, /* Video is stopped */
> -	VIDEO_PLAYING, /* Video is currently playing */
> -	VIDEO_FREEZED  /* Video is freezed */
> -} video_play_state_t;
> -
> -
> -/* Decoder commands */
> -#define VIDEO_CMD_PLAY        (0)
> -#define VIDEO_CMD_STOP        (1)
> -#define VIDEO_CMD_FREEZE      (2)
> -#define VIDEO_CMD_CONTINUE    (3)
> -
> -/* Flags for VIDEO_CMD_FREEZE */
> -#define VIDEO_CMD_FREEZE_TO_BLACK     	(1 << 0)
> -
> -/* Flags for VIDEO_CMD_STOP */
> -#define VIDEO_CMD_STOP_TO_BLACK      	(1 << 0)
> -#define VIDEO_CMD_STOP_IMMEDIATELY     	(1 << 1)
> -
> -/* Play input formats: */
> -/* The decoder has no special format requirements */
> -#define VIDEO_PLAY_FMT_NONE         (0)
> -/* The decoder requires full GOPs */
> -#define VIDEO_PLAY_FMT_GOP          (1)
> -
> -/* The structure must be zeroed before use by the application
> -   This ensures it can be extended safely in the future. */
> -struct video_command {
> -	__u32 cmd;
> -	__u32 flags;
> -	union {
> -		struct {
> -			__u64 pts;
> -		} stop;
> -
> -		struct {
> -			/* 0 or 1000 specifies normal speed,
> -			   1 specifies forward single stepping,
> -			   -1 specifies backward single stepping,
> -			   >1: playback at speed/1000 of the normal speed,
> -			   <-1: reverse playback at (-speed/1000) of the normal speed. */
> -			__s32 speed;
> -			__u32 format;
> -		} play;
> -
> -		struct {
> -			__u32 data[16];
> -		} raw;
> -	};
> -};
> -
> -/* FIELD_UNKNOWN can be used if the hardware does not know whether
> -   the Vsync is for an odd, even or progressive (i.e. non-interlaced)
> -   field. */
> -#define VIDEO_VSYNC_FIELD_UNKNOWN  	(0)
> -#define VIDEO_VSYNC_FIELD_ODD 		(1)
> -#define VIDEO_VSYNC_FIELD_EVEN		(2)
> -#define VIDEO_VSYNC_FIELD_PROGRESSIVE	(3)
> -
> -struct video_event {
> -	__s32 type;
> -#define VIDEO_EVENT_SIZE_CHANGED	1
> -#define VIDEO_EVENT_FRAME_RATE_CHANGED	2
> -#define VIDEO_EVENT_DECODER_STOPPED 	3
> -#define VIDEO_EVENT_VSYNC 		4
> -	__kernel_time_t timestamp;
> -	union {
> -		video_size_t size;
> -		unsigned int frame_rate;	/* in frames per 1000sec */
> -		unsigned char vsync_field;	/* unknown/odd/even/progressive */
> -	} u;
> -};
> -
> -
> -struct video_status {
> -	int                   video_blank;   /* blank video on freeze? */
> -	video_play_state_t    play_state;    /* current state of playback */
> -	video_stream_source_t stream_source; /* current source (demux/memory) */
> -	video_format_t        video_format;  /* current aspect ratio of stream*/
> -	video_displayformat_t display_format;/* selected cropping mode */
> -};
> -
> -
> -struct video_still_picture {
> -	char __user *iFrame;        /* pointer to a single iframe in memory */
> -	__s32 size;
> -};
> -
> -
> -typedef
> -struct video_highlight {
> -	int     active;      /*    1=show highlight, 0=hide highlight */
> -	__u8    contrast1;   /*    7- 4  Pattern pixel contrast */
> -			     /*    3- 0  Background pixel contrast */
> -	__u8    contrast2;   /*    7- 4  Emphasis pixel-2 contrast */
> -			     /*    3- 0  Emphasis pixel-1 contrast */
> -	__u8    color1;      /*    7- 4  Pattern pixel color */
> -			     /*    3- 0  Background pixel color */
> -	__u8    color2;      /*    7- 4  Emphasis pixel-2 color */
> -			     /*    3- 0  Emphasis pixel-1 color */
> -	__u32    ypos;       /*   23-22  auto action mode */
> -			     /*   21-12  start y */
> -			     /*    9- 0  end y */
> -	__u32    xpos;       /*   23-22  button color number */
> -			     /*   21-12  start x */
> -			     /*    9- 0  end x */
> -} video_highlight_t;
> -
> -
> -typedef struct video_spu {
> -	int active;
> -	int stream_id;
> -} video_spu_t;
> -
> -
> -typedef struct video_spu_palette {      /* SPU Palette information */
> -	int length;
> -	__u8 __user *palette;
> -} video_spu_palette_t;
> -
> -
> -typedef struct video_navi_pack {
> -	int length;          /* 0 ... 1024 */
> -	__u8 data[1024];
> -} video_navi_pack_t;
> -
> -
> -typedef __u16 video_attributes_t;
> -/*   bits: descr. */
> -/*   15-14 Video compression mode (0=MPEG-1, 1=MPEG-2) */
> -/*   13-12 TV system (0=525/60, 1=625/50) */
> -/*   11-10 Aspect ratio (0=4:3, 3=16:9) */
> -/*    9- 8 permitted display mode on 4:3 monitor (0=both, 1=only pan-sca */
> -/*    7    line 21-1 data present in GOP (1=yes, 0=no) */
> -/*    6    line 21-2 data present in GOP (1=yes, 0=no) */
> -/*    5- 3 source resolution (0=720x480/576, 1=704x480/576, 2=352x480/57 */
> -/*    2    source letterboxed (1=yes, 0=no) */
> -/*    0    film/camera mode (0=camera, 1=film (625/50 only)) */
> -
> -
> -/* bit definitions for capabilities: */
> -/* can the hardware decode MPEG1 and/or MPEG2? */
> -#define VIDEO_CAP_MPEG1   1
> -#define VIDEO_CAP_MPEG2   2
> -/* can you send a system and/or program stream to video device?
> -   (you still have to open the video and the audio device but only
> -    send the stream to the video device) */
> -#define VIDEO_CAP_SYS     4
> -#define VIDEO_CAP_PROG    8
> -/* can the driver also handle SPU, NAVI and CSS encoded data?
> -   (CSS API is not present yet) */
> -#define VIDEO_CAP_SPU    16
> -#define VIDEO_CAP_NAVI   32
> -#define VIDEO_CAP_CSS    64
> -
> -
> -#define VIDEO_STOP                 _IO('o', 21)
> -#define VIDEO_PLAY                 _IO('o', 22)
> -#define VIDEO_FREEZE               _IO('o', 23)
> -#define VIDEO_CONTINUE             _IO('o', 24)
> -#define VIDEO_SELECT_SOURCE        _IO('o', 25)
> -#define VIDEO_SET_BLANK            _IO('o', 26)
> -#define VIDEO_GET_STATUS           _IOR('o', 27, struct video_status)
> -#define VIDEO_GET_EVENT            _IOR('o', 28, struct video_event)
> -#define VIDEO_SET_DISPLAY_FORMAT   _IO('o', 29)
> -#define VIDEO_STILLPICTURE         _IOW('o', 30, struct video_still_picture)
> -#define VIDEO_FAST_FORWARD         _IO('o', 31)
> -#define VIDEO_SLOWMOTION           _IO('o', 32)
> -#define VIDEO_GET_CAPABILITIES     _IOR('o', 33, unsigned int)
> -#define VIDEO_CLEAR_BUFFER         _IO('o',  34)
> -#define VIDEO_SET_ID               _IO('o', 35)
> -#define VIDEO_SET_STREAMTYPE       _IO('o', 36)
> -#define VIDEO_SET_FORMAT           _IO('o', 37)
> -#define VIDEO_SET_SYSTEM           _IO('o', 38)
> -#define VIDEO_SET_HIGHLIGHT        _IOW('o', 39, video_highlight_t)
> -#define VIDEO_SET_SPU              _IOW('o', 50, video_spu_t)
> -#define VIDEO_SET_SPU_PALETTE      _IOW('o', 51, video_spu_palette_t)
> -#define VIDEO_GET_NAVI             _IOR('o', 52, video_navi_pack_t)
> -#define VIDEO_SET_ATTRIBUTES       _IO('o', 53)
> -#define VIDEO_GET_SIZE             _IOR('o', 55, video_size_t)
> -#define VIDEO_GET_FRAME_RATE       _IOR('o', 56, unsigned int)
> -
> -/**
> - * VIDEO_GET_PTS
> - *
> - * Read the 33 bit presentation time stamp as defined
> - * in ITU T-REC-H.222.0 / ISO/IEC 13818-1.
> - *
> - * The PTS should belong to the currently played
> - * frame if possible, but may also be a value close to it
> - * like the PTS of the last decoded frame or the last PTS
> - * extracted by the PES parser.
> - */
> -#define VIDEO_GET_PTS              _IOR('o', 57, __u64)
> -
> -/* Read the number of displayed frames since the decoder was started */
> -#define VIDEO_GET_FRAME_COUNT  	   _IOR('o', 58, __u64)
> -
> -#define VIDEO_COMMAND     	   _IOWR('o', 59, struct video_command)
> -#define VIDEO_TRY_COMMAND 	   _IOWR('o', 60, struct video_command)
> -
> -#endif /*_DVBVIDEO_H_*/

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 24-11-2011 15:08, Andreas Oberritter escreveu:
> Don't break existing Userspace APIs for no reason! It's OK to add the
> new API, but - pretty please - don't just blindly remove audio.h and
> video.h. They are in use since many years by av7110, out-of-tree drivers
> *and more importantly* by applications. Yes, I know, you'd like to see
> those out-of-tree drivers merged, but it isn't possible for many
> reasons. And even if they were merged, you'd say "Port them and your
> apps to V4L". No! That's not an option.

Hi Andreas,

Userspace applications that support av7110 can include the new linux/av7110.h
header. Other applications that support out-of-tree drivers can just have
their own copy of audio.h, osd.h and video.h. So, it won't break or prevent
existing applications to keep working.

The thing is that the media API presents two interfaces to control mpeg decoders.
This is confusing, and, while one of them has active upstream developers working
on it, adding new drivers and new features on it, the other API is not being
updated accordingly, and no new upstream drivers use it.

Worse than that, several ioctl's are there, with not a single in-kernel implementation, 
nor any documentation about how they are supposed to work.

We noticed in Prague that new DVB developers got confused about what should be the
proper implementation for new drivers, so marking it as deprecated is important,
otherwise, we'll end by having different approaches for the same thing.

Just to give you one example, newer DTV standards like ISDB-T and DVB-T2 now uses
H.264 video streams. Support for H.264 were added recently at V4L2 API, but the
dvb video API doesn't support it.

What I'm saying is that this API is legacy, from kernel POV.  So, let's freeze it to DVB v5.4
spec, and remove it from the official Kernel DVB API on future versions (yet, keeping it
as a private API for av7110). It probably makes sense to increase the major version
at DVB API, when this patches got merged, to indicate that DVB v6 and above doesn't
have it anymore, while v5.4 and bellow has it.

> 
> Regards,
> Andreas
> 
> On 24.11.2011 14:39, Hans Verkuil wrote:
>> From: Hans Verkuil <hans.verkuil@cisco.com>
>>
>> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>> ---
>>  fs/compat_ioctl.c         |   41 +-------
>>  include/linux/dvb/Kbuild  |    3 -
>>  include/linux/dvb/audio.h |  135 ----------------------
>>  include/linux/dvb/osd.h   |  144 -----------------------
>>  include/linux/dvb/video.h |  276 ---------------------------------------------
>>  5 files changed, 1 insertions(+), 598 deletions(-)
>>  delete mode 100644 include/linux/dvb/audio.h
>>  delete mode 100644 include/linux/dvb/osd.h
>>  delete mode 100644 include/linux/dvb/video.h
>>
>> diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
>> index 51352de..71adea1 100644
>> --- a/fs/compat_ioctl.c
>> +++ b/fs/compat_ioctl.c
>> @@ -105,10 +105,9 @@
>>  
>>  #include <linux/hiddev.h>
>>  
>> -#include <linux/dvb/audio.h>
>> +#include <linux/av7110.h>
>>  #include <linux/dvb/dmx.h>
>>  #include <linux/dvb/frontend.h>
>> -#include <linux/dvb/video.h>
>>  
>>  #include <linux/sort.h>
>>  
>> @@ -196,32 +195,6 @@ static int do_video_stillpicture(unsigned int fd, unsigned int cmd,
>>  	return err;
>>  }
>>  
>> -struct compat_video_spu_palette {
>> -	int length;
>> -	compat_uptr_t palette;
>> -};
>> -
>> -static int do_video_set_spu_palette(unsigned int fd, unsigned int cmd,
>> -		struct compat_video_spu_palette __user *up)
>> -{
>> -	struct video_spu_palette __user *up_native;
>> -	compat_uptr_t palp;
>> -	int length, err;
>> -
>> -	err  = get_user(palp, &up->palette);
>> -	err |= get_user(length, &up->length);
>> -
>> -	up_native = compat_alloc_user_space(sizeof(struct video_spu_palette));
>> -	err  = put_user(compat_ptr(palp), &up_native->palette);
>> -	err |= put_user(length, &up_native->length);
>> -	if (err)
>> -		return -EFAULT;
>> -
>> -	err = sys_ioctl(fd, cmd, (unsigned long) up_native);
>> -
>> -	return err;
>> -}
>> -
>>  #ifdef CONFIG_BLOCK
>>  typedef struct sg_io_hdr32 {
>>  	compat_int_t interface_id;	/* [i] 'S' for SCSI generic (required) */
>> @@ -1317,9 +1290,6 @@ COMPATIBLE_IOCTL(AUDIO_CLEAR_BUFFER)
>>  COMPATIBLE_IOCTL(AUDIO_SET_ID)
>>  COMPATIBLE_IOCTL(AUDIO_SET_MIXER)
>>  COMPATIBLE_IOCTL(AUDIO_SET_STREAMTYPE)
>> -COMPATIBLE_IOCTL(AUDIO_SET_EXT_ID)
>> -COMPATIBLE_IOCTL(AUDIO_SET_ATTRIBUTES)
>> -COMPATIBLE_IOCTL(AUDIO_SET_KARAOKE)
>>  COMPATIBLE_IOCTL(DMX_START)
>>  COMPATIBLE_IOCTL(DMX_STOP)
>>  COMPATIBLE_IOCTL(DMX_SET_FILTER)
>> @@ -1358,16 +1328,9 @@ COMPATIBLE_IOCTL(VIDEO_FAST_FORWARD)
>>  COMPATIBLE_IOCTL(VIDEO_SLOWMOTION)
>>  COMPATIBLE_IOCTL(VIDEO_GET_CAPABILITIES)
>>  COMPATIBLE_IOCTL(VIDEO_CLEAR_BUFFER)
>> -COMPATIBLE_IOCTL(VIDEO_SET_ID)
>>  COMPATIBLE_IOCTL(VIDEO_SET_STREAMTYPE)
>>  COMPATIBLE_IOCTL(VIDEO_SET_FORMAT)
>> -COMPATIBLE_IOCTL(VIDEO_SET_SYSTEM)
>> -COMPATIBLE_IOCTL(VIDEO_SET_HIGHLIGHT)
>> -COMPATIBLE_IOCTL(VIDEO_SET_SPU)
>> -COMPATIBLE_IOCTL(VIDEO_GET_NAVI)
>> -COMPATIBLE_IOCTL(VIDEO_SET_ATTRIBUTES)
>>  COMPATIBLE_IOCTL(VIDEO_GET_SIZE)
>> -COMPATIBLE_IOCTL(VIDEO_GET_FRAME_RATE)
>>  
>>  /* joystick */
>>  COMPATIBLE_IOCTL(JSIOCGVERSION)
>> @@ -1468,8 +1431,6 @@ static long do_ioctl_trans(int fd, unsigned int cmd,
>>  		return do_video_get_event(fd, cmd, argp);
>>  	case VIDEO_STILLPICTURE:
>>  		return do_video_stillpicture(fd, cmd, argp);
>> -	case VIDEO_SET_SPU_PALETTE:
>> -		return do_video_set_spu_palette(fd, cmd, argp);
>>  	}
>>  
>>  	/*
>> diff --git a/include/linux/dvb/Kbuild b/include/linux/dvb/Kbuild
>> index f4dba86..f5aa137 100644
>> --- a/include/linux/dvb/Kbuild
>> +++ b/include/linux/dvb/Kbuild
>> @@ -1,8 +1,5 @@
>> -header-y += audio.h
>>  header-y += ca.h
>>  header-y += dmx.h
>>  header-y += frontend.h
>>  header-y += net.h
>> -header-y += osd.h
>>  header-y += version.h
>> -header-y += video.h
>> diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h
>> deleted file mode 100644
>> index d47bccd..0000000
>> --- a/include/linux/dvb/audio.h
>> +++ /dev/null
>> @@ -1,135 +0,0 @@
>> -/*
>> - * audio.h
>> - *
>> - * Copyright (C) 2000 Ralph  Metzler <ralph@convergence.de>
>> - *                  & Marcus Metzler <marcus@convergence.de>
>> - *                    for convergence integrated media GmbH
>> - *
>> - * This program is free software; you can redistribute it and/or
>> - * modify it under the terms of the GNU General Lesser Public License
>> - * as published by the Free Software Foundation; either version 2.1
>> - * of the License, or (at your option) any later version.
>> - *
>> - * This program is distributed in the hope that it will be useful,
>> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> - * GNU General Public License for more details.
>> - *
>> - * You should have received a copy of the GNU Lesser General Public License
>> - * along with this program; if not, write to the Free Software
>> - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
>> - *
>> - */
>> -
>> -#ifndef _DVBAUDIO_H_
>> -#define _DVBAUDIO_H_
>> -
>> -#include <linux/types.h>
>> -
>> -typedef enum {
>> -	AUDIO_SOURCE_DEMUX, /* Select the demux as the main source */
>> -	AUDIO_SOURCE_MEMORY /* Select internal memory as the main source */
>> -} audio_stream_source_t;
>> -
>> -
>> -typedef enum {
>> -	AUDIO_STOPPED,      /* Device is stopped */
>> -	AUDIO_PLAYING,      /* Device is currently playing */
>> -	AUDIO_PAUSED        /* Device is paused */
>> -} audio_play_state_t;
>> -
>> -
>> -typedef enum {
>> -	AUDIO_STEREO,
>> -	AUDIO_MONO_LEFT,
>> -	AUDIO_MONO_RIGHT,
>> -	AUDIO_MONO,
>> -	AUDIO_STEREO_SWAPPED
>> -} audio_channel_select_t;
>> -
>> -
>> -typedef struct audio_mixer {
>> -	unsigned int volume_left;
>> -	unsigned int volume_right;
>> -  // what else do we need? bass, pass-through, ...
>> -} audio_mixer_t;
>> -
>> -
>> -typedef struct audio_status {
>> -	int                    AV_sync_state;  /* sync audio and video? */
>> -	int                    mute_state;     /* audio is muted */
>> -	audio_play_state_t     play_state;     /* current playback state */
>> -	audio_stream_source_t  stream_source;  /* current stream source */
>> -	audio_channel_select_t channel_select; /* currently selected channel */
>> -	int                    bypass_mode;    /* pass on audio data to */
>> -	audio_mixer_t	       mixer_state;    /* current mixer state */
>> -} audio_status_t;                              /* separate decoder hardware */
>> -
>> -
>> -typedef
>> -struct audio_karaoke {  /* if Vocal1 or Vocal2 are non-zero, they get mixed  */
>> -	int vocal1;    /* into left and right t at 70% each */
>> -	int vocal2;    /* if both, Vocal1 and Vocal2 are non-zero, Vocal1 gets*/
>> -	int melody;    /* mixed into the left channel and */
>> -		       /* Vocal2 into the right channel at 100% each. */
>> -		       /* if Melody is non-zero, the melody channel gets mixed*/
>> -} audio_karaoke_t;     /* into left and right  */
>> -
>> -
>> -typedef __u16 audio_attributes_t;
>> -/*   bits: descr. */
>> -/*   15-13 audio coding mode (0=ac3, 2=mpeg1, 3=mpeg2ext, 4=LPCM, 6=DTS, */
>> -/*   12    multichannel extension */
>> -/*   11-10 audio type (0=not spec, 1=language included) */
>> -/*    9- 8 audio application mode (0=not spec, 1=karaoke, 2=surround) */
>> -/*    7- 6 Quantization / DRC (mpeg audio: 1=DRC exists)(lpcm: 0=16bit,  */
>> -/*    5- 4 Sample frequency fs (0=48kHz, 1=96kHz) */
>> -/*    2- 0 number of audio channels (n+1 channels) */
>> -
>> -
>> -/* for GET_CAPABILITIES and SET_FORMAT, the latter should only set one bit */
>> -#define AUDIO_CAP_DTS    1
>> -#define AUDIO_CAP_LPCM   2
>> -#define AUDIO_CAP_MP1    4
>> -#define AUDIO_CAP_MP2    8
>> -#define AUDIO_CAP_MP3   16
>> -#define AUDIO_CAP_AAC   32
>> -#define AUDIO_CAP_OGG   64
>> -#define AUDIO_CAP_SDDS 128
>> -#define AUDIO_CAP_AC3  256
>> -
>> -#define AUDIO_STOP                 _IO('o', 1)
>> -#define AUDIO_PLAY                 _IO('o', 2)
>> -#define AUDIO_PAUSE                _IO('o', 3)
>> -#define AUDIO_CONTINUE             _IO('o', 4)
>> -#define AUDIO_SELECT_SOURCE        _IO('o', 5)
>> -#define AUDIO_SET_MUTE             _IO('o', 6)
>> -#define AUDIO_SET_AV_SYNC          _IO('o', 7)
>> -#define AUDIO_SET_BYPASS_MODE      _IO('o', 8)
>> -#define AUDIO_CHANNEL_SELECT       _IO('o', 9)
>> -#define AUDIO_GET_STATUS           _IOR('o', 10, audio_status_t)
>> -
>> -#define AUDIO_GET_CAPABILITIES     _IOR('o', 11, unsigned int)
>> -#define AUDIO_CLEAR_BUFFER         _IO('o',  12)
>> -#define AUDIO_SET_ID               _IO('o', 13)
>> -#define AUDIO_SET_MIXER            _IOW('o', 14, audio_mixer_t)
>> -#define AUDIO_SET_STREAMTYPE       _IO('o', 15)
>> -#define AUDIO_SET_EXT_ID           _IO('o', 16)
>> -#define AUDIO_SET_ATTRIBUTES       _IOW('o', 17, audio_attributes_t)
>> -#define AUDIO_SET_KARAOKE          _IOW('o', 18, audio_karaoke_t)
>> -
>> -/**
>> - * AUDIO_GET_PTS
>> - *
>> - * Read the 33 bit presentation time stamp as defined
>> - * in ITU T-REC-H.222.0 / ISO/IEC 13818-1.
>> - *
>> - * The PTS should belong to the currently played
>> - * frame if possible, but may also be a value close to it
>> - * like the PTS of the last decoded frame or the last PTS
>> - * extracted by the PES parser.
>> - */
>> -#define AUDIO_GET_PTS              _IOR('o', 19, __u64)
>> -#define AUDIO_BILINGUAL_CHANNEL_SELECT _IO('o', 20)
>> -
>> -#endif /* _DVBAUDIO_H_ */
>> diff --git a/include/linux/dvb/osd.h b/include/linux/dvb/osd.h
>> deleted file mode 100644
>> index 880e684..0000000
>> --- a/include/linux/dvb/osd.h
>> +++ /dev/null
>> @@ -1,144 +0,0 @@
>> -/*
>> - * osd.h
>> - *
>> - * Copyright (C) 2001 Ralph  Metzler <ralph@convergence.de>
>> - *                  & Marcus Metzler <marcus@convergence.de>
>> - *                    for convergence integrated media GmbH
>> - *
>> - * This program is free software; you can redistribute it and/or
>> - * modify it under the terms of the GNU General Lesser Public License
>> - * as published by the Free Software Foundation; either version 2.1
>> - * of the License, or (at your option) any later version.
>> - *
>> - * This program is distributed in the hope that it will be useful,
>> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> - * GNU General Public License for more details.
>> - *
>> - * You should have received a copy of the GNU Lesser General Public License
>> - * along with this program; if not, write to the Free Software
>> - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
>> - *
>> - */
>> -
>> -#ifndef _DVBOSD_H_
>> -#define _DVBOSD_H_
>> -
>> -#include <linux/compiler.h>
>> -
>> -typedef enum {
>> -  // All functions return -2 on "not open"
>> -  OSD_Close=1,    // ()
>> -  // Disables OSD and releases the buffers
>> -  // returns 0 on success
>> -  OSD_Open,       // (x0,y0,x1,y1,BitPerPixel[2/4/8](color&0x0F),mix[0..15](color&0xF0))
>> -  // Opens OSD with this size and bit depth
>> -  // returns 0 on success, -1 on DRAM allocation error, -2 on "already open"
>> -  OSD_Show,       // ()
>> -  // enables OSD mode
>> -  // returns 0 on success
>> -  OSD_Hide,       // ()
>> -  // disables OSD mode
>> -  // returns 0 on success
>> -  OSD_Clear,      // ()
>> -  // Sets all pixel to color 0
>> -  // returns 0 on success
>> -  OSD_Fill,       // (color)
>> -  // Sets all pixel to color <col>
>> -  // returns 0 on success
>> -  OSD_SetColor,   // (color,R{x0},G{y0},B{x1},opacity{y1})
>> -  // set palette entry <num> to <r,g,b>, <mix> and <trans> apply
>> -  // R,G,B: 0..255
>> -  // R=Red, G=Green, B=Blue
>> -  // opacity=0:      pixel opacity 0% (only video pixel shows)
>> -  // opacity=1..254: pixel opacity as specified in header
>> -  // opacity=255:    pixel opacity 100% (only OSD pixel shows)
>> -  // returns 0 on success, -1 on error
>> -  OSD_SetPalette, // (firstcolor{color},lastcolor{x0},data)
>> -  // Set a number of entries in the palette
>> -  // sets the entries "firstcolor" through "lastcolor" from the array "data"
>> -  // data has 4 byte for each color:
>> -  // R,G,B, and a opacity value: 0->transparent, 1..254->mix, 255->pixel
>> -  OSD_SetTrans,   // (transparency{color})
>> -  // Sets transparency of mixed pixel (0..15)
>> -  // returns 0 on success
>> -  OSD_SetPixel,   // (x0,y0,color)
>> -  // sets pixel <x>,<y> to color number <col>
>> -  // returns 0 on success, -1 on error
>> -  OSD_GetPixel,   // (x0,y0)
>> -  // returns color number of pixel <x>,<y>,  or -1
>> -  OSD_SetRow,     // (x0,y0,x1,data)
>> -  // fills pixels x0,y through  x1,y with the content of data[]
>> -  // returns 0 on success, -1 on clipping all pixel (no pixel drawn)
>> -  OSD_SetBlock,   // (x0,y0,x1,y1,increment{color},data)
>> -  // fills pixels x0,y0 through  x1,y1 with the content of data[]
>> -  // inc contains the width of one line in the data block,
>> -  // inc<=0 uses blockwidth as linewidth
>> -  // returns 0 on success, -1 on clipping all pixel
>> -  OSD_FillRow,    // (x0,y0,x1,color)
>> -  // fills pixels x0,y through  x1,y with the color <col>
>> -  // returns 0 on success, -1 on clipping all pixel
>> -  OSD_FillBlock,  // (x0,y0,x1,y1,color)
>> -  // fills pixels x0,y0 through  x1,y1 with the color <col>
>> -  // returns 0 on success, -1 on clipping all pixel
>> -  OSD_Line,       // (x0,y0,x1,y1,color)
>> -  // draw a line from x0,y0 to x1,y1 with the color <col>
>> -  // returns 0 on success
>> -  OSD_Query,      // (x0,y0,x1,y1,xasp{color}}), yasp=11
>> -  // fills parameters with the picture dimensions and the pixel aspect ratio
>> -  // returns 0 on success
>> -  OSD_Test,       // ()
>> -  // draws a test picture. for debugging purposes only
>> -  // returns 0 on success
>> -// TODO: remove "test" in final version
>> -  OSD_Text,       // (x0,y0,size,color,text)
>> -  OSD_SetWindow, //  (x0) set window with number 0<x0<8 as current
>> -  OSD_MoveWindow, //  move current window to (x0, y0)
>> -  OSD_OpenRaw,	// Open other types of OSD windows
>> -} OSD_Command;
>> -
>> -typedef struct osd_cmd_s {
>> -	OSD_Command cmd;
>> -	int x0;
>> -	int y0;
>> -	int x1;
>> -	int y1;
>> -	int color;
>> -	void __user *data;
>> -} osd_cmd_t;
>> -
>> -/* OSD_OpenRaw: set 'color' to desired window type */
>> -typedef enum {
>> -	OSD_BITMAP1,           /* 1 bit bitmap */
>> -	OSD_BITMAP2,           /* 2 bit bitmap */
>> -	OSD_BITMAP4,           /* 4 bit bitmap */
>> -	OSD_BITMAP8,           /* 8 bit bitmap */
>> -	OSD_BITMAP1HR,         /* 1 Bit bitmap half resolution */
>> -	OSD_BITMAP2HR,         /* 2 bit bitmap half resolution */
>> -	OSD_BITMAP4HR,         /* 4 bit bitmap half resolution */
>> -	OSD_BITMAP8HR,         /* 8 bit bitmap half resolution */
>> -	OSD_YCRCB422,          /* 4:2:2 YCRCB Graphic Display */
>> -	OSD_YCRCB444,          /* 4:4:4 YCRCB Graphic Display */
>> -	OSD_YCRCB444HR,        /* 4:4:4 YCRCB graphic half resolution */
>> -	OSD_VIDEOTSIZE,        /* True Size Normal MPEG Video Display */
>> -	OSD_VIDEOHSIZE,        /* MPEG Video Display Half Resolution */
>> -	OSD_VIDEOQSIZE,        /* MPEG Video Display Quarter Resolution */
>> -	OSD_VIDEODSIZE,        /* MPEG Video Display Double Resolution */
>> -	OSD_VIDEOTHSIZE,       /* True Size MPEG Video Display Half Resolution */
>> -	OSD_VIDEOTQSIZE,       /* True Size MPEG Video Display Quarter Resolution*/
>> -	OSD_VIDEOTDSIZE,       /* True Size MPEG Video Display Double Resolution */
>> -	OSD_VIDEONSIZE,        /* Full Size MPEG Video Display */
>> -	OSD_CURSOR             /* Cursor */
>> -} osd_raw_window_t;
>> -
>> -typedef struct osd_cap_s {
>> -	int  cmd;
>> -#define OSD_CAP_MEMSIZE         1  /* memory size */
>> -	long val;
>> -} osd_cap_t;
>> -
>> -
>> -#define OSD_SEND_CMD            _IOW('o', 160, osd_cmd_t)
>> -#define OSD_GET_CAPABILITY      _IOR('o', 161, osd_cap_t)
>> -
>> -#endif
>> diff --git a/include/linux/dvb/video.h b/include/linux/dvb/video.h
>> deleted file mode 100644
>> index 1d750c0..0000000
>> --- a/include/linux/dvb/video.h
>> +++ /dev/null
>> @@ -1,276 +0,0 @@
>> -/*
>> - * video.h
>> - *
>> - * Copyright (C) 2000 Marcus Metzler <marcus@convergence.de>
>> - *                  & Ralph  Metzler <ralph@convergence.de>
>> - *                    for convergence integrated media GmbH
>> - *
>> - * This program is free software; you can redistribute it and/or
>> - * modify it under the terms of the GNU Lesser General Public License
>> - * as published by the Free Software Foundation; either version 2.1
>> - * of the License, or (at your option) any later version.
>> - *
>> - * This program is distributed in the hope that it will be useful,
>> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> - * GNU General Public License for more details.
>> - *
>> - * You should have received a copy of the GNU Lesser General Public License
>> - * along with this program; if not, write to the Free Software
>> - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
>> - *
>> - */
>> -
>> -#ifndef _DVBVIDEO_H_
>> -#define _DVBVIDEO_H_
>> -
>> -#include <linux/types.h>
>> -#ifdef __KERNEL__
>> -#include <linux/compiler.h>
>> -#else
>> -#include <stdint.h>
>> -#include <time.h>
>> -#endif
>> -
>> -typedef enum {
>> -	VIDEO_FORMAT_4_3,     /* Select 4:3 format */
>> -	VIDEO_FORMAT_16_9,    /* Select 16:9 format. */
>> -	VIDEO_FORMAT_221_1    /* 2.21:1 */
>> -} video_format_t;
>> -
>> -
>> -typedef enum {
>> -	 VIDEO_SYSTEM_PAL,
>> -	 VIDEO_SYSTEM_NTSC,
>> -	 VIDEO_SYSTEM_PALN,
>> -	 VIDEO_SYSTEM_PALNc,
>> -	 VIDEO_SYSTEM_PALM,
>> -	 VIDEO_SYSTEM_NTSC60,
>> -	 VIDEO_SYSTEM_PAL60,
>> -	 VIDEO_SYSTEM_PALM60
>> -} video_system_t;
>> -
>> -
>> -typedef enum {
>> -	VIDEO_PAN_SCAN,       /* use pan and scan format */
>> -	VIDEO_LETTER_BOX,     /* use letterbox format */
>> -	VIDEO_CENTER_CUT_OUT  /* use center cut out format */
>> -} video_displayformat_t;
>> -
>> -typedef struct {
>> -	int w;
>> -	int h;
>> -	video_format_t aspect_ratio;
>> -} video_size_t;
>> -
>> -typedef enum {
>> -	VIDEO_SOURCE_DEMUX, /* Select the demux as the main source */
>> -	VIDEO_SOURCE_MEMORY /* If this source is selected, the stream
>> -			       comes from the user through the write
>> -			       system call */
>> -} video_stream_source_t;
>> -
>> -
>> -typedef enum {
>> -	VIDEO_STOPPED, /* Video is stopped */
>> -	VIDEO_PLAYING, /* Video is currently playing */
>> -	VIDEO_FREEZED  /* Video is freezed */
>> -} video_play_state_t;
>> -
>> -
>> -/* Decoder commands */
>> -#define VIDEO_CMD_PLAY        (0)
>> -#define VIDEO_CMD_STOP        (1)
>> -#define VIDEO_CMD_FREEZE      (2)
>> -#define VIDEO_CMD_CONTINUE    (3)
>> -
>> -/* Flags for VIDEO_CMD_FREEZE */
>> -#define VIDEO_CMD_FREEZE_TO_BLACK     	(1 << 0)
>> -
>> -/* Flags for VIDEO_CMD_STOP */
>> -#define VIDEO_CMD_STOP_TO_BLACK      	(1 << 0)
>> -#define VIDEO_CMD_STOP_IMMEDIATELY     	(1 << 1)
>> -
>> -/* Play input formats: */
>> -/* The decoder has no special format requirements */
>> -#define VIDEO_PLAY_FMT_NONE         (0)
>> -/* The decoder requires full GOPs */
>> -#define VIDEO_PLAY_FMT_GOP          (1)
>> -
>> -/* The structure must be zeroed before use by the application
>> -   This ensures it can be extended safely in the future. */
>> -struct video_command {
>> -	__u32 cmd;
>> -	__u32 flags;
>> -	union {
>> -		struct {
>> -			__u64 pts;
>> -		} stop;
>> -
>> -		struct {
>> -			/* 0 or 1000 specifies normal speed,
>> -			   1 specifies forward single stepping,
>> -			   -1 specifies backward single stepping,
>> -			   >1: playback at speed/1000 of the normal speed,
>> -			   <-1: reverse playback at (-speed/1000) of the normal speed. */
>> -			__s32 speed;
>> -			__u32 format;
>> -		} play;
>> -
>> -		struct {
>> -			__u32 data[16];
>> -		} raw;
>> -	};
>> -};
>> -
>> -/* FIELD_UNKNOWN can be used if the hardware does not know whether
>> -   the Vsync is for an odd, even or progressive (i.e. non-interlaced)
>> -   field. */
>> -#define VIDEO_VSYNC_FIELD_UNKNOWN  	(0)
>> -#define VIDEO_VSYNC_FIELD_ODD 		(1)
>> -#define VIDEO_VSYNC_FIELD_EVEN		(2)
>> -#define VIDEO_VSYNC_FIELD_PROGRESSIVE	(3)
>> -
>> -struct video_event {
>> -	__s32 type;
>> -#define VIDEO_EVENT_SIZE_CHANGED	1
>> -#define VIDEO_EVENT_FRAME_RATE_CHANGED	2
>> -#define VIDEO_EVENT_DECODER_STOPPED 	3
>> -#define VIDEO_EVENT_VSYNC 		4
>> -	__kernel_time_t timestamp;
>> -	union {
>> -		video_size_t size;
>> -		unsigned int frame_rate;	/* in frames per 1000sec */
>> -		unsigned char vsync_field;	/* unknown/odd/even/progressive */
>> -	} u;
>> -};
>> -
>> -
>> -struct video_status {
>> -	int                   video_blank;   /* blank video on freeze? */
>> -	video_play_state_t    play_state;    /* current state of playback */
>> -	video_stream_source_t stream_source; /* current source (demux/memory) */
>> -	video_format_t        video_format;  /* current aspect ratio of stream*/
>> -	video_displayformat_t display_format;/* selected cropping mode */
>> -};
>> -
>> -
>> -struct video_still_picture {
>> -	char __user *iFrame;        /* pointer to a single iframe in memory */
>> -	__s32 size;
>> -};
>> -
>> -
>> -typedef
>> -struct video_highlight {
>> -	int     active;      /*    1=show highlight, 0=hide highlight */
>> -	__u8    contrast1;   /*    7- 4  Pattern pixel contrast */
>> -			     /*    3- 0  Background pixel contrast */
>> -	__u8    contrast2;   /*    7- 4  Emphasis pixel-2 contrast */
>> -			     /*    3- 0  Emphasis pixel-1 contrast */
>> -	__u8    color1;      /*    7- 4  Pattern pixel color */
>> -			     /*    3- 0  Background pixel color */
>> -	__u8    color2;      /*    7- 4  Emphasis pixel-2 color */
>> -			     /*    3- 0  Emphasis pixel-1 color */
>> -	__u32    ypos;       /*   23-22  auto action mode */
>> -			     /*   21-12  start y */
>> -			     /*    9- 0  end y */
>> -	__u32    xpos;       /*   23-22  button color number */
>> -			     /*   21-12  start x */
>> -			     /*    9- 0  end x */
>> -} video_highlight_t;
>> -
>> -
>> -typedef struct video_spu {
>> -	int active;
>> -	int stream_id;
>> -} video_spu_t;
>> -
>> -
>> -typedef struct video_spu_palette {      /* SPU Palette information */
>> -	int length;
>> -	__u8 __user *palette;
>> -} video_spu_palette_t;
>> -
>> -
>> -typedef struct video_navi_pack {
>> -	int length;          /* 0 ... 1024 */
>> -	__u8 data[1024];
>> -} video_navi_pack_t;
>> -
>> -
>> -typedef __u16 video_attributes_t;
>> -/*   bits: descr. */
>> -/*   15-14 Video compression mode (0=MPEG-1, 1=MPEG-2) */
>> -/*   13-12 TV system (0=525/60, 1=625/50) */
>> -/*   11-10 Aspect ratio (0=4:3, 3=16:9) */
>> -/*    9- 8 permitted display mode on 4:3 monitor (0=both, 1=only pan-sca */
>> -/*    7    line 21-1 data present in GOP (1=yes, 0=no) */
>> -/*    6    line 21-2 data present in GOP (1=yes, 0=no) */
>> -/*    5- 3 source resolution (0=720x480/576, 1=704x480/576, 2=352x480/57 */
>> -/*    2    source letterboxed (1=yes, 0=no) */
>> -/*    0    film/camera mode (0=camera, 1=film (625/50 only)) */
>> -
>> -
>> -/* bit definitions for capabilities: */
>> -/* can the hardware decode MPEG1 and/or MPEG2? */
>> -#define VIDEO_CAP_MPEG1   1
>> -#define VIDEO_CAP_MPEG2   2
>> -/* can you send a system and/or program stream to video device?
>> -   (you still have to open the video and the audio device but only
>> -    send the stream to the video device) */
>> -#define VIDEO_CAP_SYS     4
>> -#define VIDEO_CAP_PROG    8
>> -/* can the driver also handle SPU, NAVI and CSS encoded data?
>> -   (CSS API is not present yet) */
>> -#define VIDEO_CAP_SPU    16
>> -#define VIDEO_CAP_NAVI   32
>> -#define VIDEO_CAP_CSS    64
>> -
>> -
>> -#define VIDEO_STOP                 _IO('o', 21)
>> -#define VIDEO_PLAY                 _IO('o', 22)
>> -#define VIDEO_FREEZE               _IO('o', 23)
>> -#define VIDEO_CONTINUE             _IO('o', 24)
>> -#define VIDEO_SELECT_SOURCE        _IO('o', 25)
>> -#define VIDEO_SET_BLANK            _IO('o', 26)
>> -#define VIDEO_GET_STATUS           _IOR('o', 27, struct video_status)
>> -#define VIDEO_GET_EVENT            _IOR('o', 28, struct video_event)
>> -#define VIDEO_SET_DISPLAY_FORMAT   _IO('o', 29)
>> -#define VIDEO_STILLPICTURE         _IOW('o', 30, struct video_still_picture)
>> -#define VIDEO_FAST_FORWARD         _IO('o', 31)
>> -#define VIDEO_SLOWMOTION           _IO('o', 32)
>> -#define VIDEO_GET_CAPABILITIES     _IOR('o', 33, unsigned int)
>> -#define VIDEO_CLEAR_BUFFER         _IO('o',  34)
>> -#define VIDEO_SET_ID               _IO('o', 35)
>> -#define VIDEO_SET_STREAMTYPE       _IO('o', 36)
>> -#define VIDEO_SET_FORMAT           _IO('o', 37)
>> -#define VIDEO_SET_SYSTEM           _IO('o', 38)
>> -#define VIDEO_SET_HIGHLIGHT        _IOW('o', 39, video_highlight_t)
>> -#define VIDEO_SET_SPU              _IOW('o', 50, video_spu_t)
>> -#define VIDEO_SET_SPU_PALETTE      _IOW('o', 51, video_spu_palette_t)
>> -#define VIDEO_GET_NAVI             _IOR('o', 52, video_navi_pack_t)
>> -#define VIDEO_SET_ATTRIBUTES       _IO('o', 53)
>> -#define VIDEO_GET_SIZE             _IOR('o', 55, video_size_t)
>> -#define VIDEO_GET_FRAME_RATE       _IOR('o', 56, unsigned int)
>> -
>> -/**
>> - * VIDEO_GET_PTS
>> - *
>> - * Read the 33 bit presentation time stamp as defined
>> - * in ITU T-REC-H.222.0 / ISO/IEC 13818-1.
>> - *
>> - * The PTS should belong to the currently played
>> - * frame if possible, but may also be a value close to it
>> - * like the PTS of the last decoded frame or the last PTS
>> - * extracted by the PES parser.
>> - */
>> -#define VIDEO_GET_PTS              _IOR('o', 57, __u64)
>> -
>> -/* Read the number of displayed frames since the decoder was started */
>> -#define VIDEO_GET_FRAME_COUNT  	   _IOR('o', 58, __u64)
>> -
>> -#define VIDEO_COMMAND     	   _IOWR('o', 59, struct video_command)
>> -#define VIDEO_TRY_COMMAND 	   _IOWR('o', 60, struct video_command)
>> -
>> -#endif /*_DVBVIDEO_H_*/
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Hans Verkuil]

On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
> Don't break existing Userspace APIs for no reason! It's OK to add the
> new API, but - pretty please - don't just blindly remove audio.h and
> video.h. They are in use since many years by av7110, out-of-tree drivers
> *and more importantly* by applications. Yes, I know, you'd like to see
> those out-of-tree drivers merged, but it isn't possible for many
> reasons. And even if they were merged, you'd say "Port them and your
> apps to V4L". No! That's not an option.

I'm not breaking anything. All apps will still work.

One option (and it depends on whether people like it or not) is to have
audio.h, video.h and osd.h just include av7110.h and add a #warning
that these headers need to be replaced by the new av7110.h.

And really remove them at some point in the future.

But the important thing to realize is that the ABI hasn't changed (unless
I made a mistake somewhere).

Regards,

	Hans

> 
> Regards,
> Andreas
> 
> On 24.11.2011 14:39, Hans Verkuil wrote:
> > From: Hans Verkuil <hans.verkuil@cisco.com>
> > 
> > Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> > ---
> >  fs/compat_ioctl.c         |   41 +-------
> >  include/linux/dvb/Kbuild  |    3 -
> >  include/linux/dvb/audio.h |  135 ----------------------
> >  include/linux/dvb/osd.h   |  144 -----------------------
> >  include/linux/dvb/video.h |  276 ---------------------------------------------
> >  5 files changed, 1 insertions(+), 598 deletions(-)
> >  delete mode 100644 include/linux/dvb/audio.h
> >  delete mode 100644 include/linux/dvb/osd.h
> >  delete mode 100644 include/linux/dvb/video.h
> > 
> > diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
> > index 51352de..71adea1 100644
> > --- a/fs/compat_ioctl.c
> > +++ b/fs/compat_ioctl.c
> > @@ -105,10 +105,9 @@
> >  
> >  #include <linux/hiddev.h>
> >  
> > -#include <linux/dvb/audio.h>
> > +#include <linux/av7110.h>
> >  #include <linux/dvb/dmx.h>
> >  #include <linux/dvb/frontend.h>
> > -#include <linux/dvb/video.h>
> >  
> >  #include <linux/sort.h>
> >  
> > @@ -196,32 +195,6 @@ static int do_video_stillpicture(unsigned int fd, unsigned int cmd,
> >  	return err;
> >  }
> >  
> > -struct compat_video_spu_palette {
> > -	int length;
> > -	compat_uptr_t palette;
> > -};
> > -
> > -static int do_video_set_spu_palette(unsigned int fd, unsigned int cmd,
> > -		struct compat_video_spu_palette __user *up)
> > -{
> > -	struct video_spu_palette __user *up_native;
> > -	compat_uptr_t palp;
> > -	int length, err;
> > -
> > -	err  = get_user(palp, &up->palette);
> > -	err |= get_user(length, &up->length);
> > -
> > -	up_native = compat_alloc_user_space(sizeof(struct video_spu_palette));
> > -	err  = put_user(compat_ptr(palp), &up_native->palette);
> > -	err |= put_user(length, &up_native->length);
> > -	if (err)
> > -		return -EFAULT;
> > -
> > -	err = sys_ioctl(fd, cmd, (unsigned long) up_native);
> > -
> > -	return err;
> > -}
> > -
> >  #ifdef CONFIG_BLOCK
> >  typedef struct sg_io_hdr32 {
> >  	compat_int_t interface_id;	/* [i] 'S' for SCSI generic (required) */
> > @@ -1317,9 +1290,6 @@ COMPATIBLE_IOCTL(AUDIO_CLEAR_BUFFER)
> >  COMPATIBLE_IOCTL(AUDIO_SET_ID)
> >  COMPATIBLE_IOCTL(AUDIO_SET_MIXER)
> >  COMPATIBLE_IOCTL(AUDIO_SET_STREAMTYPE)
> > -COMPATIBLE_IOCTL(AUDIO_SET_EXT_ID)
> > -COMPATIBLE_IOCTL(AUDIO_SET_ATTRIBUTES)
> > -COMPATIBLE_IOCTL(AUDIO_SET_KARAOKE)
> >  COMPATIBLE_IOCTL(DMX_START)
> >  COMPATIBLE_IOCTL(DMX_STOP)
> >  COMPATIBLE_IOCTL(DMX_SET_FILTER)
> > @@ -1358,16 +1328,9 @@ COMPATIBLE_IOCTL(VIDEO_FAST_FORWARD)
> >  COMPATIBLE_IOCTL(VIDEO_SLOWMOTION)
> >  COMPATIBLE_IOCTL(VIDEO_GET_CAPABILITIES)
> >  COMPATIBLE_IOCTL(VIDEO_CLEAR_BUFFER)
> > -COMPATIBLE_IOCTL(VIDEO_SET_ID)
> >  COMPATIBLE_IOCTL(VIDEO_SET_STREAMTYPE)
> >  COMPATIBLE_IOCTL(VIDEO_SET_FORMAT)
> > -COMPATIBLE_IOCTL(VIDEO_SET_SYSTEM)
> > -COMPATIBLE_IOCTL(VIDEO_SET_HIGHLIGHT)
> > -COMPATIBLE_IOCTL(VIDEO_SET_SPU)
> > -COMPATIBLE_IOCTL(VIDEO_GET_NAVI)
> > -COMPATIBLE_IOCTL(VIDEO_SET_ATTRIBUTES)
> >  COMPATIBLE_IOCTL(VIDEO_GET_SIZE)
> > -COMPATIBLE_IOCTL(VIDEO_GET_FRAME_RATE)
> >  
> >  /* joystick */
> >  COMPATIBLE_IOCTL(JSIOCGVERSION)
> > @@ -1468,8 +1431,6 @@ static long do_ioctl_trans(int fd, unsigned int cmd,
> >  		return do_video_get_event(fd, cmd, argp);
> >  	case VIDEO_STILLPICTURE:
> >  		return do_video_stillpicture(fd, cmd, argp);
> > -	case VIDEO_SET_SPU_PALETTE:
> > -		return do_video_set_spu_palette(fd, cmd, argp);
> >  	}
> >  
> >  	/*
> > diff --git a/include/linux/dvb/Kbuild b/include/linux/dvb/Kbuild
> > index f4dba86..f5aa137 100644
> > --- a/include/linux/dvb/Kbuild
> > +++ b/include/linux/dvb/Kbuild
> > @@ -1,8 +1,5 @@
> > -header-y += audio.h
> >  header-y += ca.h
> >  header-y += dmx.h
> >  header-y += frontend.h
> >  header-y += net.h
> > -header-y += osd.h
> >  header-y += version.h
> > -header-y += video.h
> > diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h
> > deleted file mode 100644
> > index d47bccd..0000000
> > --- a/include/linux/dvb/audio.h
> > +++ /dev/null
> > @@ -1,135 +0,0 @@
> > -/*
> > - * audio.h
> > - *
> > - * Copyright (C) 2000 Ralph  Metzler <ralph@convergence.de>
> > - *                  & Marcus Metzler <marcus@convergence.de>
> > - *                    for convergence integrated media GmbH
> > - *
> > - * This program is free software; you can redistribute it and/or
> > - * modify it under the terms of the GNU General Lesser Public License
> > - * as published by the Free Software Foundation; either version 2.1
> > - * of the License, or (at your option) any later version.
> > - *
> > - * This program is distributed in the hope that it will be useful,
> > - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > - * GNU General Public License for more details.
> > - *
> > - * You should have received a copy of the GNU Lesser General Public License
> > - * along with this program; if not, write to the Free Software
> > - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
> > - *
> > - */
> > -
> > -#ifndef _DVBAUDIO_H_
> > -#define _DVBAUDIO_H_
> > -
> > -#include <linux/types.h>
> > -
> > -typedef enum {
> > -	AUDIO_SOURCE_DEMUX, /* Select the demux as the main source */
> > -	AUDIO_SOURCE_MEMORY /* Select internal memory as the main source */
> > -} audio_stream_source_t;
> > -
> > -
> > -typedef enum {
> > -	AUDIO_STOPPED,      /* Device is stopped */
> > -	AUDIO_PLAYING,      /* Device is currently playing */
> > -	AUDIO_PAUSED        /* Device is paused */
> > -} audio_play_state_t;
> > -
> > -
> > -typedef enum {
> > -	AUDIO_STEREO,
> > -	AUDIO_MONO_LEFT,
> > -	AUDIO_MONO_RIGHT,
> > -	AUDIO_MONO,
> > -	AUDIO_STEREO_SWAPPED
> > -} audio_channel_select_t;
> > -
> > -
> > -typedef struct audio_mixer {
> > -	unsigned int volume_left;
> > -	unsigned int volume_right;
> > -  // what else do we need? bass, pass-through, ...
> > -} audio_mixer_t;
> > -
> > -
> > -typedef struct audio_status {
> > -	int                    AV_sync_state;  /* sync audio and video? */
> > -	int                    mute_state;     /* audio is muted */
> > -	audio_play_state_t     play_state;     /* current playback state */
> > -	audio_stream_source_t  stream_source;  /* current stream source */
> > -	audio_channel_select_t channel_select; /* currently selected channel */
> > -	int                    bypass_mode;    /* pass on audio data to */
> > -	audio_mixer_t	       mixer_state;    /* current mixer state */
> > -} audio_status_t;                              /* separate decoder hardware */
> > -
> > -
> > -typedef
> > -struct audio_karaoke {  /* if Vocal1 or Vocal2 are non-zero, they get mixed  */
> > -	int vocal1;    /* into left and right t at 70% each */
> > -	int vocal2;    /* if both, Vocal1 and Vocal2 are non-zero, Vocal1 gets*/
> > -	int melody;    /* mixed into the left channel and */
> > -		       /* Vocal2 into the right channel at 100% each. */
> > -		       /* if Melody is non-zero, the melody channel gets mixed*/
> > -} audio_karaoke_t;     /* into left and right  */
> > -
> > -
> > -typedef __u16 audio_attributes_t;
> > -/*   bits: descr. */
> > -/*   15-13 audio coding mode (0=ac3, 2=mpeg1, 3=mpeg2ext, 4=LPCM, 6=DTS, */
> > -/*   12    multichannel extension */
> > -/*   11-10 audio type (0=not spec, 1=language included) */
> > -/*    9- 8 audio application mode (0=not spec, 1=karaoke, 2=surround) */
> > -/*    7- 6 Quantization / DRC (mpeg audio: 1=DRC exists)(lpcm: 0=16bit,  */
> > -/*    5- 4 Sample frequency fs (0=48kHz, 1=96kHz) */
> > -/*    2- 0 number of audio channels (n+1 channels) */
> > -
> > -
> > -/* for GET_CAPABILITIES and SET_FORMAT, the latter should only set one bit */
> > -#define AUDIO_CAP_DTS    1
> > -#define AUDIO_CAP_LPCM   2
> > -#define AUDIO_CAP_MP1    4
> > -#define AUDIO_CAP_MP2    8
> > -#define AUDIO_CAP_MP3   16
> > -#define AUDIO_CAP_AAC   32
> > -#define AUDIO_CAP_OGG   64
> > -#define AUDIO_CAP_SDDS 128
> > -#define AUDIO_CAP_AC3  256
> > -
> > -#define AUDIO_STOP                 _IO('o', 1)
> > -#define AUDIO_PLAY                 _IO('o', 2)
> > -#define AUDIO_PAUSE                _IO('o', 3)
> > -#define AUDIO_CONTINUE             _IO('o', 4)
> > -#define AUDIO_SELECT_SOURCE        _IO('o', 5)
> > -#define AUDIO_SET_MUTE             _IO('o', 6)
> > -#define AUDIO_SET_AV_SYNC          _IO('o', 7)
> > -#define AUDIO_SET_BYPASS_MODE      _IO('o', 8)
> > -#define AUDIO_CHANNEL_SELECT       _IO('o', 9)
> > -#define AUDIO_GET_STATUS           _IOR('o', 10, audio_status_t)
> > -
> > -#define AUDIO_GET_CAPABILITIES     _IOR('o', 11, unsigned int)
> > -#define AUDIO_CLEAR_BUFFER         _IO('o',  12)
> > -#define AUDIO_SET_ID               _IO('o', 13)
> > -#define AUDIO_SET_MIXER            _IOW('o', 14, audio_mixer_t)
> > -#define AUDIO_SET_STREAMTYPE       _IO('o', 15)
> > -#define AUDIO_SET_EXT_ID           _IO('o', 16)
> > -#define AUDIO_SET_ATTRIBUTES       _IOW('o', 17, audio_attributes_t)
> > -#define AUDIO_SET_KARAOKE          _IOW('o', 18, audio_karaoke_t)
> > -
> > -/**
> > - * AUDIO_GET_PTS
> > - *
> > - * Read the 33 bit presentation time stamp as defined
> > - * in ITU T-REC-H.222.0 / ISO/IEC 13818-1.
> > - *
> > - * The PTS should belong to the currently played
> > - * frame if possible, but may also be a value close to it
> > - * like the PTS of the last decoded frame or the last PTS
> > - * extracted by the PES parser.
> > - */
> > -#define AUDIO_GET_PTS              _IOR('o', 19, __u64)
> > -#define AUDIO_BILINGUAL_CHANNEL_SELECT _IO('o', 20)
> > -
> > -#endif /* _DVBAUDIO_H_ */
> > diff --git a/include/linux/dvb/osd.h b/include/linux/dvb/osd.h
> > deleted file mode 100644
> > index 880e684..0000000
> > --- a/include/linux/dvb/osd.h
> > +++ /dev/null
> > @@ -1,144 +0,0 @@
> > -/*
> > - * osd.h
> > - *
> > - * Copyright (C) 2001 Ralph  Metzler <ralph@convergence.de>
> > - *                  & Marcus Metzler <marcus@convergence.de>
> > - *                    for convergence integrated media GmbH
> > - *
> > - * This program is free software; you can redistribute it and/or
> > - * modify it under the terms of the GNU General Lesser Public License
> > - * as published by the Free Software Foundation; either version 2.1
> > - * of the License, or (at your option) any later version.
> > - *
> > - * This program is distributed in the hope that it will be useful,
> > - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > - * GNU General Public License for more details.
> > - *
> > - * You should have received a copy of the GNU Lesser General Public License
> > - * along with this program; if not, write to the Free Software
> > - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
> > - *
> > - */
> > -
> > -#ifndef _DVBOSD_H_
> > -#define _DVBOSD_H_
> > -
> > -#include <linux/compiler.h>
> > -
> > -typedef enum {
> > -  // All functions return -2 on "not open"
> > -  OSD_Close=1,    // ()
> > -  // Disables OSD and releases the buffers
> > -  // returns 0 on success
> > -  OSD_Open,       // (x0,y0,x1,y1,BitPerPixel[2/4/8](color&0x0F),mix[0..15](color&0xF0))
> > -  // Opens OSD with this size and bit depth
> > -  // returns 0 on success, -1 on DRAM allocation error, -2 on "already open"
> > -  OSD_Show,       // ()
> > -  // enables OSD mode
> > -  // returns 0 on success
> > -  OSD_Hide,       // ()
> > -  // disables OSD mode
> > -  // returns 0 on success
> > -  OSD_Clear,      // ()
> > -  // Sets all pixel to color 0
> > -  // returns 0 on success
> > -  OSD_Fill,       // (color)
> > -  // Sets all pixel to color <col>
> > -  // returns 0 on success
> > -  OSD_SetColor,   // (color,R{x0},G{y0},B{x1},opacity{y1})
> > -  // set palette entry <num> to <r,g,b>, <mix> and <trans> apply
> > -  // R,G,B: 0..255
> > -  // R=Red, G=Green, B=Blue
> > -  // opacity=0:      pixel opacity 0% (only video pixel shows)
> > -  // opacity=1..254: pixel opacity as specified in header
> > -  // opacity=255:    pixel opacity 100% (only OSD pixel shows)
> > -  // returns 0 on success, -1 on error
> > -  OSD_SetPalette, // (firstcolor{color},lastcolor{x0},data)
> > -  // Set a number of entries in the palette
> > -  // sets the entries "firstcolor" through "lastcolor" from the array "data"
> > -  // data has 4 byte for each color:
> > -  // R,G,B, and a opacity value: 0->transparent, 1..254->mix, 255->pixel
> > -  OSD_SetTrans,   // (transparency{color})
> > -  // Sets transparency of mixed pixel (0..15)
> > -  // returns 0 on success
> > -  OSD_SetPixel,   // (x0,y0,color)
> > -  // sets pixel <x>,<y> to color number <col>
> > -  // returns 0 on success, -1 on error
> > -  OSD_GetPixel,   // (x0,y0)
> > -  // returns color number of pixel <x>,<y>,  or -1
> > -  OSD_SetRow,     // (x0,y0,x1,data)
> > -  // fills pixels x0,y through  x1,y with the content of data[]
> > -  // returns 0 on success, -1 on clipping all pixel (no pixel drawn)
> > -  OSD_SetBlock,   // (x0,y0,x1,y1,increment{color},data)
> > -  // fills pixels x0,y0 through  x1,y1 with the content of data[]
> > -  // inc contains the width of one line in the data block,
> > -  // inc<=0 uses blockwidth as linewidth
> > -  // returns 0 on success, -1 on clipping all pixel
> > -  OSD_FillRow,    // (x0,y0,x1,color)
> > -  // fills pixels x0,y through  x1,y with the color <col>
> > -  // returns 0 on success, -1 on clipping all pixel
> > -  OSD_FillBlock,  // (x0,y0,x1,y1,color)
> > -  // fills pixels x0,y0 through  x1,y1 with the color <col>
> > -  // returns 0 on success, -1 on clipping all pixel
> > -  OSD_Line,       // (x0,y0,x1,y1,color)
> > -  // draw a line from x0,y0 to x1,y1 with the color <col>
> > -  // returns 0 on success
> > -  OSD_Query,      // (x0,y0,x1,y1,xasp{color}}), yasp=11
> > -  // fills parameters with the picture dimensions and the pixel aspect ratio
> > -  // returns 0 on success
> > -  OSD_Test,       // ()
> > -  // draws a test picture. for debugging purposes only
> > -  // returns 0 on success
> > -// TODO: remove "test" in final version
> > -  OSD_Text,       // (x0,y0,size,color,text)
> > -  OSD_SetWindow, //  (x0) set window with number 0<x0<8 as current
> > -  OSD_MoveWindow, //  move current window to (x0, y0)
> > -  OSD_OpenRaw,	// Open other types of OSD windows
> > -} OSD_Command;
> > -
> > -typedef struct osd_cmd_s {
> > -	OSD_Command cmd;
> > -	int x0;
> > -	int y0;
> > -	int x1;
> > -	int y1;
> > -	int color;
> > -	void __user *data;
> > -} osd_cmd_t;
> > -
> > -/* OSD_OpenRaw: set 'color' to desired window type */
> > -typedef enum {
> > -	OSD_BITMAP1,           /* 1 bit bitmap */
> > -	OSD_BITMAP2,           /* 2 bit bitmap */
> > -	OSD_BITMAP4,           /* 4 bit bitmap */
> > -	OSD_BITMAP8,           /* 8 bit bitmap */
> > -	OSD_BITMAP1HR,         /* 1 Bit bitmap half resolution */
> > -	OSD_BITMAP2HR,         /* 2 bit bitmap half resolution */
> > -	OSD_BITMAP4HR,         /* 4 bit bitmap half resolution */
> > -	OSD_BITMAP8HR,         /* 8 bit bitmap half resolution */
> > -	OSD_YCRCB422,          /* 4:2:2 YCRCB Graphic Display */
> > -	OSD_YCRCB444,          /* 4:4:4 YCRCB Graphic Display */
> > -	OSD_YCRCB444HR,        /* 4:4:4 YCRCB graphic half resolution */
> > -	OSD_VIDEOTSIZE,        /* True Size Normal MPEG Video Display */
> > -	OSD_VIDEOHSIZE,        /* MPEG Video Display Half Resolution */
> > -	OSD_VIDEOQSIZE,        /* MPEG Video Display Quarter Resolution */
> > -	OSD_VIDEODSIZE,        /* MPEG Video Display Double Resolution */
> > -	OSD_VIDEOTHSIZE,       /* True Size MPEG Video Display Half Resolution */
> > -	OSD_VIDEOTQSIZE,       /* True Size MPEG Video Display Quarter Resolution*/
> > -	OSD_VIDEOTDSIZE,       /* True Size MPEG Video Display Double Resolution */
> > -	OSD_VIDEONSIZE,        /* Full Size MPEG Video Display */
> > -	OSD_CURSOR             /* Cursor */
> > -} osd_raw_window_t;
> > -
> > -typedef struct osd_cap_s {
> > -	int  cmd;
> > -#define OSD_CAP_MEMSIZE         1  /* memory size */
> > -	long val;
> > -} osd_cap_t;
> > -
> > -
> > -#define OSD_SEND_CMD            _IOW('o', 160, osd_cmd_t)
> > -#define OSD_GET_CAPABILITY      _IOR('o', 161, osd_cap_t)
> > -
> > -#endif
> > diff --git a/include/linux/dvb/video.h b/include/linux/dvb/video.h
> > deleted file mode 100644
> > index 1d750c0..0000000
> > --- a/include/linux/dvb/video.h
> > +++ /dev/null
> > @@ -1,276 +0,0 @@
> > -/*
> > - * video.h
> > - *
> > - * Copyright (C) 2000 Marcus Metzler <marcus@convergence.de>
> > - *                  & Ralph  Metzler <ralph@convergence.de>
> > - *                    for convergence integrated media GmbH
> > - *
> > - * This program is free software; you can redistribute it and/or
> > - * modify it under the terms of the GNU Lesser General Public License
> > - * as published by the Free Software Foundation; either version 2.1
> > - * of the License, or (at your option) any later version.
> > - *
> > - * This program is distributed in the hope that it will be useful,
> > - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > - * GNU General Public License for more details.
> > - *
> > - * You should have received a copy of the GNU Lesser General Public License
> > - * along with this program; if not, write to the Free Software
> > - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
> > - *
> > - */
> > -
> > -#ifndef _DVBVIDEO_H_
> > -#define _DVBVIDEO_H_
> > -
> > -#include <linux/types.h>
> > -#ifdef __KERNEL__
> > -#include <linux/compiler.h>
> > -#else
> > -#include <stdint.h>
> > -#include <time.h>
> > -#endif
> > -
> > -typedef enum {
> > -	VIDEO_FORMAT_4_3,     /* Select 4:3 format */
> > -	VIDEO_FORMAT_16_9,    /* Select 16:9 format. */
> > -	VIDEO_FORMAT_221_1    /* 2.21:1 */
> > -} video_format_t;
> > -
> > -
> > -typedef enum {
> > -	 VIDEO_SYSTEM_PAL,
> > -	 VIDEO_SYSTEM_NTSC,
> > -	 VIDEO_SYSTEM_PALN,
> > -	 VIDEO_SYSTEM_PALNc,
> > -	 VIDEO_SYSTEM_PALM,
> > -	 VIDEO_SYSTEM_NTSC60,
> > -	 VIDEO_SYSTEM_PAL60,
> > -	 VIDEO_SYSTEM_PALM60
> > -} video_system_t;
> > -
> > -
> > -typedef enum {
> > -	VIDEO_PAN_SCAN,       /* use pan and scan format */
> > -	VIDEO_LETTER_BOX,     /* use letterbox format */
> > -	VIDEO_CENTER_CUT_OUT  /* use center cut out format */
> > -} video_displayformat_t;
> > -
> > -typedef struct {
> > -	int w;
> > -	int h;
> > -	video_format_t aspect_ratio;
> > -} video_size_t;
> > -
> > -typedef enum {
> > -	VIDEO_SOURCE_DEMUX, /* Select the demux as the main source */
> > -	VIDEO_SOURCE_MEMORY /* If this source is selected, the stream
> > -			       comes from the user through the write
> > -			       system call */
> > -} video_stream_source_t;
> > -
> > -
> > -typedef enum {
> > -	VIDEO_STOPPED, /* Video is stopped */
> > -	VIDEO_PLAYING, /* Video is currently playing */
> > -	VIDEO_FREEZED  /* Video is freezed */
> > -} video_play_state_t;
> > -
> > -
> > -/* Decoder commands */
> > -#define VIDEO_CMD_PLAY        (0)
> > -#define VIDEO_CMD_STOP        (1)
> > -#define VIDEO_CMD_FREEZE      (2)
> > -#define VIDEO_CMD_CONTINUE    (3)
> > -
> > -/* Flags for VIDEO_CMD_FREEZE */
> > -#define VIDEO_CMD_FREEZE_TO_BLACK     	(1 << 0)
> > -
> > -/* Flags for VIDEO_CMD_STOP */
> > -#define VIDEO_CMD_STOP_TO_BLACK      	(1 << 0)
> > -#define VIDEO_CMD_STOP_IMMEDIATELY     	(1 << 1)
> > -
> > -/* Play input formats: */
> > -/* The decoder has no special format requirements */
> > -#define VIDEO_PLAY_FMT_NONE         (0)
> > -/* The decoder requires full GOPs */
> > -#define VIDEO_PLAY_FMT_GOP          (1)
> > -
> > -/* The structure must be zeroed before use by the application
> > -   This ensures it can be extended safely in the future. */
> > -struct video_command {
> > -	__u32 cmd;
> > -	__u32 flags;
> > -	union {
> > -		struct {
> > -			__u64 pts;
> > -		} stop;
> > -
> > -		struct {
> > -			/* 0 or 1000 specifies normal speed,
> > -			   1 specifies forward single stepping,
> > -			   -1 specifies backward single stepping,
> > -			   >1: playback at speed/1000 of the normal speed,
> > -			   <-1: reverse playback at (-speed/1000) of the normal speed. */
> > -			__s32 speed;
> > -			__u32 format;
> > -		} play;
> > -
> > -		struct {
> > -			__u32 data[16];
> > -		} raw;
> > -	};
> > -};
> > -
> > -/* FIELD_UNKNOWN can be used if the hardware does not know whether
> > -   the Vsync is for an odd, even or progressive (i.e. non-interlaced)
> > -   field. */
> > -#define VIDEO_VSYNC_FIELD_UNKNOWN  	(0)
> > -#define VIDEO_VSYNC_FIELD_ODD 		(1)
> > -#define VIDEO_VSYNC_FIELD_EVEN		(2)
> > -#define VIDEO_VSYNC_FIELD_PROGRESSIVE	(3)
> > -
> > -struct video_event {
> > -	__s32 type;
> > -#define VIDEO_EVENT_SIZE_CHANGED	1
> > -#define VIDEO_EVENT_FRAME_RATE_CHANGED	2
> > -#define VIDEO_EVENT_DECODER_STOPPED 	3
> > -#define VIDEO_EVENT_VSYNC 		4
> > -	__kernel_time_t timestamp;
> > -	union {
> > -		video_size_t size;
> > -		unsigned int frame_rate;	/* in frames per 1000sec */
> > -		unsigned char vsync_field;	/* unknown/odd/even/progressive */
> > -	} u;
> > -};
> > -
> > -
> > -struct video_status {
> > -	int                   video_blank;   /* blank video on freeze? */
> > -	video_play_state_t    play_state;    /* current state of playback */
> > -	video_stream_source_t stream_source; /* current source (demux/memory) */
> > -	video_format_t        video_format;  /* current aspect ratio of stream*/
> > -	video_displayformat_t display_format;/* selected cropping mode */
> > -};
> > -
> > -
> > -struct video_still_picture {
> > -	char __user *iFrame;        /* pointer to a single iframe in memory */
> > -	__s32 size;
> > -};
> > -
> > -
> > -typedef
> > -struct video_highlight {
> > -	int     active;      /*    1=show highlight, 0=hide highlight */
> > -	__u8    contrast1;   /*    7- 4  Pattern pixel contrast */
> > -			     /*    3- 0  Background pixel contrast */
> > -	__u8    contrast2;   /*    7- 4  Emphasis pixel-2 contrast */
> > -			     /*    3- 0  Emphasis pixel-1 contrast */
> > -	__u8    color1;      /*    7- 4  Pattern pixel color */
> > -			     /*    3- 0  Background pixel color */
> > -	__u8    color2;      /*    7- 4  Emphasis pixel-2 color */
> > -			     /*    3- 0  Emphasis pixel-1 color */
> > -	__u32    ypos;       /*   23-22  auto action mode */
> > -			     /*   21-12  start y */
> > -			     /*    9- 0  end y */
> > -	__u32    xpos;       /*   23-22  button color number */
> > -			     /*   21-12  start x */
> > -			     /*    9- 0  end x */
> > -} video_highlight_t;
> > -
> > -
> > -typedef struct video_spu {
> > -	int active;
> > -	int stream_id;
> > -} video_spu_t;
> > -
> > -
> > -typedef struct video_spu_palette {      /* SPU Palette information */
> > -	int length;
> > -	__u8 __user *palette;
> > -} video_spu_palette_t;
> > -
> > -
> > -typedef struct video_navi_pack {
> > -	int length;          /* 0 ... 1024 */
> > -	__u8 data[1024];
> > -} video_navi_pack_t;
> > -
> > -
> > -typedef __u16 video_attributes_t;
> > -/*   bits: descr. */
> > -/*   15-14 Video compression mode (0=MPEG-1, 1=MPEG-2) */
> > -/*   13-12 TV system (0=525/60, 1=625/50) */
> > -/*   11-10 Aspect ratio (0=4:3, 3=16:9) */
> > -/*    9- 8 permitted display mode on 4:3 monitor (0=both, 1=only pan-sca */
> > -/*    7    line 21-1 data present in GOP (1=yes, 0=no) */
> > -/*    6    line 21-2 data present in GOP (1=yes, 0=no) */
> > -/*    5- 3 source resolution (0=720x480/576, 1=704x480/576, 2=352x480/57 */
> > -/*    2    source letterboxed (1=yes, 0=no) */
> > -/*    0    film/camera mode (0=camera, 1=film (625/50 only)) */
> > -
> > -
> > -/* bit definitions for capabilities: */
> > -/* can the hardware decode MPEG1 and/or MPEG2? */
> > -#define VIDEO_CAP_MPEG1   1
> > -#define VIDEO_CAP_MPEG2   2
> > -/* can you send a system and/or program stream to video device?
> > -   (you still have to open the video and the audio device but only
> > -    send the stream to the video device) */
> > -#define VIDEO_CAP_SYS     4
> > -#define VIDEO_CAP_PROG    8
> > -/* can the driver also handle SPU, NAVI and CSS encoded data?
> > -   (CSS API is not present yet) */
> > -#define VIDEO_CAP_SPU    16
> > -#define VIDEO_CAP_NAVI   32
> > -#define VIDEO_CAP_CSS    64
> > -
> > -
> > -#define VIDEO_STOP                 _IO('o', 21)
> > -#define VIDEO_PLAY                 _IO('o', 22)
> > -#define VIDEO_FREEZE               _IO('o', 23)
> > -#define VIDEO_CONTINUE             _IO('o', 24)
> > -#define VIDEO_SELECT_SOURCE        _IO('o', 25)
> > -#define VIDEO_SET_BLANK            _IO('o', 26)
> > -#define VIDEO_GET_STATUS           _IOR('o', 27, struct video_status)
> > -#define VIDEO_GET_EVENT            _IOR('o', 28, struct video_event)
> > -#define VIDEO_SET_DISPLAY_FORMAT   _IO('o', 29)
> > -#define VIDEO_STILLPICTURE         _IOW('o', 30, struct video_still_picture)
> > -#define VIDEO_FAST_FORWARD         _IO('o', 31)
> > -#define VIDEO_SLOWMOTION           _IO('o', 32)
> > -#define VIDEO_GET_CAPABILITIES     _IOR('o', 33, unsigned int)
> > -#define VIDEO_CLEAR_BUFFER         _IO('o',  34)
> > -#define VIDEO_SET_ID               _IO('o', 35)
> > -#define VIDEO_SET_STREAMTYPE       _IO('o', 36)
> > -#define VIDEO_SET_FORMAT           _IO('o', 37)
> > -#define VIDEO_SET_SYSTEM           _IO('o', 38)
> > -#define VIDEO_SET_HIGHLIGHT        _IOW('o', 39, video_highlight_t)
> > -#define VIDEO_SET_SPU              _IOW('o', 50, video_spu_t)
> > -#define VIDEO_SET_SPU_PALETTE      _IOW('o', 51, video_spu_palette_t)
> > -#define VIDEO_GET_NAVI             _IOR('o', 52, video_navi_pack_t)
> > -#define VIDEO_SET_ATTRIBUTES       _IO('o', 53)
> > -#define VIDEO_GET_SIZE             _IOR('o', 55, video_size_t)
> > -#define VIDEO_GET_FRAME_RATE       _IOR('o', 56, unsigned int)
> > -
> > -/**
> > - * VIDEO_GET_PTS
> > - *
> > - * Read the 33 bit presentation time stamp as defined
> > - * in ITU T-REC-H.222.0 / ISO/IEC 13818-1.
> > - *
> > - * The PTS should belong to the currently played
> > - * frame if possible, but may also be a value close to it
> > - * like the PTS of the last decoded frame or the last PTS
> > - * extracted by the PES parser.
> > - */
> > -#define VIDEO_GET_PTS              _IOR('o', 57, __u64)
> > -
> > -/* Read the number of displayed frames since the decoder was started */
> > -#define VIDEO_GET_FRAME_COUNT  	   _IOR('o', 58, __u64)
> > -
> > -#define VIDEO_COMMAND     	   _IOWR('o', 59, struct video_command)
> > -#define VIDEO_TRY_COMMAND 	   _IOWR('o', 60, struct video_command)
> > -
> > -#endif /*_DVBVIDEO_H_*/
> 

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Andreas Oberritter]

On 24.11.2011 18:44, Hans Verkuil wrote:
> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>> Don't break existing Userspace APIs for no reason! It's OK to add the
>> new API, but - pretty please - don't just blindly remove audio.h and
>> video.h. They are in use since many years by av7110, out-of-tree drivers
>> *and more importantly* by applications. Yes, I know, you'd like to see
>> those out-of-tree drivers merged, but it isn't possible for many
>> reasons. And even if they were merged, you'd say "Port them and your
>> apps to V4L". No! That's not an option.
> 
> I'm not breaking anything. All apps will still work.
> 
> One option (and it depends on whether people like it or not) is to have
> audio.h, video.h and osd.h just include av7110.h and add a #warning
> that these headers need to be replaced by the new av7110.h.
> 
> And really remove them at some point in the future.
> 
> But the important thing to realize is that the ABI hasn't changed (unless
> I made a mistake somewhere).

So why don't you just leave the headers where they are and add a notice
about the new V4L API as a comment?

What you proposed breaks compilation. If you add a warning, it breaks
compilation for programs compiled with -Werror. Both are regressions.

Regards,
Andreas

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 24-11-2011 15:51, Andreas Oberritter escreveu:
> On 24.11.2011 18:44, Hans Verkuil wrote:
>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>> new API, but - pretty please - don't just blindly remove audio.h and
>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>> those out-of-tree drivers merged, but it isn't possible for many
>>> reasons. And even if they were merged, you'd say "Port them and your
>>> apps to V4L". No! That's not an option.
>>
>> I'm not breaking anything. All apps will still work.
>>
>> One option (and it depends on whether people like it or not) is to have
>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>> that these headers need to be replaced by the new av7110.h.
>>
>> And really remove them at some point in the future.
>>
>> But the important thing to realize is that the ABI hasn't changed (unless
>> I made a mistake somewhere).
> 
> So why don't you just leave the headers where they are and add a notice
> about the new V4L API as a comment?
> 
> What you proposed breaks compilation. If you add a warning, it breaks
> compilation for programs compiled with -Werror. Both are regressions.

I don't mind doing it for 3.3 kernel, and add a note at
Documentation/feature-removal-schedule.txt that the
headers will go away on 3.4. This should give distributions
and app developers enough time to prevent build failures, and
prepare for the upcoming changes.

Regards,
Mauro.

> 
> Regards,
> Andreas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Manu Abraham]

On Thu, Nov 24, 2011 at 11:07 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 24-11-2011 15:08, Andreas Oberritter escreveu:
>> Don't break existing Userspace APIs for no reason! It's OK to add the
>> new API, but - pretty please - don't just blindly remove audio.h and
>> video.h. They are in use since many years by av7110, out-of-tree drivers
>> *and more importantly* by applications. Yes, I know, you'd like to see
>> those out-of-tree drivers merged, but it isn't possible for many
>> reasons. And even if they were merged, you'd say "Port them and your
>> apps to V4L". No! That's not an option.
>
> Hi Andreas,
>
> Userspace applications that support av7110 can include the new linux/av7110.h
> header. Other applications that support out-of-tree drivers can just have
> their own copy of audio.h, osd.h and video.h. So, it won't break or prevent
> existing applications to keep working.
>
> The thing is that the media API presents two interfaces to control mpeg decoders.
> This is confusing, and, while one of them has active upstream developers working
> on it, adding new drivers and new features on it, the other API is not being
> updated accordingly, and no new upstream drivers use it.
>
> Worse than that, several ioctl's are there, with not a single in-kernel implementation,
> nor any documentation about how they are supposed to work.
>
> We noticed in Prague that new DVB developers got confused about what should be the
> proper implementation for new drivers, so marking it as deprecated is important,
> otherwise, we'll end by having different approaches for the same thing.
>
> Just to give you one example, newer DTV standards like ISDB-T and DVB-T2 now uses
> H.264 video streams. Support for H.264 were added recently at V4L2 API, but the
> dvb video API doesn't support it.


That's not true at all. I am testing DVB-S2/H.264 with the current DVB API.

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Andreas Oberritter]

On 24.11.2011 18:37, Mauro Carvalho Chehab wrote:
> Em 24-11-2011 15:08, Andreas Oberritter escreveu:
>> Don't break existing Userspace APIs for no reason! It's OK to add the
>> new API, but - pretty please - don't just blindly remove audio.h and
>> video.h. They are in use since many years by av7110, out-of-tree drivers
>> *and more importantly* by applications. Yes, I know, you'd like to see
>> those out-of-tree drivers merged, but it isn't possible for many
>> reasons. And even if they were merged, you'd say "Port them and your
>> apps to V4L". No! That's not an option.
> 
> Hi Andreas,
> 
> Userspace applications that support av7110 can include the new linux/av7110.h
> header. Other applications that support out-of-tree drivers can just have
> their own copy of audio.h, osd.h and video.h. So, it won't break or prevent
> existing applications to keep working.

As already replied to Hans, breaking compilation on purpose is bad.

> The thing is that the media API presents two interfaces to control mpeg decoders.
> This is confusing, and, while one of them has active upstream developers working
> on it, adding new drivers and new features on it, the other API is not being
> updated accordingly, and no new upstream drivers use it.

There is no "media API". There's a V4L API and a DVB API. There are
active downstream developers adding new drivers and features to it.

> Worse than that, several ioctl's are there, with not a single in-kernel implementation, 
> nor any documentation about how they are supposed to work.

I think I know how most of them are supposed to work. If you have
questions, just ask.

Yes, there are many ioctls which have never been used (mostly for DVD
playback, IIRC). You can mark them as deprecated.

> We noticed in Prague that new DVB developers got confused about what should be the
> proper implementation for new drivers, so marking it as deprecated is important,
> otherwise, we'll end by having different approaches for the same thing.

There's a huge difference between marking something as deprecated and
deleting userspace header files (and compat-ioctl for that matter).

Adding a comment on top of audio.h and video.h will be good enough for
new DVB developers.

> Just to give you one example, newer DTV standards like ISDB-T and DVB-T2 now uses
> H.264 video streams. Support for H.264 were added recently at V4L2 API, but the
> dvb video API doesn't support it.

My attempts to add the necessary #defines for new video standards were
blocked because there was no in-kernel driver available. You can't use
that as an argument against it now. If you like, I can submit patches to
address this.

Regards,
Andreas

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Manu Abraham]

On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>> Don't break existing Userspace APIs for no reason! It's OK to add the
>> new API, but - pretty please - don't just blindly remove audio.h and
>> video.h. They are in use since many years by av7110, out-of-tree drivers
>> *and more importantly* by applications. Yes, I know, you'd like to see
>> those out-of-tree drivers merged, but it isn't possible for many
>> reasons. And even if they were merged, you'd say "Port them and your
>> apps to V4L". No! That's not an option.
>
> I'm not breaking anything. All apps will still work.
>
> One option (and it depends on whether people like it or not) is to have
> audio.h, video.h and osd.h just include av7110.h and add a #warning
> that these headers need to be replaced by the new av7110.h.


That won't work with other non av7110 hardware.

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Andreas Oberritter]

On 24.11.2011 18:58, Mauro Carvalho Chehab wrote:
> Em 24-11-2011 15:51, Andreas Oberritter escreveu:
>> On 24.11.2011 18:44, Hans Verkuil wrote:
>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>>> new API, but - pretty please - don't just blindly remove audio.h and
>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>>> those out-of-tree drivers merged, but it isn't possible for many
>>>> reasons. And even if they were merged, you'd say "Port them and your
>>>> apps to V4L". No! That's not an option.
>>>
>>> I'm not breaking anything. All apps will still work.
>>>
>>> One option (and it depends on whether people like it or not) is to have
>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>>> that these headers need to be replaced by the new av7110.h.
>>>
>>> And really remove them at some point in the future.
>>>
>>> But the important thing to realize is that the ABI hasn't changed (unless
>>> I made a mistake somewhere).
>>
>> So why don't you just leave the headers where they are and add a notice
>> about the new V4L API as a comment?
>>
>> What you proposed breaks compilation. If you add a warning, it breaks
>> compilation for programs compiled with -Werror. Both are regressions.
> 
> I don't mind doing it for 3.3 kernel, and add a note at
> Documentation/feature-removal-schedule.txt that the
> headers will go away on 3.4. This should give distributions
> and app developers enough time to prevent build failures, and
> prepare for the upcoming changes.

Are you serious?

Breaking things that worked well for many years - for an artificially
invented reason - is so annoying, I can't even find the words to express
how much this sucks.

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 24-11-2011 16:01, Manu Abraham escreveu:
> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>> new API, but - pretty please - don't just blindly remove audio.h and
>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>> those out-of-tree drivers merged, but it isn't possible for many
>>> reasons. And even if they were merged, you'd say "Port them and your
>>> apps to V4L". No! That's not an option.
>>
>> I'm not breaking anything. All apps will still work.
>>
>> One option (and it depends on whether people like it or not) is to have
>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>> that these headers need to be replaced by the new av7110.h.
> 
> 
> That won't work with other non av7110 hardware.

There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put
a warning at the existing headers as-is, for now, putting them to be removed
for a new kernel version, like 3.4.

Regards,
Mauro

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Manu Abraham]

On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 24-11-2011 16:01, Manu Abraham escreveu:
>> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>>> new API, but - pretty please - don't just blindly remove audio.h and
>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>>> those out-of-tree drivers merged, but it isn't possible for many
>>>> reasons. And even if they were merged, you'd say "Port them and your
>>>> apps to V4L". No! That's not an option.
>>>
>>> I'm not breaking anything. All apps will still work.
>>>
>>> One option (and it depends on whether people like it or not) is to have
>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>>> that these headers need to be replaced by the new av7110.h.
>>
>>
>> That won't work with other non av7110 hardware.
>
> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put
> a warning at the existing headers as-is, for now, putting them to be removed
> for a new kernel version, like 3.4.


No, that's not an option. The to-be merged saa716x driver depends on it.
A DVB alone device need not depend V4L2 for it's operation. Also, it doesn't
make any sense to have device specific headers to be used by an application,
when drivers share more than one commonality.

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 24-11-2011 16:07, Andreas Oberritter escreveu:
> On 24.11.2011 18:58, Mauro Carvalho Chehab wrote:
>> Em 24-11-2011 15:51, Andreas Oberritter escreveu:
>>> On 24.11.2011 18:44, Hans Verkuil wrote:
>>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>>>> new API, but - pretty please - don't just blindly remove audio.h and
>>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>>>> those out-of-tree drivers merged, but it isn't possible for many
>>>>> reasons. And even if they were merged, you'd say "Port them and your
>>>>> apps to V4L". No! That's not an option.
>>>>
>>>> I'm not breaking anything. All apps will still work.
>>>>
>>>> One option (and it depends on whether people like it or not) is to have
>>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>>>> that these headers need to be replaced by the new av7110.h.
>>>>
>>>> And really remove them at some point in the future.
>>>>
>>>> But the important thing to realize is that the ABI hasn't changed (unless
>>>> I made a mistake somewhere).
>>>
>>> So why don't you just leave the headers where they are and add a notice
>>> about the new V4L API as a comment?
>>>
>>> What you proposed breaks compilation. If you add a warning, it breaks
>>> compilation for programs compiled with -Werror. Both are regressions.
>>
>> I don't mind doing it for 3.3 kernel, and add a note at
>> Documentation/feature-removal-schedule.txt that the
>> headers will go away on 3.4. This should give distributions
>> and app developers enough time to prevent build failures, and
>> prepare for the upcoming changes.
> 
> Are you serious?
> 
> Breaking things that worked well for many years - for an artificially
> invented reason - is so annoying, I can't even find the words to express
> how much this sucks.

Andreas,

All the in-kernel API's are there to support in-kernel drivers.

Out of tree drivers can do whatever they want. As you likely know, several STB 
vendors have their own API's. 

Some use some variants of DVBv3 or DVBv5, and some use their own proprietary
API's, that are even incompatible with DVB (and some even provide both).

Even the ones that use DVBv3 (or v5) have their own implementation that diverges
from the upstream one.

Provided that such vendors don't violate the Kernel GPLv2 license where it applies, 
they're free do do whatever they want, forking the DVB API, or creating their own
stacks.

So, keeping the in-kernel unused ioctl's don't bring any real benefit, as vendors
can still do their forks, and applications designed to work with those hardware 
need to support the vendor's stack.

On the other hand, keeping an outdated API that doesn't fit well for the vendors
that want to upstream their STB drivers is bad, as it creates confusion for
them, and prevents innovation, as they may try to workaround on the limitation of
an API designed for the first generation DVB standards.

That's what Hans patches are addressing.

If you have a better approach, feel free to suggest it, provided that, at the end,
the API that aren't used by non-legacy drivers are removed (or moved to driver's
specific ioctl's).

Regards,
Mauro

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Manu Abraham]

On Thu, Nov 24, 2011 at 11:55 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 24-11-2011 16:07, Andreas Oberritter escreveu:
>> On 24.11.2011 18:58, Mauro Carvalho Chehab wrote:
>>> Em 24-11-2011 15:51, Andreas Oberritter escreveu:
>>>> On 24.11.2011 18:44, Hans Verkuil wrote:
>>>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>>>>> new API, but - pretty please - don't just blindly remove audio.h and
>>>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>>>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>>>>> those out-of-tree drivers merged, but it isn't possible for many
>>>>>> reasons. And even if they were merged, you'd say "Port them and your
>>>>>> apps to V4L". No! That's not an option.
>>>>>
>>>>> I'm not breaking anything. All apps will still work.
>>>>>
>>>>> One option (and it depends on whether people like it or not) is to have
>>>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>>>>> that these headers need to be replaced by the new av7110.h.
>>>>>
>>>>> And really remove them at some point in the future.
>>>>>
>>>>> But the important thing to realize is that the ABI hasn't changed (unless
>>>>> I made a mistake somewhere).
>>>>
>>>> So why don't you just leave the headers where they are and add a notice
>>>> about the new V4L API as a comment?
>>>>
>>>> What you proposed breaks compilation. If you add a warning, it breaks
>>>> compilation for programs compiled with -Werror. Both are regressions.
>>>
>>> I don't mind doing it for 3.3 kernel, and add a note at
>>> Documentation/feature-removal-schedule.txt that the
>>> headers will go away on 3.4. This should give distributions
>>> and app developers enough time to prevent build failures, and
>>> prepare for the upcoming changes.
>>
>> Are you serious?
>>
>> Breaking things that worked well for many years - for an artificially
>> invented reason - is so annoying, I can't even find the words to express
>> how much this sucks.
>
> Andreas,
>
> All the in-kernel API's are there to support in-kernel drivers.
>
> Out of tree drivers can do whatever they want. As you likely know, several STB
> vendors have their own API's.
>
> Some use some variants of DVBv3 or DVBv5, and some use their own proprietary
> API's, that are even incompatible with DVB (and some even provide both).
>
> Even the ones that use DVBv3 (or v5) have their own implementation that diverges
> from the upstream one.
>
> Provided that such vendors don't violate the Kernel GPLv2 license where it applies,
> they're free do do whatever they want, forking the DVB API, or creating their own
> stacks.
>
> So, keeping the in-kernel unused ioctl's don't bring any real benefit, as vendors
> can still do their forks, and applications designed to work with those hardware
> need to support the vendor's stack.


In another thread, where I requested you to revert the audio/video
ioctl removal
patch, I did chime in that those headers are in use. If you consider a
driver that's
to be merged as an out-of tree driver, then you are asking people to go away.

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 24-11-2011 16:13, Manu Abraham escreveu:
> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Em 24-11-2011 16:01, Manu Abraham escreveu:
>>> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>>>> new API, but - pretty please - don't just blindly remove audio.h and
>>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>>>> those out-of-tree drivers merged, but it isn't possible for many
>>>>> reasons. And even if they were merged, you'd say "Port them and your
>>>>> apps to V4L". No! That's not an option.
>>>>
>>>> I'm not breaking anything. All apps will still work.
>>>>
>>>> One option (and it depends on whether people like it or not) is to have
>>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>>>> that these headers need to be replaced by the new av7110.h.
>>>
>>>
>>> That won't work with other non av7110 hardware.
>>
>> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put
>> a warning at the existing headers as-is, for now, putting them to be removed
>> for a new kernel version, like 3.4.
> 
> 
> No, that's not an option. The to-be merged saa716x driver depends on it.

If the driver is not merged yet, it can be changed.

> A DVB alone device need not depend V4L2 for it's operation.

Why not? DVB drivers with IR should implement the input/event/IR API. DVB drivers with net
should implement the Linux Network API.

There is nothing wrong on using the ALSA API for audio and the V4L2 API for video,
as both API fits the needs for decoding audio and video streams, and new features
could be added there when needed.

Duplicated API's that become legacy are removed with time. Just to mention two
notable cases, this happened with the old audio stack (OSS), with the old Wireless
stack.

Do you have any issues that needs to be addressed by the V4L2 API for it to fit
on your needs?

> Also, it doesn't
> make any sense to have device specific headers to be used by an application,
> when drivers share more than one commonality.

The only in-kernel driver using audio/video/osd is av7110. There are some other
cases on driver-specific API's. The bttv and ivtv drivers used to have it. 
Their private API's were gradually replaced by other API's that are more flexible
and become standardized. In some cases, the same API that used to be private
were moved to the core API

Regards,
Mauro

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Manu Abraham]

On Fri, Nov 25, 2011 at 12:17 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 24-11-2011 16:13, Manu Abraham escreveu:
>> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab
>> <mchehab@redhat.com> wrote:
>>> Em 24-11-2011 16:01, Manu Abraham escreveu:
>>>> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>>>>> new API, but - pretty please - don't just blindly remove audio.h and
>>>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>>>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>>>>> those out-of-tree drivers merged, but it isn't possible for many
>>>>>> reasons. And even if they were merged, you'd say "Port them and your
>>>>>> apps to V4L". No! That's not an option.
>>>>>
>>>>> I'm not breaking anything. All apps will still work.
>>>>>
>>>>> One option (and it depends on whether people like it or not) is to have
>>>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>>>>> that these headers need to be replaced by the new av7110.h.
>>>>
>>>>
>>>> That won't work with other non av7110 hardware.
>>>
>>> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put
>>> a warning at the existing headers as-is, for now, putting them to be removed
>>> for a new kernel version, like 3.4.
>>
>>
>> No, that's not an option. The to-be merged saa716x driver depends on it.
>
> If the driver is not merged yet, it can be changed.
>
>> A DVB alone device need not depend V4L2 for it's operation.
>
> Why not? DVB drivers with IR should implement the input/event/IR API. DVB drivers with net
> should implement the Linux Network API.


A  DVB device having DVB alone associated with it, I see no reason for it to be
using V4L framework, while that same framework exists within DVB, just because
someone has created some artificial reasons to remove it and put it to V4L.
That's so wicked and full of politics.

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Manu Abraham]

On Fri, Nov 25, 2011 at 12:17 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 24-11-2011 16:13, Manu Abraham escreveu:
>> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab
>> <mchehab@redhat.com> wrote:
>>> Em 24-11-2011 16:01, Manu Abraham escreveu:
>>>> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>>>>> new API, but - pretty please - don't just blindly remove audio.h and
>>>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>>>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>>>>> those out-of-tree drivers merged, but it isn't possible for many
>>>>>> reasons. And even if they were merged, you'd say "Port them and your
>>>>>> apps to V4L". No! That's not an option.
>>>>>
>>>>> I'm not breaking anything. All apps will still work.
>>>>>
>>>>> One option (and it depends on whether people like it or not) is to have
>>>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>>>>> that these headers need to be replaced by the new av7110.h.
>>>>
>>>>
>>>> That won't work with other non av7110 hardware.
>>>
>>> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put
>>> a warning at the existing headers as-is, for now, putting them to be removed
>>> for a new kernel version, like 3.4.
>>
>>
>> No, that's not an option. The to-be merged saa716x driver depends on it.
>
> If the driver is not merged yet, it can be changed.


A DVB alone device shouldn't use V4L, while an existing interface exists.
I have no plans of porting the driver to use DVB and V4L, for DVB
alone operations.

Re: [RFCv2 PATCH 10/12] av7110: replace audio.h, video.h and osd.h by av7110.h.

[Oliver Endriss]

Hi,

no matter what that workshop discussed:
*** It is not acceptable to change the DVB kernel <-> user-space API! ***

Introduce whatever you want for V4L but do not touch the DVB drivers!

The av7110 driver is working for years and still in use.

I hereby NACK any attempt to remove dvb/*.h.

Nacked-by: Oliver Endriss <o.endriss@gmx.de>

CU
Oliver

On Thursday 24 November 2011 14:39:07 Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
> 
> Create a new public header, av7110.h, that contains all the av7110
> specific audio, video and osd APIs that used to be defined in dvb/audio.h,
> dvb/video.h and dvb/osd.h. These APIs are no longer part of DVBv5 but are
> now av7110-specific.
> 
> This decision was taken during the 2011 Prague V4L-DVB workshop.
> 
> Ideally av7110 would be converted to use the replacement V4L2 MPEG
> decoder API, but that's a huge job for such an old driver.
> 
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> ---
>  drivers/media/dvb/ttpci/av7110.h |    4 +-
>  include/linux/Kbuild             |    1 +
>  include/linux/av7110.h           |  609 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 611 insertions(+), 3 deletions(-)
>  create mode 100644 include/linux/av7110.h
> 
> diff --git a/drivers/media/dvb/ttpci/av7110.h b/drivers/media/dvb/ttpci/av7110.h
> index d85b851..e36d6bd 100644
> --- a/drivers/media/dvb/ttpci/av7110.h
> +++ b/drivers/media/dvb/ttpci/av7110.h
> @@ -7,11 +7,9 @@
>  #include <linux/i2c.h>
>  #include <linux/input.h>
>  
> -#include <linux/dvb/video.h>
> -#include <linux/dvb/audio.h>
> +#include <linux/av7110.h>
>  #include <linux/dvb/dmx.h>
>  #include <linux/dvb/ca.h>
> -#include <linux/dvb/osd.h>
>  #include <linux/dvb/net.h>
>  #include <linux/mutex.h>
>  
> diff --git a/include/linux/Kbuild b/include/linux/Kbuild
> index 619b565..51bd25f 100644
> --- a/include/linux/Kbuild
> +++ b/include/linux/Kbuild
> @@ -68,6 +68,7 @@ header-y += audit.h
>  header-y += auto_fs.h
>  header-y += auto_fs4.h
>  header-y += auxvec.h
> +header-y += av7110.h
>  header-y += ax25.h
>  header-y += b1lli.h
>  header-y += baycom.h
> diff --git a/include/linux/av7110.h b/include/linux/av7110.h
> new file mode 100644
> index 0000000..a192480
> --- /dev/null
> +++ b/include/linux/av7110.h
> @@ -0,0 +1,609 @@
> +/*
> + * av7110.h
> + *
> + * Copyright (C) 2000 Marcus Metzler <marcus@convergence.de>
> + *                  & Ralph  Metzler <ralph@convergence.de>
> + *                    for convergence integrated media GmbH
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public License
> + * as published by the Free Software Foundation; either version 2.1
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
> + *
> + */
> +
> +#ifndef _AV7110_API_H_
> +#define _AV7110_API_H_
> +
> +#include <linux/types.h>
> +#ifdef __KERNEL__
> +#include <linux/compiler.h>
> +#else
> +#include <stdint.h>
> +#include <time.h>
> +#endif
> +
> +
> +/* av7110 video ioctls
> + *
> + * The DVB video device controls the MPEG2 video decoder of the av7110 DVB
> + * hardware. It can be accessed through /dev/dvb/adapter0/video0.
> + *
> + * Note that the DVB video device only controls decoding of the MPEG video
> + * stream, not its presentation on the TV or computer screen. On PCs this
> + * is typically handled by an associated video4linux device, e.g. /dev/video,
> + * which allows scaling and defining output windows.
> + *Hi,

no matter what that workshop discussed:
*** It is not acceptable to change the DVB kernel <-> user-space API! ***

Introduce whatever you want for V4L but do not touch the DVB drivers!

The av7110 driver is working for years and still in use.

I hereby NACK any attempt to remove dvb/*.h.

Nacked-by: Oliver Endriss <o.endriss@gmx.de>

CU
Oliver
> + * Only one user can open the Video Device in O_RDWR mode. All other attempts
> + * to open the device in this mode will fail and an error code will be returned.
> + * If the Video Device is opened in O_RDONLY mode, the only ioctl call that can
> + * be used is VIDEO_GET_STATUS. All other calls will return with an error code.
> + *
> + * The write() system call can only be used if VIDEO_SOURCE_MEMORY is selected
> + * in the ioctl call VIDEO_SELECT_SOURCE. The data provided shall be in PES
> + * format. If O_NONBLOCK is not specified the function will block until buffer
> + * space is available. The amount of data to be transferred is implied by count.
> + */
> +
> +/** video_format_t
> + * Used in the VIDEO_SET_FORMAT ioctl to tell the driver which aspect ratio
> + * the output hardware (e.g. TV) has. It is also used in the data structures
> + * video_status returned by VIDEO_GET_STATUS and video_event returned by
> + * VIDEO_GET_EVENT which report about the display format of the current video
> + * stream.
> + */
> +typedef enum {
> +	VIDEO_FORMAT_4_3,     /* Select 4:3 format */
> +	VIDEO_FORMAT_16_9,    /* Select 16:9 format. */
> +	VIDEO_FORMAT_221_1    /* 2.21:1 */
> +} video_format_t;
> +
> +
> +/** video_displayformat_t
> + * In case the display format of the video stream and of the display hardware
> + * differ the application has to specify how to handle the cropping of the
> + * picture. This can be done using the VIDEO_SET_DISPLAY_FORMAT call.
> + */
> +typedef enum {
> +	VIDEO_PAN_SCAN,       /* use pan and scan format */
> +	VIDEO_LETTER_BOX,     /* use letterbox format */
> +	VIDEO_CENTER_CUT_OUT  /* use center cut out format */
> +} video_displayformat_t;
> +
> +typedef struct {
> +	int w;
> +	int h;
> +	video_format_t aspect_ratio;
> +} video_size_t;
> +
> +/** video_stream_source_t
> + * The video stream source is set through the VIDEO_SELECT_SOURCE call and
> + * can take the following values, depending on whether we are replaying from
> + * an internal (demuxer) or external (user write) source.
> + *
> + * VIDEO_SOURCE_DEMUX selects the demultiplexer (fed either by the frontend
> + * or the DVR device) as the source of the video stream. If VIDEO_SOURCE_MEMORY
> + * is selected the stream comes from the application through the write() system call.
> + */
> +typedef enum {
> +	VIDEO_SOURCE_DEMUX, /* Select the demux as the main source */
> +	VIDEO_SOURCE_MEMORY /* If this source is selected, the stream
> +			       comes from the user through the write
> +			       system call */
> +} video_stream_source_t;
> +
> +
> +/** video_play_state_t
> + * The following values can be returned by the VIDEO_GET_STATUS call
> + * representing the state of video playback.
> + */
> +typedef enum {
> +	VIDEO_STOPPED, /* Video is stopped */
> +	VIDEO_PLAYING, /* Video is currently playing */
> +	VIDEO_FREEZED  /* Video is freezed */
> +} video_play_state_t;
> +
> +
> +/* Decoder commands */
> +#define VIDEO_CMD_PLAY        (0)
> +#define VIDEO_CMD_STOP        (1)
> +#define VIDEO_CMD_FREEZE      (2)
> +#define VIDEO_CMD_CONTINUE    (3)
> +
> +struct video_event {
> +	__s32 type;
> +#define VIDEO_EVENT_SIZE_CHANGED	1
> +	__kernel_time_t timestamp;
> +	union {
> +		video_size_t size;
> +	} u;
> +};
> +
> +
> +/** struct video_status
> + * The VIDEO_GET_STATUS call returns this structure informing about various
> + * states of the playback operation.
> + *
> + * @video_blank: if set video will be blanked out if the channel is changed
> + * or if playback is stopped. Otherwise, the last picture will be displayed.
> + * @play_state: indicates if the video is currently frozen, stopped, or being
> + * played back.
> + * @stream_source: corresponds to the selected source for the
> + * video stream. It can come either from the demultiplexer or from memory.
> + * @video_format: indicates the aspect ratio (one of 4:3 or 16:9) of the
> + * currently played video stream.
> + * @display_format: corresponds to the selected cropping mode in case the
> + * source video format is not the same as the format of the output device.
> + */
> +struct video_status {
> +	int                   video_blank;   /* blank video on freeze? */
> +	video_play_state_t    play_state;    /* current state of playback */
> +	video_stream_source_t stream_source; /* current source (demux/memory) */
> +	video_format_t        video_format;  /* current aspect ratio of stream*/
> +	video_displayformat_t display_format;/* selected cropping mode */
> +};
> +
> +
> +/** struct video_still_picture
> + * An I-frame displayed via the VIDEO_STILLPICTURE call is passed on within the
> + * following structure.
> + */
> +struct video_still_picture {
> +	char __user *iFrame;        /* pointer to a single iframe in memory */
> +	__s32 size;
> +};
> +
> +typedef __u16 video_attributes_t;
> +/*   bits: descr. */
> +/*   15-14 Video compression mode (0=MPEG-1, 1=MPEG-2) */
> +/*   13-12 TV system (0=525/60, 1=625/50) */
> +/*   11-10 Aspect ratio (0=4:3, 3=16:9) */
> +/*    9- 8 permitted display mode on 4:3 monitor (0=both, 1=only pan-sca */
> +/*    7    line 21-1 data present in GOP (1=yes, 0=no) */
> +/*    6    line 21-2 data present in GOP (1=yes, 0=no) */
> +/*    5- 3 source resolution (0=720x480/576, 1=704x480/576, 2=352x480/57 */
> +/*    2    source letterboxed (1=yes, 0=no) */
> +/*    0    film/camera mode (0=camera, 1=film (625/50 only)) */
> +
> +
> +/* bit definitions for capabilities: */
> +/* can the hardware decode MPEG1 and/or MPEG2? */
> +#define VIDEO_CAP_MPEG1   1
> +#define VIDEO_CAP_MPEG2   2
> +/* can you send a system and/or program stream to video device?
> +   (you still have to open the video and the audio device but only
> +    send the stream to the video device) */
> +#define VIDEO_CAP_SYS     4
> +#define VIDEO_CAP_PROG    8
> +/* can the driver also handle SPU, NAVI and CSS encoded data?
> +   (CSS API is not present yet) */
> +#define VIDEO_CAP_SPU    16
> +#define VIDEO_CAP_NAVI   32
> +#define VIDEO_CAP_CSS    64
> +
> +/** VIDEO_STOP - Stop playing the current stream.
> + */
> +#define VIDEO_STOP                 _IO('o', 21)
> +
> +/** VIDEO_PLAY - Start playing a video stream from the selected source.
> + * Depending on the input parameter, the screen can be blanked out (1)
> + * or displaying the last decoded frame (0).
> + */
> +#define VIDEO_PLAY                 _IO('o', 22)
> +
> +/** VIDEO_FREEZE
> + * This ioctl call suspends the live video stream being played. Decoding and
> + * playing are frozen. It is then possible to restart the decoding and playing
> + * process of the video stream using the VIDEO_CONTINUE command. If
> + * VIDEO_SOURCE_MEMORY is selected in the ioctl call VIDEO_SELECT_SOURCE, the
> + * DVB subsystem will not decode any more data until the ioctl call
> + * VIDEO_CONTINUE or VIDEO_PLAY is performed.
> + */
> +#define VIDEO_FREEZE               _IO('o', 23)
> +
> +/** VIDEO_CONTINUE
> + * Restarts decoding and playing processes of the video stream which was played
> + * before a call to VIDEO_FREEZE was made.
> + */
> +#define VIDEO_CONTINUE             _IO('o', 24)
> +
> +/** VIDEO_SELECT_SOURCE
> + * This ioctl call informs the video device which source shall be used for the
> + * input data. The possible sources are demux or memory. If memory is selected,
> + * the data is fed to the video device through the write command.
> + */
> +#define VIDEO_SELECT_SOURCE        _IO('o', 25)
> +
> +/** VIDEO_SET_BLANK
> + * Blank out the picture (1) or show last decoded frame (0).
> + */
> +#define VIDEO_SET_BLANK            _IO('o', 26)
> +
> +/** VIDEO_GET_STATUS - Return the current status of the device.
> + */
> +#define VIDEO_GET_STATUS           _IOR('o', 27, struct video_status)
> +
> +/** VIDEO_GET_EVENT
> + * This ioctl call returns an event of type video_event if available. If an
> + * event is not available, the behavior depends on whether the device is in
> + * blocking or non-blocking mode. In the latter case, the call fails immediately
> + * with errno set to EWOULDBLOCK. In the former case, the call blocks until an
> + * event becomes available. The standard Linux poll() and/or select() system
> + * calls can be used with the device file descriptor to watch for new events.
> + * For select(), the file descriptor should be included in the exceptfds
> + * argument, and for poll(), POLLPRI should be specified as the wake-up
> + * condition. Read-only permissions are sufficient for this ioctl call.
> + */
> +#define VIDEO_GET_EVENT            _IOR('o', 28, struct video_event)
> +
> +/** VIDEO_SET_DISPLAY_FORMAT - Select the video format to be applied by the MPEG chip on the video.
> + */
> +#define VIDEO_SET_DISPLAY_FORMAT   _IO('o', 29)
> +
> +/** VIDEO_STILLPICTURE
> + * This ioctl call asks the Video Device to display a still picture (I-frame).
> + * The input data shall contain an I-frame. If the pointer is NULL, then the
> + * current displayed still picture is blanked.
> + */
> +#define VIDEO_STILLPICTURE         _IOW('o', 30, struct video_still_picture)
> +
> +/** VIDEO_FAST_FORWARD
> + * This ioctl call asks the Video Device to skip decoding of N number of
> + * I-frames. This call can only be used if VIDEO_SOURCE_MEMORY is selected.
> + */
> +#define VIDEO_FAST_FORWARD         _IO('o', 31)
> +
> +/** VIDEO_SLOWMOTION
> + * This ioctl call asks the video device to repeat decoding frames N number
> + * of times. This call can only be used if VIDEO_SOURCE_MEMORY is selected.
> + */
> +#define VIDEO_SLOWMOTION           _IO('o', 32)
> +
> +/** VIDEO_GET_CAPABILITIES
> + * This ioctl call asks the video device about its decoding capabilities.
> + * On success it returns an integer which has bits set according to the
> + * video capability defines.
> + */
> +#define VIDEO_GET_CAPABILITIES     _IOR('o', 33, unsigned int)
> +
> +/** VIDEO_CLEAR_BUFFER - Clear all video buffers in the driver and in the decoder hardware.
> + */
> +#define VIDEO_CLEAR_BUFFER         _IO('o',  34)
> +
> +/** VIDEO_SET_STREAMTYPE
> + * This ioctl tells the driver which kind of stream to expect being written
> + * to it. If this call is not used the default of video PES is used.
> + * Note: this call doesn't do anything in the av7110 driver and just returns 0.
> + */
> +#define VIDEO_SET_STREAMTYPE       _IO('o', 36)
> +
> +/** VIDEO_SET_FORMAT
> + * This ioctl sets the screen format (aspect ratio) of the connected output
> + * device (TV) so that the output of the decoder can be adjusted accordingly.
> + */
> +#define VIDEO_SET_FORMAT           _IO('o', 37)
> +
> +/** VIDEO_GET_SIZE
> + */
> +#define VIDEO_GET_SIZE             _IOR('o', 55, video_size_t)
> +
> +
> +
> +/* av7110 audio ioctls
> + *
> + * The DVB audio device controls the MPEG2 audio decoder of the av7110 DVB
> + * hardware. It can be accessed through /dev/dvb/adapter0/audio0.
> + *
> + * Only one user can open the Audio Device in O_RDWR mode. All other attempts
> + * to open the device in this mode will fail and an error code will be returned.
> + * If the Audio Device is opened in O_RDONLY mode, the only ioctl call that can
> + * be used is AUDIO_GET_STATUS. All other calls will return with an error code.
> + *
> + * The write() system call can only be used if AUDIO_SOURCE_MEMORY is selected
> + * in the ioctl call AUDIO_SELECT_SOURCE. The data provided shall be in PES
> + * format. If O_NONBLOCK is not specified the function will block until buffer
> + * space is available. The amount of data to be transferred is implied by count.
> + */
> +
> +/** audio_stream_source_t
> + *
> + * The audio stream source is set through the AUDIO_SELECT_SOURCE call and can take
> + * the following values, depending on whether we are replaying from an internal (demux) or
> + * external (user write) source.
> + *
> + * AUDIO_SOURCE_DEMUX selects the demultiplexer (fed either by the frontend or the
> + * DVR device) as the source of the video stream. If AUDIO_SOURCE_MEMORY
> + * is selected the stream comes from the application through the write() system
> + * call.
> + */
> +typedef enum {
> +	AUDIO_SOURCE_DEMUX, /* Select the demux as the main source */
> +	AUDIO_SOURCE_MEMORY /* Select internal memory as the main source */
> +} audio_stream_source_t;
> +
> +
> +/** audio_play_state_t
> + *
> + * The following values can be returned by the AUDIO_GET_STATUS call representing the
> + * state of audio playback.
> + */
> +typedef enum {
> +	AUDIO_STOPPED,      /* Device is stopped */
> +	AUDIO_PLAYING,      /* Device is currently playing */
> +	AUDIO_PAUSED        /* Device is paused */
> +} audio_play_state_t;
> +
> +
> +/** audio_channel_select_t
> + *
> + * The audio channel selected via AUDIO_CHANNEL_SELECT is determined by the
> + * following values.
> + */
> +typedef enum {
> +	AUDIO_STEREO,
> +	AUDIO_MONO_LEFT,
> +	AUDIO_MONO_RIGHT,
> +	AUDIO_MONO,
> +	AUDIO_STEREO_SWAPPED
> +} audio_channel_select_t;
> +
> +
> +/** struct audio_mixer
> + *
> + * The following structure is used by the AUDIO_SET_MIXER call to set the audio
> + * volume.
> + */
> +typedef struct audio_mixer {
> +	unsigned int volume_left;
> +	unsigned int volume_right;
> +  // what else do we need? bass, pass-through, ...
> +} audio_mixer_t;
> +
> +
> +/** struct audio_status
> + *
> + * The AUDIO_GET_STATUS call returns the following structure informing about various
> + * states of the playback operation.
> + */
> +typedef struct audio_status {
> +	int                    AV_sync_state;  /* sync audio and video? */
> +	int                    mute_state;     /* audio is muted */
> +	audio_play_state_t     play_state;     /* current playback state */
> +	audio_stream_source_t  stream_source;  /* current stream source */
> +	audio_channel_select_t channel_select; /* currently selected channel */
> +	int                    bypass_mode;    /* pass on audio data to */
> +	audio_mixer_t	       mixer_state;    /* current mixer state */
> +} audio_status_t;                              /* separate decoder hardware */
> +
> +/** audio encodings
> + *
> + * A call to AUDIO_GET_CAPABILITIES returns an unsigned integer with the following
> + * bits set according to the hardware's capabilities.
> + */
> +#define AUDIO_CAP_DTS    1
> +#define AUDIO_CAP_LPCM   2
> +#define AUDIO_CAP_MP1    4
> +#define AUDIO_CAP_MP2    8
> +#define AUDIO_CAP_MP3   16
> +#define AUDIO_CAP_AAC   32
> +#define AUDIO_CAP_OGG   64
> +#define AUDIO_CAP_SDDS 128
> +#define AUDIO_CAP_AC3  256
> +
> +/** AUDIO_STOP - Stop playing the current stream.
> + */
> +#define AUDIO_STOP                 _IO('o', 1)
> +
> +/** AUDIO_PLAY - Start playing an audio stream from the selected source.
> + */
> +#define AUDIO_PLAY                 _IO('o', 2)
> +
> +/** AUDIO_PAUSE
> + * Suspends the audio stream being played. Decoding and playing are paused.
> + * It is then possible to restart again decoding and playing process of the
> + * audio stream using AUDIO_CONTINUE command.
> + *
> + * If AUDIO_SOURCE_MEMORY is selected in the ioctl call AUDIO_SELECT_SOURCE,
> + * the DVB-subsystem will not decode (consume) any more data until the ioctl
> + * call AUDIO_CONTINUE or AUDIO_PLAY is performed.
> + */
> +#define AUDIO_PAUSE                _IO('o', 3)
> +
> +/** AUDIO_CONTINUE - Restarts the decoding and playing process previously paused with AUDIO_PAUSE command.
> + *
> + * It only works if the stream were previously stopped with AUDIO_PAUSE.
> + */
> +#define AUDIO_CONTINUE             _IO('o', 4)
> +
> +/** AUDIO_SELECT_SOURCE
> + * This ioctl call informs the audio device which source shall be used for
> + * the input data. The possible sources are demux or memory. If
> + * AUDIO_SOURCE_MEMORY is selected, the data is fed to the Audio Device
> + * through the write command.
> + */
> +#define AUDIO_SELECT_SOURCE        _IO('o', 5)
> +
> +/** AUDIO_SET_MUTE - Mute the stream that is currently being played.
> + */
> +#define AUDIO_SET_MUTE             _IO('o', 6)
> +
> +/** AUDIO_SET_AV_SYNC - Turn ON or OFF A/V synchronization.
> + */
> +#define AUDIO_SET_AV_SYNC          _IO('o', 7)
> +
> +/** AUDIO_SET_BYPASS_MODE
> + * This ioctl call asks the Audio Device to bypass the Audio decoder and forward
> + * the stream without decoding. This mode shall be used if streams that can’t be
> + * handled by the DVB system shall be decoded. Dolby DigitalTM streams are
> + * automatically forwarded by the DVB subsystem if the hardware can handle it.
> + */
> +#define AUDIO_SET_BYPASS_MODE      _IO('o', 8)
> +
> +/** AUDIO_CHANNEL_SELECT - Select the requested channel if possible.
> + */
> +#define AUDIO_CHANNEL_SELECT       _IO('o', 9)
> +
> +/** AUDIO_GET_STATUS - Return the current state of the Audio Device.
> + */
> +#define AUDIO_GET_STATUS           _IOR('o', 10, audio_status_t)
> +
> +/** AUDIO_GET_CAPABILITIES - Return the decoding capabilities of the audio hardware.
> + * Returns a bit array of supported sound formats.
> + */
> +#define AUDIO_GET_CAPABILITIES     _IOR('o', 11, unsigned int)
> +
> +/** AUDIO_CLEAR_BUFFER - Clear all software and hardware buffers of the audio decoder device.
> + */
> +#define AUDIO_CLEAR_BUFFER         _IO('o',  12)
> +
> +/** AUDIO_SET_ID
> + * This ioctl selects which sub-stream is to be decoded if a program or system
> + * stream is sent to the video device. If no audio stream type is set the id
> + * has to be in [0xC0,0xDF] for MPEG sound, in [0x80,0x87] for AC3 and in
> + * [0xA0,0xA7] for LPCM. More specifications may follow for other stream types.
> + * If the stream type is set the id just specifies the substream id of the
> + * audio stream and only the first 5 bits are recognized.
> + * Note: this call doesn't do anything in the av7110 driver and just returns 0.
> + */
> +#define AUDIO_SET_ID               _IO('o', 13)
> +
> +/** AUDIO_SET_MIXER - Adjusts the mixer settings of the audio decoder.
> + */
> +#define AUDIO_SET_MIXER            _IOW('o', 14, audio_mixer_t)
> +
> +/** AUDIO_SET_STREAMTYPE
> + * This ioctl tells the driver which kind of audio stream to expect. This is
> + * useful if the stream offers several audio sub-streams like LPCM and AC3.
> + * Note: this call doesn't do anything in the av7110 driver and just returns 0.
> + */
> +#define AUDIO_SET_STREAMTYPE       _IO('o', 15)
> +
> +
> +/* av7110 OSD ioctls */
> +
> +typedef enum {
> +  // All functions return -2 on "not open"
> +  OSD_Close=1,    // ()
> +  // Disables OSD and releases the buffers
> +  // returns 0 on success
> +  OSD_Open,       // (x0,y0,x1,y1,BitPerPixel[2/4/8](color&0x0F),mix[0..15](color&0xF0))
> +  // Opens OSD with this size and bit depth
> +  // returns 0 on success, -1 on DRAM allocation error, -2 on "already open"
> +  OSD_Show,       // ()
> +  // enables OSD mode
> +  // returns 0 on success
> +  OSD_Hide,       // ()
> +  // disables OSD mode
> +  // returns 0 on success
> +  OSD_Clear,      // ()
> +  // Sets all pixel to color 0
> +  // returns 0 on success
> +  OSD_Fill,       // (color)
> +  // Sets all pixel to color <col>
> +  // returns 0 on success
> +  OSD_SetColor,   // (color,R{x0},G{y0},B{x1},opacity{y1})
> +  // set palette entry <num> to <r,g,b>, <mix> and <trans> apply
> +  // R,G,B: 0..255
> +  // R=Red, G=Green, B=Blue
> +  // opacity=0:      pixel opacity 0% (only video pixel shows)
> +  // opacity=1..254: pixel opacity as specified in header
> +  // opacity=255:    pixel opacity 100% (only OSD pixel shows)
> +  // returns 0 on success, -1 on error
> +  OSD_SetPalette, // (firstcolor{color},lastcolor{x0},data)
> +  // Set a number of entries in the palette
> +  // sets the entries "firstcolor" through "lastcolor" from the array "data"
> +  // data has 4 byte for each color:
> +  // R,G,B, and a opacity value: 0->transparent, 1..254->mix, 255->pixel
> +  OSD_SetTrans,   // (transparency{color})
> +  // Sets transparency of mixed pixel (0..15)
> +  // returns 0 on success
> +  OSD_SetPixel,   // (x0,y0,color)
> +  // sets pixel <x>,<y> to color number <col>
> +  // returns 0 on success, -1 on error
> +  OSD_GetPixel,   // (x0,y0)
> +  // returns color number of pixel <x>,<y>,  or -1
> +  OSD_SetRow,     // (x0,y0,x1,data)
> +  // fills pixels x0,y through  x1,y with the content of data[]
> +  // returns 0 on success, -1 on clipping all pixel (no pixel drawn)
> +  OSD_SetBlock,   // (x0,y0,x1,y1,increment{color},data)
> +  // fills pixels x0,y0 through  x1,y1 with the content of data[]
> +  // inc contains the width of one line in the data block,
> +  // inc<=0 uses blockwidth as linewidth
> +  // returns 0 on success, -1 on clipping all pixel
> +  OSD_FillRow,    // (x0,y0,x1,color)
> +  // fills pixels x0,y through  x1,y with the color <col>
> +  // returns 0 on success, -1 on clipping all pixel
> +  OSD_FillBlock,  // (x0,y0,x1,y1,color)
> +  // fills pixels x0,y0 through  x1,y1 with the color <col>
> +  // returns 0 on success, -1 on clipping all pixel
> +  OSD_Line,       // (x0,y0,x1,y1,color)
> +  // draw a line from x0,y0 to x1,y1 with the color <col>
> +  // returns 0 on success
> +  OSD_Query,      // (x0,y0,x1,y1,xasp{color}}), yasp=11
> +  // fills parameters with the picture dimensions and the pixel aspect ratio
> +  // returns 0 on success
> +  OSD_Test,       // ()
> +  // draws a test picture. for debugging purposes only
> +  // returns 0 on success
> +// TODO: remove "test" in final version
> +  OSD_Text,       // (x0,y0,size,color,text)
> +  OSD_SetWindow, //  (x0) set window with number 0<x0<8 as current
> +  OSD_MoveWindow, //  move current window to (x0, y0)
> +  OSD_OpenRaw,	// Open other types of OSD windows
> +} OSD_Command;
> +
> +typedef struct osd_cmd_s {
> +	OSD_Command cmd;
> +	int x0;
> +	int y0;
> +	int x1;
> +	int y1;
> +	int color;
> +	void __user *data;
> +} osd_cmd_t;
> +
> +/* OSD_OpenRaw: set 'color' to desired window type */
> +typedef enum {
> +	OSD_BITMAP1,           /* 1 bit bitmap */
> +	OSD_BITMAP2,           /* 2 bit bitmap */
> +	OSD_BITMAP4,           /* 4 bit bitmap */
> +	OSD_BITMAP8,           /* 8 bit bitmap */
> +	OSD_BITMAP1HR,         /* 1 Bit bitmap half resolution */
> +	OSD_BITMAP2HR,         /* 2 bit bitmap half resolution */
> +	OSD_BITMAP4HR,         /* 4 bit bitmap half resolution */
> +	OSD_BITMAP8HR,         /* 8 bit bitmap half resolution */
> +	OSD_YCRCB422,          /* 4:2:2 YCRCB Graphic Display */
> +	OSD_YCRCB444,          /* 4:4:4 YCRCB Graphic Display */
> +	OSD_YCRCB444HR,        /* 4:4:4 YCRCB graphic half resolution */
> +	OSD_VIDEOTSIZE,        /* True Size Normal MPEG Video Display */
> +	OSD_VIDEOHSIZE,        /* MPEG Video Display Half Resolution */
> +	OSD_VIDEOQSIZE,        /* MPEG Video Display Quarter Resolution */
> +	OSD_VIDEODSIZE,        /* MPEG Video Display Double Resolution */
> +	OSD_VIDEOTHSIZE,       /* True Size MPEG Video Display Half Resolution */
> +	OSD_VIDEOTQSIZE,       /* True Size MPEG Video Display Quarter Resolution*/
> +	OSD_VIDEOTDSIZE,       /* True Size MPEG Video Display Double Resolution */
> +	OSD_VIDEONSIZE,        /* Full Size MPEG Video Display */
> +	OSD_CURSOR             /* Cursor */
> +} osd_raw_window_t;
> +
> +typedef struct osd_cap_s {
> +	int  cmd;
> +#define OSD_CAP_MEMSIZE         1  /* memory size */
> +	long val;
> +} osd_cap_t;
> +
> +
> +#define OSD_SEND_CMD            _IOW('o', 160, osd_cmd_t)
> +#define OSD_GET_CAPABILITY      _IOR('o', 161, osd_cap_t)
> +
> +#endif
> +

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Oliver Endriss]

Hi,

no matter what that workshop discussed:
*** It is not acceptable to change the DVB kernel <-> user-space API! ***

Introduce whatever you want for V4L but do not touch the DVB drivers!

The av7110 driver is working for years and still in use.

I hereby NACK any attempt to remove dvb/*.h.

Nacked-by: Oliver Endriss <o.endriss@gmx.de>

CU
Oliver


On Thursday 24 November 2011 14:39:09 Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
> 
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> ---
>  fs/compat_ioctl.c         |   41 +-------
>  include/linux/dvb/Kbuild  |    3 -
>  include/linux/dvb/audio.h |  135 ----------------------
>  include/linux/dvb/osd.h   |  144 -----------------------
>  include/linux/dvb/video.h |  276 ---------------------------------------------
>  5 files changed, 1 insertions(+), 598 deletions(-)
>  delete mode 100644 include/linux/dvb/audio.h
>  delete mode 100644 include/linux/dvb/osd.h
>  delete mode 100644 include/linux/dvb/video.h
> 
> diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
> index 51352de..71adea1 100644
> --- a/fs/compat_ioctl.c
> +++ b/fs/compat_ioctl.c
> @@ -105,10 +105,9 @@
>  
>  #include <linux/hiddev.h>
>  
> -#include <linux/dvb/audio.h>
> +#include <linux/av7110.h>
>  #include <linux/dvb/dmx.h>
>  #include <linux/dvb/frontend.h>
> -#include <linux/dvb/video.h>
>  
>  #include <linux/sort.h>
>  
> @@ -196,32 +195,6 @@ static int do_video_stillpicture(unsigned int fd, unsigned int cmd,
>  	return err;
>  }
>  
> -struct compat_video_spu_palette {
> -	int length;
> -	compat_uptr_t palette;
> -};
> -
> -static int do_video_set_spu_palette(unsigned int fd, unsigned int cmd,
> -		struct compat_video_spu_palette __user *up)
> -{
> -	struct video_spu_palette __user *up_native;
> -	compat_uptr_t palp;
> -	int length, err;
> -
> -	err  = get_user(palp, &up->palette);
> -	err |= get_user(length, &up->length);
> -
> -	up_native = compat_alloc_user_space(sizeof(struct video_spu_palette));
> -	err  = put_user(compat_ptr(palp), &up_native->palette);
> -	err |= put_user(length, &up_native->length);
> -	if (err)
> -		return -EFAULT;
> -
> -	err = sys_ioctl(fd, cmd, (unsigned long) up_native);
> -
> -	return err;
> -}
> -
>  #ifdef CONFIG_BLOCK
>  typedef struct sg_io_hdr32 {
>  	compat_int_t interface_id;	/* [i] 'S' for SCSI generic (required) */
> @@ -1317,9 +1290,6 @@ COMPATIBLE_IOCTL(AUDIO_CLEAR_BUFFER)
>  COMPATIBLE_IOCTL(AUDIO_SET_ID)
>  COMPATIBLE_IOCTL(AUDIO_SET_MIXER)
>  COMPATIBLE_IOCTL(AUDIO_SET_STREAMTYPE)
> -COMPATIBLE_IOCTL(AUDIO_SET_EXT_ID)
> -COMPATIBLE_IOCTL(AUDIO_SET_ATTRIBUTES)
> -COMPATIBLE_IOCTL(AUDIO_SET_KARAOKE)
>  COMPATIBLE_IOCTL(DMX_START)
>  COMPATIBLE_IOCTL(DMX_STOP)
>  COMPATIBLE_IOCTL(DMX_SET_FILTER)
> @@ -1358,16 +1328,9 @@ COMPATIBLE_IOCTL(VIDEO_FAST_FORWARD)
>  COMPATIBLE_IOCTL(VIDEO_SLOWMOTION)
>  COMPATIBLE_IOCTL(VIDEO_GET_CAPABILITIES)
>  COMPATIBLE_IOCTL(VIDEO_CLEAR_BUFFER)
> -COMPATIBLE_IOCTL(VIDEO_SET_ID)
>  COMPATIBLE_IOCTL(VIDEO_SET_STREAMTYPE)
>  COMPATIBLE_IOCTL(VIDEO_SET_FORMAT)
> -COMPATIBLE_IOCTL(VIDEO_SET_SYSTEM)
> -COMPATIBLE_IOCTL(VIDEO_SET_HIGHLIGHT)
> -COMPATIBLE_IOCTL(VIDEO_SET_SPU)
> -COMPATIBLE_IOCTL(VIDEO_GET_NAVI)
> -COMPATIBLE_IOCTL(VIDEO_SET_ATTRIBUTES)
>  COMPATIBLE_IOCTL(VIDEO_GET_SIZE)
> -COMPATIBLE_IOCTL(VIDEO_GET_FRAME_RATE)
>  
>  /* joystick */
>  COMPATIBLE_IOCTL(JSIOCGVERSION)
> @@ -1468,8 +1431,6 @@ static long do_ioctl_trans(int fd, unsigned int cmd,
>  		return do_video_get_event(fd, cmd, argp);
>  	case VIDEO_STILLPICTURE:
>  		return do_video_stillpicture(fd, cmd, argp);
> -	case VIDEO_SET_SPU_PALETTE:
> -		return do_video_set_spu_palette(fd, cmd, argp);
>  	}
>  
>  	/*
> diff --git a/include/linux/dvb/Kbuild b/include/linux/dvb/Kbuild
> index f4dba86..f5aa137 100644
> --- a/include/linux/dvb/Kbuild
> +++ b/include/linux/dvb/Kbuild
> @@ -1,8 +1,5 @@
> -header-y += audio.h
>  header-y += ca.h
>  header-y += dmx.h
>  header-y += frontend.h
>  header-y += net.h
> -header-y += osd.h
>  header-y += version.h
> -header-y += video.h
> diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h
> deleted file mode 100644
> index d47bccd..0000000
> --- a/include/linux/dvb/audio.h
> +++ /dev/null
> @@ -1,135 +0,0 @@
> -/*
> - * audio.h
> - *
> - * Copyright (C) 2000 Ralph  Metzler <ralph@convergence.de>
> - *                  & Marcus Metzler <marcus@convergence.de>
> - *                    for convergence integrated media GmbH
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Lesser Public License
> - * as published by the Free Software Foundation; either version 2.1
> - * of the License, or (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU Lesser General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
> - *
> - */
> -
> -#ifndef _DVBAUDIO_H_
> -#define _DVBAUDIO_H_
> -
> -#include <linux/types.h>
> -
> -typedef enum {
> -	AUDIO_SOURCE_DEMUX, /* Select the demux as the main source */
> -	AUDIO_SOURCE_MEMORY /* Select internal memory as the main source */
> -} audio_stream_source_t;
> -
> -
> -typedef enum {
> -	AUDIO_STOPPED,      /* Device is stopped */
> -	AUDIO_PLAYING,      /* Device is currently playing */
> -	AUDIO_PAUSED        /* Device is paused */
> -} audio_play_state_t;
> -
> -
> -typedef enum {
> -	AUDIO_STEREO,
> -	AUDIO_MONO_LEFT,
> -	AUDIO_MONO_RIGHT,
> -	AUDIO_MONO,
> -	AUDIO_STEREO_SWAPPED
> -} audio_channel_select_t;
> -
> -
> -typedef struct audio_mixer {
> -	unsigned int volume_left;
> -	unsigned int volume_right;
> -  // what else do we need? bass, pass-through, ...
> -} audio_mixer_t;
> -
> -
> -typedef struct audio_status {
> -	int                    AV_sync_state;  /* sync audio and video? */
> -	int                    mute_state;     /* audio is muted */
> -	audio_play_state_t     play_state;     /* current playback state */
> -	audio_stream_source_t  stream_source;  /* current stream source */
> -	audio_channel_select_t channel_select; /* currently selected channel */
> -	int                    bypass_mode;    /* pass on audio data to */
> -	audio_mixer_t	       mixer_state;    /* current mixer state */
> -} audio_status_t;                              /* separate decoder hardware */
> -
> -
> -typedef
> -struct audio_karaoke {  /* if Vocal1 or Vocal2 are non-zero, they get mixed  */
> -	int vocal1;    /* into left and right t at 70% each */
> -	int vocal2;    /* if both, Vocal1 and Vocal2 are non-zero, Vocal1 gets*/
> -	int melody;    /* mixed into the left channel and */
> -		       /* Vocal2 into the right channel at 100% each. */
> -		       /* if Melody is non-zero, the melody channel gets mixed*/
> -} audio_karaoke_t;     /* into left and right  */
> -
> -
> -typedef __u16 audio_attributes_t;
> -/*   bits: descr. */
> -/*   15-13 audio coding mode (0=ac3, 2=mpeg1, 3=mpeg2ext, 4=LPCM, 6=DTS, */
> -/*   12    multichannel extension */
> -/*   11-10 audio type (0=not spec, 1=language included) */
> -/*    9- 8 audio application mode (0=not spec, 1=karaoke, 2=surround) */
> -/*    7- 6 Quantization / DRC (mpeg audio: 1=DRC exists)(lpcm: 0=16bit,  */
> -/*    5- 4 Sample frequency fs (0=48kHz, 1=96kHz) */
> -/*    2- 0 number of audio channels (n+1 channels) */
> -
> -
> -/* for GET_CAPABILITIES and SET_FORMAT, the latter should only set one bit */
> -#define AUDIO_CAP_DTS    1
> -#define AUDIO_CAP_LPCM   2
> -#define AUDIO_CAP_MP1    4
> -#define AUDIO_CAP_MP2    8
> -#define AUDIO_CAP_MP3   16
> -#define AUDIO_CAP_AAC   32
> -#define AUDIO_CAP_OGG   64
> -#define AUDIO_CAP_SDDS 128
> -#define AUDIO_CAP_AC3  256
> -
> -#define AUDIO_STOP                 _IO('o', 1)
> -#define AUDIO_PLAY                 _IO('o', 2)
> -#define AUDIO_PAUSE                _IO('o', 3)
> -#define AUDIO_CONTINUE             _IO('o', 4)
> -#define AUDIO_SELECT_SOURCE        _IO('o', 5)
> -#define AUDIO_SET_MUTE             _IO('o', 6)
> -#define AUDIO_SET_AV_SYNC          _IO('o', 7)
> -#define AUDIO_SET_BYPASS_MODE      _IO('o', 8)
> -#define AUDIO_CHANNEL_SELECT       _IO('o', 9)
> -#define AUDIO_GET_STATUS           _IOR('o', 10, audio_status_t)
> -
> -#define AUDIO_GET_CAPABILITIES     _IOR('o', 11, unsigned int)
> -#define AUDIO_CLEAR_BUFFER         _IO('o',  12)
> -#define AUDIO_SET_ID               _IO('o', 13)
> -#define AUDIO_SET_MIXER            _IOW('o', 14, audio_mixer_t)
> -#define AUDIO_SET_STREAMTYPE       _IO('o', 15)
> -#define AUDIO_SET_EXT_ID           _IO('o', 16)
> -#define AUDIO_SET_ATTRIBUTES       _IOW('o', 17, audio_attributes_t)
> -#define AUDIO_SET_KARAOKE          _IOW('o', 18, audio_karaoke_t)
> -
> -/**
> - * AUDIO_GET_PTS
> - *
> - * Read the 33 bit presentation time stamp as defined
> - * in ITU T-REC-H.222.0 / ISO/IEC 13818-1.
> - *
> - * The PTS should belong to the currently played
> - * frame if possible, but may also be a value close to it
> - * like the PTS of the last decoded frame or the last PTS
> - * extracted by the PES parser.
> - */
> -#define AUDIO_GET_PTS              _IOR('o', 19, __u64)
> -#define AUDIO_BILINGUAL_CHANNEL_SELECT _IO('o', 20)
> -
> -#endif /* _DVBAUDIO_H_ */
> diff --git a/include/linux/dvb/osd.h b/include/linux/dvb/osd.h
> deleted file mode 100644
> index 880e684..0000000
> --- a/include/linux/dvb/osd.h
> +++ /dev/null
> @@ -1,144 +0,0 @@
> -/*
> - * osd.h
> - *
> - * Copyright (C) 2001 Ralph  Metzler <ralph@convergence.de>
> - *                  & Marcus Metzler <marcus@convergence.de>
> - *                    for convergence integrated media GmbH
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Lesser Public License
> - * as published by the Free Software Foundation; either version 2.1
> - * of the License, or (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU Lesser General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
> - *
> - */
> -
> -#ifndef _DVBOSD_H_
> -#define _DVBOSD_H_
> -
> -#include <linux/compiler.h>
> -
> -typedef enum {
> -  // All functions return -2 on "not open"
> -  OSD_Close=1,    // ()
> -  // Disables OSD and releases the buffers
> -  // returns 0 on success
> -  OSD_Open,       // (x0,y0,x1,y1,BitPerPixel[2/4/8](color&0x0F),mix[0..15](color&0xF0))
> -  // Opens OSD with this size and bit depth
> -  // returns 0 on success, -1 on DRAM allocation error, -2 on "already open"
> -  OSD_Show,       // ()
> -  // enables OSD mode
> -  // returns 0 on success
> -  OSD_Hide,       // ()
> -  // disables OSD mode
> -  // returns 0 on success
> -  OSD_Clear,      // ()
> -  // Sets all pixel to color 0
> -  // returns 0 on success
> -  OSD_Fill,       // (color)
> -  // Sets all pixel to color <col>
> -  // returns 0 on success
> -  OSD_SetColor,   // (color,R{x0},G{y0},B{x1},opacity{y1})
> -  // set palette entry <num> to <r,g,b>, <mix> and <trans> apply
> -  // R,G,B: 0..255
> -  // R=Red, G=Green, B=Blue
> -  // opacity=0:      pixel opacity 0% (only video pixel shows)
> -  // opacity=1..254: pixel opacity as specified in header
> -  // opacity=255:    pixel opacity 100% (only OSD pixel shows)
> -  // returns 0 on success, -1 on error
> -  OSD_SetPalette, // (firstcolor{color},lastcolor{x0},data)
> -  // Set a number of entries in the palette
> -  // sets the entries "firstcolor" through "lastcolor" from the array "data"
> -  // data has 4 byte for each color:
> -  // R,G,B, and a opacity value: 0->transparent, 1..254->mix, 255->pixel
> -  OSD_SetTrans,   // (transparency{color})
> -  // Sets transparency of mixed pixel (0..15)
> -  // returns 0 on success
> -  OSD_SetPixel,   // (x0,y0,color)
> -  // sets pixel <x>,<y> to color number <col>
> -  // returns 0 on success, -1 on error
> -  OSD_GetPixel,   // (x0,y0)
> -  // returns color number of pixel <x>,<y>,  or -1
> -  OSD_SetRow,     // (x0,y0,x1,data)
> -  // fills pixels x0,y through  x1,y with the content of data[]
> -  // returns 0 on success, -1 on clipping all pixel (no pixel drawn)
> -  OSD_SetBlock,   // (x0,y0,x1,y1,increment{color},data)
> -  // fills pixels x0,y0 through  x1,y1 with the content of data[]
> -  // inc contains the width of one line in the data block,
> -  // inc<=0 uses blockwidth as linewidth
> -  // returns 0 on success, -1 on clipping all pixel
> -  OSD_FillRow,    // (x0,y0,x1,color)
> -  // fills pixels x0,y through  x1,y with the color <col>
> -  // returns 0 on success, -1 on clipping all pixel
> -  OSD_FillBlock,  // (x0,y0,x1,y1,color)
> -  // fills pixels x0,y0 through  x1,y1 with the color <col>
> -  // returns 0 on success, -1 on clipping all pixel
> -  OSD_Line,       // (x0,y0,x1,y1,color)
> -  // draw a line from x0,y0 to x1,y1 with the color <col>
> -  // returns 0 on success
> -  OSD_Query,      // (x0,y0,x1,y1,xasp{color}}), yasp=11
> -  // fills parameters with the picture dimensions and the pixel aspect ratio
> -  // returns 0 on success
> -  OSD_Test,       // ()
> -  // draws a test picture. for debugging purposes only
> -  // returns 0 on success
> -// TODO: remove "test" in final version
> -  OSD_Text,       // (x0,y0,size,color,text)
> -  OSD_SetWindow, //  (x0) set window with number 0<x0<8 as current
> -  OSD_MoveWindow, //  move current window to (x0, y0)
> -  OSD_OpenRaw,	// Open other types of OSD windows
> -} OSD_Command;
> -
> -typedef struct osd_cmd_s {
> -	OSD_Command cmd;
> -	int x0;
> -	int y0;
> -	int x1;
> -	int y1;
> -	int color;
> -	void __user *data;
> -} osd_cmd_t;
> -
> -/* OSD_OpenRaw: set 'color' to desired window type */
> -typedef enum {
> -	OSD_BITMAP1,           /* 1 bit bitmap */
> -	OSD_BITMAP2,           /* 2 bit bitmap */
> -	OSD_BITMAP4,           /* 4 bit bitmap */
> -	OSD_BITMAP8,           /* 8 bit bitmap */
> -	OSD_BITMAP1HR,         /* 1 Bit bitmap half resolution */
> -	OSD_BITMAP2HR,         /* 2 bit bitmap half resolution */
> -	OSD_BITMAP4HR,         /* 4 bit bitmap half resolution */
> -	OSD_BITMAP8HR,         /* 8 bit bitmap half resolution */
> -	OSD_YCRCB422,          /* 4:2:2 YCRCB Graphic Display */
> -	OSD_YCRCB444,          /* 4:4:4 YCRCB Graphic Display */
> -	OSD_YCRCB444HR,        /* 4:4:4 YCRCB graphic half resolution */
> -	OSD_VIDEOTSIZE,        /* True Size Normal MPEG Video Display */
> -	OSD_VIDEOHSIZE,        /* MPEG Video Display Half Resolution */
> -	OSD_VIDEOQSIZE,        /* MPEG Video Display Quarter Resolution */
> -	OSD_VIDEODSIZE,        /* MPEG Video Display Double Resolution */
> -	OSD_VIDEOTHSIZE,       /* True Size MPEG Video Display Half Resolution */
> -	OSD_VIDEOTQSIZE,       /* True Size MPEG Video Display Quarter Resolution*/
> -	OSD_VIDEOTDSIZE,       /* True Size MPEG Video Display Double Resolution */
> -	OSD_VIDEONSIZE,        /* Full Size MPEG Video Display */
> -	OSD_CURSOR             /* Cursor */
> -} osd_raw_window_t;
> -
> -typedef struct osd_cap_s {
> -	int  cmd;
> -#define OSD_CAP_MEMSIZE         1  /* memory size */
> -	long val;
> -} osd_cap_t;
> -
> -
> -#define OSD_SEND_CMD            _IOW('o', 160, osd_cmd_t)
> -#define OSD_GET_CAPABILITY      _IOR('o', 161, osd_cap_t)
> -
> -#endif
> diff --git a/include/linux/dvb/video.h b/include/linux/dvb/video.h
> deleted file mode 100644
> index 1d750c0..0000000
> --- a/include/linux/dvb/video.h
> +++ /dev/null
> @@ -1,276 +0,0 @@
> -/*
> - * video.h
> - *
> - * Copyright (C) 2000 Marcus Metzler <marcus@convergence.de>
> - *                  & Ralph  Metzler <ralph@convergence.de>
> - *                    for convergence integrated media GmbH
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU Lesser General Public License
> - * as published by the Free Software Foundation; either version 2.1
> - * of the License, or (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU Lesser General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
> - *
> - */
> -
> -#ifndef _DVBVIDEO_H_
> -#define _DVBVIDEO_H_
> -
> -#include <linux/types.h>
> -#ifdef __KERNEL__
> -#include <linux/compiler.h>
> -#else
> -#include <stdint.h>
> -#include <time.h>
> -#endif
> -
> -typedef enum {
> -	VIDEO_FORMAT_4_3,     /* Select 4:3 format */
> -	VIDEO_FORMAT_16_9,    /* Select 16:9 format. */
> -	VIDEO_FORMAT_221_1    /* 2.21:1 */
> -} video_format_t;
> -
> -
> -typedef enum {
> -	 VIDEO_SYSTEM_PAL,
> -	 VIDEO_SYSTEM_NTSC,
> -	 VIDEO_SYSTEM_PALN,
> -	 VIDEO_SYSTEM_PALNc,
> -	 VIDEO_SYSTEM_PALM,
> -	 VIDEO_SYSTEM_NTSC60,
> -	 VIDEO_SYSTEM_PAL60,
> -	 VIDEO_SYSTEM_PALM60
> -} video_system_t;
> -
> -
> -typedef enum {
> -	VIDEO_PAN_SCAN,       /* use pan and scan format */
> -	VIDEO_LETTER_BOX,     /* use letterbox format */
> -	VIDEO_CENTER_CUT_OUT  /* use center cut out format */
> -} video_displayformat_t;
> -
> -typedef struct {
> -	int w;
> -	int h;
> -	video_format_t aspect_ratio;
> -} video_size_t;
> -
> -typedef enum {
> -	VIDEO_SOURCE_DEMUX, /* Select the demux as the main source */
> -	VIDEO_SOURCE_MEMORY /* If this source is selected, the stream
> -			       comes from the user through the write
> -			       system call */
> -} video_stream_source_t;
> -
> -
> -typedef enum {
> -	VIDEO_STOPPED, /* Video is stopped */
> -	VIDEO_PLAYING, /* Video is currently playing */
> -	VIDEO_FREEZED  /* Video is freezed */
> -} video_play_state_t;
> -
> -
> -/* Decoder commands */
> -#define VIDEO_CMD_PLAY        (0)
> -#define VIDEO_CMD_STOP        (1)
> -#define VIDEO_CMD_FREEZE      (2)
> -#define VIDEO_CMD_CONTINUE    (3)
> -
> -/* Flags for VIDEO_CMD_FREEZE */
> -#define VIDEO_CMD_FREEZE_TO_BLACK     	(1 << 0)
> -
> -/* Flags for VIDEO_CMD_STOP */
> -#define VIDEO_CMD_STOP_TO_BLACK      	(1 << 0)
> -#define VIDEO_CMD_STOP_IMMEDIATELY     	(1 << 1)
> -
> -/* Play input formats: */
> -/* The decoder has no special format requirements */
> -#define VIDEO_PLAY_FMT_NONE         (0)
> -/* The decoder requires full GOPs */
> -#define VIDEO_PLAY_FMT_GOP          (1)
> -
> -/* The structure must be zeroed before use by the application
> -   This ensures it can be extended safely in the future. */
> -struct video_command {
> -	__u32 cmd;
> -	__u32 flags;
> -	union {
> -		struct {
> -			__u64 pts;
> -		} stop;
> -
> -		struct {
> -			/* 0 or 1000 specifies normal speed,
> -			   1 specifies forward single stepping,
> -			   -1 specifies backward single stepping,
> -			   >1: playback at speed/1000 of the normal speed,
> -			   <-1: reverse playback at (-speed/1000) of the normal speed. */
> -			__s32 speed;
> -			__u32 format;
> -		} play;
> -
> -		struct {
> -			__u32 data[16];
> -		} raw;
> -	};
> -};
> -
> -/* FIELD_UNKNOWN can be used if the hardware does not know whether
> -   the Vsync is for an odd, even or progressive (i.e. non-interlaced)
> -   field. */
> -#define VIDEO_VSYNC_FIELD_UNKNOWN  	(0)
> -#define VIDEO_VSYNC_FIELD_ODD 		(1)
> -#define VIDEO_VSYNC_FIELD_EVEN		(2)
> -#define VIDEO_VSYNC_FIELD_PROGRESSIVE	(3)
> -
> -struct video_event {
> -	__s32 type;
> -#define VIDEO_EVENT_SIZE_CHANGED	1
> -#define VIDEO_EVENT_FRAME_RATE_CHANGED	2
> -#define VIDEO_EVENT_DECODER_STOPPED 	3
> -#define VIDEO_EVENT_VSYNC 		4
> -	__kernel_time_t timestamp;
> -	union {
> -		video_size_t size;
> -		unsigned int frame_rate;	/* in frames per 1000sec */
> -		unsigned char vsync_field;	/* unknown/odd/even/progressive */
> -	} u;
> -};
> -
> -
> -struct video_status {
> -	int                   video_blank;   /* blank video on freeze? */
> -	video_play_state_t    play_state;    /* current state of playback */
> -	video_stream_source_t stream_source; /* current source (demux/memory) */
> -	video_format_t        video_format;  /* current aspect ratio of stream*/
> -	video_displayformat_t display_format;/* selected cropping mode */
> -};
> -
> -
> -struct video_still_picture {
> -	char __user *iFrame;        /* pointer to a single iframe in memory */
> -	__s32 size;
> -};
> -
> -
> -typedef
> -struct video_highlight {
> -	int     active;      /*    1=show highlight, 0=hide highlight */
> -	__u8    contrast1;   /*    7- 4  Pattern pixel contrast */
> -			     /*    3- 0  Background pixel contrast */
> -	__u8    contrast2;   /*    7- 4  Emphasis pixel-2 contrast */
> -			     /*    3- 0  Emphasis pixel-1 contrast */
> -	__u8    color1;      /*    7- 4  Pattern pixel color */
> -			     /*    3- 0  Background pixel color */
> -	__u8    color2;      /*    7- 4  Emphasis pixel-2 color */
> -			     /*    3- 0  Emphasis pixel-1 color */
> -	__u32    ypos;       /*   23-22  auto action mode */
> -			     /*   21-12  start y */
> -			     /*    9- 0  end y */
> -	__u32    xpos;       /*   23-22  button color number */
> -			     /*   21-12  start x */
> -			     /*    9- 0  end x */
> -} video_highlight_t;
> -
> -
> -typedef struct video_spu {
> -	int active;
> -	int stream_id;
> -} video_spu_t;
> -
> -
> -typedef struct video_spu_palette {      /* SPU Palette information */
> -	int length;
> -	__u8 __user *palette;
> -} video_spu_palette_t;
> -
> -
> -typedef struct video_navi_pack {
> -	int length;          /* 0 ... 1024 */
> -	__u8 data[1024];
> -} video_navi_pack_t;
> -
> -
> -typedef __u16 video_attributes_t;
> -/*   bits: descr. */
> -/*   15-14 Video compression mode (0=MPEG-1, 1=MPEG-2) */
> -/*   13-12 TV system (0=525/60, 1=625/50) */
> -/*   11-10 Aspect ratio (0=4:3, 3=16:9) */
> -/*    9- 8 permitted display mode on 4:3 monitor (0=both, 1=only pan-sca */
> -/*    7    line 21-1 data present in GOP (1=yes, 0=no) */
> -/*    6    line 21-2 data present in GOP (1=yes, 0=no) */
> -/*    5- 3 source resolution (0=720x480/576, 1=704x480/576, 2=352x480/57 */
> -/*    2    source letterboxed (1=yes, 0=no) */
> -/*    0    film/camera mode (0=camera, 1=film (625/50 only)) */
> -
> -
> -/* bit definitions for capabilities: */
> -/* can the hardware decode MPEG1 and/or MPEG2? */
> -#define VIDEO_CAP_MPEG1   1
> -#define VIDEO_CAP_MPEG2   2
> -/* can you send a system and/or program stream to video device?
> -   (you still have to open the video and the audio device but only
> -    send the stream to the video device) */
> -#define VIDEO_CAP_SYS     4
> -#define VIDEO_CAP_PROG    8
> -/* can the driver also handle SPU, NAVI and CSS encoded data?
> -   (CSS API is not present yet) */
> -#define VIDEO_CAP_SPU    16
> -#define VIDEO_CAP_NAVI   32
> -#define VIDEO_CAP_CSS    64
> -
> -
> -#define VIDEO_STOP                 _IO('o', 21)
> -#define VIDEO_PLAY                 _IO('o', 22)
> -#define VIDEO_FREEZE               _IO('o', 23)
> -#define VIDEO_CONTINUE             _IO('o', 24)
> -#define VIDEO_SELECT_SOURCE        _IO('o', 25)
> -#define VIDEO_SET_BLANK            _IO('o', 26)
> -#define VIDEO_GET_STATUS           _IOR('o', 27, struct video_status)
> -#define VIDEO_GET_EVENT            _IOR('o', 28, struct video_event)
> -#define VIDEO_SET_DISPLAY_FORMAT   _IO('o', 29)
> -#define VIDEO_STILLPICTURE         _IOW('o', 30, struct video_still_picture)
> -#define VIDEO_FAST_FORWARD         _IO('o', 31)
> -#define VIDEO_SLOWMOTION           _IO('o', 32)
> -#define VIDEO_GET_CAPABILITIES     _IOR('o', 33, unsigned int)
> -#define VIDEO_CLEAR_BUFFER         _IO('o',  34)
> -#define VIDEO_SET_ID               _IO('o', 35)
> -#define VIDEO_SET_STREAMTYPE       _IO('o', 36)
> -#define VIDEO_SET_FORMAT           _IO('o', 37)
> -#define VIDEO_SET_SYSTEM           _IO('o', 38)
> -#define VIDEO_SET_HIGHLIGHT        _IOW('o', 39, video_highlight_t)
> -#define VIDEO_SET_SPU              _IOW('o', 50, video_spu_t)
> -#define VIDEO_SET_SPU_PALETTE      _IOW('o', 51, video_spu_palette_t)
> -#define VIDEO_GET_NAVI             _IOR('o', 52, video_navi_pack_t)
> -#define VIDEO_SET_ATTRIBUTES       _IO('o', 53)
> -#define VIDEO_GET_SIZE             _IOR('o', 55, video_size_t)
> -#define VIDEO_GET_FRAME_RATE       _IOR('o', 56, unsigned int)
> -
> -/**
> - * VIDEO_GET_PTS
> - *
> - * Read the 33 bit presentation time stamp as defined
> - * in ITU T-REC-H.222.0 / ISO/IEC 13818-1.
> - *
> - * The PTS should belong to the currently played
> - * frame if possible, but may also be a value close to it
> - * like the PTS of the last decoded frame or the last PTS
> - * extracted by the PES parser.
> - */
> -#define VIDEO_GET_PTS              _IOR('o', 57, __u64)
> -
> -/* Read the number of displayed frames since the decoder was started */
> -#define VIDEO_GET_FRAME_COUNT  	   _IOR('o', 58, __u64)
> -
> -#define VIDEO_COMMAND     	   _IOWR('o', 59, struct video_command)
> -#define VIDEO_TRY_COMMAND 	   _IOWR('o', 60, struct video_command)
> -
> -#endif /*_DVBVIDEO_H_*/



-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Oliver Endriss]

On Thursday 24 November 2011 18:37:02 Mauro Carvalho Chehab wrote:
> Userspace applications that support av7110 can include the new linux/av7110.h
> header. Other applications that support out-of-tree drivers can just have
> their own copy of audio.h, osd.h and video.h. So, it won't break or prevent
> existing applications to keep working.

No way! Changes of the user-space API are not acceptable.
If you do not believe that, ask Linux Torwalds!

> The thing is that the media API presents two interfaces to control mpeg decoders.
> This is confusing, and, while one of them has active upstream developers working
> on it, adding new drivers and new features on it, the other API is not being
> updated accordingly, and no new upstream drivers use it.

The decoder API is as old as the DVB spec.

NACK to any attempts to remove these files.

Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Andreas Oberritter]

On 24.11.2011 19:25, Mauro Carvalho Chehab wrote:
> Em 24-11-2011 16:07, Andreas Oberritter escreveu:
>> On 24.11.2011 18:58, Mauro Carvalho Chehab wrote:
>>> Em 24-11-2011 15:51, Andreas Oberritter escreveu:
>>>> On 24.11.2011 18:44, Hans Verkuil wrote:
>>>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>>>>> new API, but - pretty please - don't just blindly remove audio.h and
>>>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>>>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>>>>> those out-of-tree drivers merged, but it isn't possible for many
>>>>>> reasons. And even if they were merged, you'd say "Port them and your
>>>>>> apps to V4L". No! That's not an option.
>>>>>
>>>>> I'm not breaking anything. All apps will still work.
>>>>>
>>>>> One option (and it depends on whether people like it or not) is to have
>>>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>>>>> that these headers need to be replaced by the new av7110.h.
>>>>>
>>>>> And really remove them at some point in the future.
>>>>>
>>>>> But the important thing to realize is that the ABI hasn't changed (unless
>>>>> I made a mistake somewhere).
>>>>
>>>> So why don't you just leave the headers where they are and add a notice
>>>> about the new V4L API as a comment?
>>>>
>>>> What you proposed breaks compilation. If you add a warning, it breaks
>>>> compilation for programs compiled with -Werror. Both are regressions.
>>>
>>> I don't mind doing it for 3.3 kernel, and add a note at
>>> Documentation/feature-removal-schedule.txt that the
>>> headers will go away on 3.4. This should give distributions
>>> and app developers enough time to prevent build failures, and
>>> prepare for the upcoming changes.
>>
>> Are you serious?
>>
>> Breaking things that worked well for many years - for an artificially
>> invented reason - is so annoying, I can't even find the words to express
>> how much this sucks.
> 
> Andreas,
> 
> All the in-kernel API's are there to support in-kernel drivers.
> 
> Out of tree drivers can do whatever they want. As you likely know, several STB 
> vendors have their own API's. 
> 
> Some use some variants of DVBv3 or DVBv5, and some use their own proprietary
> API's, that are even incompatible with DVB (and some even provide both).
> 
> Even the ones that use DVBv3 (or v5) have their own implementation that diverges
> from the upstream one.
> 
> Provided that such vendors don't violate the Kernel GPLv2 license where it applies, 
> they're free do do whatever they want, forking the DVB API, or creating their own
> stacks.

You're encouraging people to do their own stuff instead of using and
contributing to a common API?

Anyway, you're talking about the DVB API as a whole, which of course
diverges a little bit from upstream in every implementation, because
patches to enhance the API are generally rejected if no in-kernel driver
uses the new function/flag/whatever at the time of its introduction. I
would have submitted many more API enhancements in the past, if you
wouldn't force that strict policy. Instead I usually have to wait until
another developer does the same job and then merge our work.

On the other hand, S2API was merged upstream with many unused "DTV_xxx"
commands and unused structs in the public header, being incomplete at
the same time (e.g. missing DiSEqC support and signal quality
measurements functions).

> So, keeping the in-kernel unused ioctl's don't bring any real benefit, as vendors
> can still do their forks, and applications designed to work with those hardware 
> need to support the vendor's stack.

Can you please list all unused ioctls? As you know, av7110 uses some of
them and Manu is currently developing another open source driver using
the audio and video APIs. Please don't pretend that all ioctls are
unused to justify a removal of the whole API.

> On the other hand, keeping an outdated API that doesn't fit well for the vendors
> that want to upstream their STB drivers is bad, as it creates confusion for
> them, and prevents innovation, as they may try to workaround on the limitation of
> an API designed for the first generation DVB standards.

Can you elaborate which parts of the current generation DVB standards
limit the use of the audio and video API, apart from the missing video
codec flags, which were sent to the mailing list as a patch in 2006?

As already said in another mail today, a comment explaining the
existence and benefits of the V4L video decoder API at the top of
linux/dvb/{audio,video}.h would stop the confusion you're talking about.

Btw.: How does V4l replace osd.h and audio.h? I know that osd.h has been
deprecated for many years, but all reasoning I've heard in this thread
until now was that V4L was superior to the DVB video decoder API.

> That's what Hans patches are addressing.
> 
> If you have a better approach, feel free to suggest it, provided that, at the end,
> the API that aren't used by non-legacy drivers are removed (or moved to driver's
> specific ioctl's).

OK. Can we agree on waiting for Manu's "non-legacy" driver to get
merged? After that we can remove unused ioctls - and only those. I
assume that "legacy" in your sentence means "unable to decode H.264",
which is a little bit odd, considering that large amounts of SDTV STBs
are still being sold worldwide and considering that analogue TV is still
being used in more than a handful of locations.

Regards,
Andreas

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 24-11-2011 23:09, Andreas Oberritter escreveu:
> On 24.11.2011 19:25, Mauro Carvalho Chehab wrote:
>> Em 24-11-2011 16:07, Andreas Oberritter escreveu:
>>> On 24.11.2011 18:58, Mauro Carvalho Chehab wrote:
>>>> Em 24-11-2011 15:51, Andreas Oberritter escreveu:
>>>>> On 24.11.2011 18:44, Hans Verkuil wrote:
>>>>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>>>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>>>>>> new API, but - pretty please - don't just blindly remove audio.h and
>>>>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>>>>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>>>>>> those out-of-tree drivers merged, but it isn't possible for many
>>>>>>> reasons. And even if they were merged, you'd say "Port them and your
>>>>>>> apps to V4L". No! That's not an option.
>>>>>>
>>>>>> I'm not breaking anything. All apps will still work.
>>>>>>
>>>>>> One option (and it depends on whether people like it or not) is to have
>>>>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>>>>>> that these headers need to be replaced by the new av7110.h.
>>>>>>
>>>>>> And really remove them at some point in the future.
>>>>>>
>>>>>> But the important thing to realize is that the ABI hasn't changed (unless
>>>>>> I made a mistake somewhere).
>>>>>
>>>>> So why don't you just leave the headers where they are and add a notice
>>>>> about the new V4L API as a comment?
>>>>>
>>>>> What you proposed breaks compilation. If you add a warning, it breaks
>>>>> compilation for programs compiled with -Werror. Both are regressions.
>>>>
>>>> I don't mind doing it for 3.3 kernel, and add a note at
>>>> Documentation/feature-removal-schedule.txt that the
>>>> headers will go away on 3.4. This should give distributions
>>>> and app developers enough time to prevent build failures, and
>>>> prepare for the upcoming changes.
>>>
>>> Are you serious?
>>>
>>> Breaking things that worked well for many years - for an artificially
>>> invented reason - is so annoying, I can't even find the words to express
>>> how much this sucks.
>>
>> Andreas,
>>
>> All the in-kernel API's are there to support in-kernel drivers.
>>
>> Out of tree drivers can do whatever they want. As you likely know, several STB 
>> vendors have their own API's. 
>>
>> Some use some variants of DVBv3 or DVBv5, and some use their own proprietary
>> API's, that are even incompatible with DVB (and some even provide both).
>>
>> Even the ones that use DVBv3 (or v5) have their own implementation that diverges
>> from the upstream one.
>>
>> Provided that such vendors don't violate the Kernel GPLv2 license where it applies, 
>> they're free do do whatever they want, forking the DVB API, or creating their own
>> stacks.
> 
> You're encouraging people to do their own stuff instead of using and
> contributing to a common API?

Not at all, but this is what happens when drivers are out-of-tree.
The only way to avoid it to happen is to merge the drivers upstream.

> Anyway, you're talking about the DVB API as a whole, which of course
> diverges a little bit from upstream in every implementation, because
> patches to enhance the API are generally rejected if no in-kernel driver
> uses the new function/flag/whatever at the time of its introduction. I
> would have submitted many more API enhancements in the past, if you
> wouldn't force that strict policy. Instead I usually have to wait until
> another developer does the same job and then merge our work.

There are no restrictions for you to merge your API enhancements with your drivers.

> On the other hand, S2API was merged upstream with many unused "DTV_xxx"
> commands and unused structs in the public header, being incomplete at
> the same time (e.g. missing DiSEqC support and signal quality
> measurements functions).

Yes, this was a big mistake. It should never happen again. On that time,
I trusted that the developer that proposed S2API would provide us both API 
documentation and the missing features, as promised, with unfortunately
didn't happen.

This is one more reason for me to not accept anymore patches that adds incomplete
stuff at the Kernel API's: a new API patch series now needs to provide:
   - API bits;
   - Documentation;
   - driver using it.

This is the only way to be sure that everything is all set, and to warrant that
other drivers using the API will behave like the first one that added it.

>> So, keeping the in-kernel unused ioctl's don't bring any real benefit, as vendors
>> can still do their forks, and applications designed to work with those hardware 
>> need to support the vendor's stack.
> 
> Can you please list all unused ioctls? As you know, av7110 uses some of
> them and Manu is currently developing another open source driver using
> the audio and video APIs. Please don't pretend that all ioctls are
> unused to justify a removal of the whole API.

a make htmldocs will list what API calls aren't documented:

Error: no ID for constraint linkend: AUDIO_GET_PTS.
Error: no ID for constraint linkend: AUDIO_BILINGUAL_CHANNEL_SELECT.
Error: no ID for constraint linkend: CA_RESET.
Error: no ID for constraint linkend: CA_GET_CAP.
Error: no ID for constraint linkend: CA_GET_SLOT_INFO.
Error: no ID for constraint linkend: CA_GET_DESCR_INFO.
Error: no ID for constraint linkend: CA_GET_MSG.
Error: no ID for constraint linkend: CA_SEND_MSG.
Error: no ID for constraint linkend: CA_SET_DESCR.
Error: no ID for constraint linkend: CA_SET_PID.
Error: no ID for constraint linkend: DMX_GET_PES_PIDS.
Error: no ID for constraint linkend: DMX_GET_CAPS.
Error: no ID for constraint linkend: DMX_SET_SOURCE.
Error: no ID for constraint linkend: DMX_ADD_PID.
Error: no ID for constraint linkend: DMX_REMOVE_PID.
Error: no ID for constraint linkend: DTV-ENUM-DELSYS.
Error: no ID for constraint linkend: NET_ADD_IF.
Error: no ID for constraint linkend: NET_REMOVE_IF.
Error: no ID for constraint linkend: NET_GET_IF.
Error: no ID for constraint linkend: VIDEO_GET_SIZE.
Error: no ID for constraint linkend: VIDEO_GET_FRAME_RATE.
Error: no ID for constraint linkend: VIDEO_GET_PTS.
Error: no ID for constraint linkend: VIDEO_GET_FRAME_COUNT.
Error: no ID for constraint linkend: VIDEO_COMMAND.
Error: no ID for constraint linkend: VIDEO_TRY_COMMAND.

As far as I remember, the audio/video ioctl's there aren't used. I've made
a presentation in Prague where I listed what's in usage. I think I've sent
it to the meeting's public mailing list. I'll put it on a public repository
when I have some time.
 
>> On the other hand, keeping an outdated API that doesn't fit well for the vendors
>> that want to upstream their STB drivers is bad, as it creates confusion for
>> them, and prevents innovation, as they may try to workaround on the limitation of
>> an API designed for the first generation DVB standards.
> 
> Can you elaborate which parts of the current generation DVB standards
> limit the use of the audio and video API, apart from the missing video
> codec flags, which were sent to the mailing list as a patch in 2006?

Making an exhaustive list takes some time, but one of the big missing part
is the pipeline setting. SoC devices may have several ways to configure the
pipelines, any may have some processing blocks in the middle of the image
processing. It may also need to share buffers with the video adapter of the
SoC. All those features are there at the V4L2 core, and are provided via
the V4L2 subdev and the Media Controller API's. All those discussions are
under heavy development since 2008. Re-implementing it at the DVB API
would be to re-invent the wheel.

Also, SoC devices may have analog TV, Web cams, grabber sources, digital
TV, etc as input, and, after decoded, using the same pipeline for outputing
or displaying the video.

> As already said in another mail today, a comment explaining the
> existence and benefits of the V4L video decoder API at the top of
> linux/dvb/{audio,video}.h would stop the confusion you're talking about.

It would be really nice if you, Manu and Oliver could be there in Prague,
as those things were discussed there with other Kernelspace and userspace
developers. This is the kind of discussion that could take a large amount
of time to discuss and come to a common understanding via email.

I'll seek for some time to write something about that. Maybe the others that
followed the discussions could write a summary about it.

Maybe we could try, instead, to set some audio or video conference with the
interested parties (or even a discussion on irc?).

> Btw.: How does V4l replace osd.h and audio.h? I know that osd.h has been
> deprecated for many years, but all reasoning I've heard in this thread
> until now was that V4L was superior to the DVB video decoder API.

OSD is currently not supported directly, although I think that the proper
way for doing it is via the shared buffer API, e. g., doing OSD composition
inside the video adapter. While V4L2 is well-known for video input, it also
supports video output, and the shared buffer API is enhancing it by allowing
to share a video buffer with the GPU.

The V4L2 API has several ioctl's to control the audio of the stream, like
selecting the language, SAP, stereo, etc. The DVB implementation for audio
demod status (pause, play, etc) is the same kind of control that is done at
the video part. So, the Hans proposal is to use the same ioctl's for both
audio and video. This approach doesn't allow things like pausing audio while
keeping video running, but this doesn't seem to make much sense, anyway.

>> That's what Hans patches are addressing.
>>
>> If you have a better approach, feel free to suggest it, provided that, at the end,
>> the API that aren't used by non-legacy drivers are removed (or moved to driver's
>> specific ioctl's).
> 
> OK. Can we agree on waiting for Manu's "non-legacy" driver to get
> merged? After that we can remove unused ioctls - and only those. I
> assume that "legacy" in your sentence means "unable to decode H.264",
> which is a little bit odd, considering that large amounts of SDTV STBs
> are still being sold worldwide and considering that analogue TV is still
> being used in more than a handful of locations.

Legacy, in my sentence means legacy hardware.

The thing is that, while the audio/video DVB API would make some sense at
av7110 time, with SoC designs, it become obsolete as a hole, as it is not
enough to replace V4L2/ALSA/MC/subdev API's, and changing it to fulfill
today's needs would require a very large amount of re-work on something
that it is already there.

So, I fail to see how waiting for Manu's driver would change it. In any case,
I'm not on a hurry. So, should discuss it more, in order to properly
address the evolution of the media API.

Regards,
Mauro

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Andreas Oberritter]

On 24.11.2011 19:47, Mauro Carvalho Chehab wrote:
> Em 24-11-2011 16:13, Manu Abraham escreveu:
>> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab
>> <mchehab@redhat.com> wrote:
>>> Em 24-11-2011 16:01, Manu Abraham escreveu:
>>>> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>>>>> new API, but - pretty please - don't just blindly remove audio.h and
>>>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>>>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>>>>> those out-of-tree drivers merged, but it isn't possible for many
>>>>>> reasons. And even if they were merged, you'd say "Port them and your
>>>>>> apps to V4L". No! That's not an option.
>>>>>
>>>>> I'm not breaking anything. All apps will still work.
>>>>>
>>>>> One option (and it depends on whether people like it or not) is to have
>>>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>>>>> that these headers need to be replaced by the new av7110.h.
>>>>
>>>>
>>>> That won't work with other non av7110 hardware.
>>>
>>> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put
>>> a warning at the existing headers as-is, for now, putting them to be removed
>>> for a new kernel version, like 3.4.
>>
>>
>> No, that's not an option. The to-be merged saa716x driver depends on it.
> 
> If the driver is not merged yet, it can be changed.
> 
>> A DVB alone device need not depend V4L2 for it's operation.
> 
> Why not? DVB drivers with IR should implement the input/event/IR API. DVB drivers with net
> should implement the Linux Network API.

DVB doesn't specify IR. There's no such thing like a DVB IR device.

IP over DVB is implemented transparently. No driver needs to do anything
but register its device's MAC address, therefore no driver implements
the Linux Network API.

> There is nothing wrong on using the ALSA API for audio and the V4L2 API for video,
> as both API fits the needs for decoding audio and video streams, and new features
> could be added there when needed.

Yes. There's nothing wrong with it and I'm not complaining. I don't care
about the implementation of the API in ivtv either. Just don't remove
the API from dvb-core, period.

> Duplicated API's that become legacy are removed with time. Just to mention two
> notable cases, this happened with the old audio stack (OSS), with the old Wireless
> stack.

I can still use iwconfig and linux/wireless.h is still available on my
system.

ALSA still provides OSS emulation and the real OSS stack was marked
deprecated but still present for ages. In contrast, you want to remove a
stable API and introduce a new *completely untested* API between 3.3 and
3.4.

> Do you have any issues that needs to be addressed by the V4L2 API for it to fit
> on your needs?

I don't want to be forced to use the V4L2 API for no reason and no gain.

>> Also, it doesn't
>> make any sense to have device specific headers to be used by an application,
>> when drivers share more than one commonality.
> 
> The only in-kernel driver using audio/video/osd is av7110.

Once again: Manu is going to submit a new driver soon.

You're trying to remove an API that you've never used. The people who
use the API want it to stay.

Regards,
Andreas

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Andreas Oberritter]

On 25.11.2011 03:44, Mauro Carvalho Chehab wrote:
> Em 24-11-2011 23:09, Andreas Oberritter escreveu:
>> On 24.11.2011 19:25, Mauro Carvalho Chehab wrote:
>>> Em 24-11-2011 16:07, Andreas Oberritter escreveu:
>>>> On 24.11.2011 18:58, Mauro Carvalho Chehab wrote:
>>>>> Em 24-11-2011 15:51, Andreas Oberritter escreveu:
>>
>> You're encouraging people to do their own stuff instead of using and
>> contributing to a common API?
> 
> Not at all, but this is what happens when drivers are out-of-tree.
> The only way to avoid it to happen is to merge the drivers upstream.

Well, you're right. But only because you artificially made it the only
way to contribute to the API.

>> Anyway, you're talking about the DVB API as a whole, which of course
>> diverges a little bit from upstream in every implementation, because
>> patches to enhance the API are generally rejected if no in-kernel driver
>> uses the new function/flag/whatever at the time of its introduction. I
>> would have submitted many more API enhancements in the past, if you
>> wouldn't force that strict policy. Instead I usually have to wait until
>> another developer does the same job and then merge our work.
> 
> There are no restrictions for you to merge your API enhancements with your drivers.

I guess you're misunderstanding. I don't need to merge *my* enhancements
with *my* drivers. I need to merge upstream API changes with my local
API changes, whenever they are done, i.e. when a device appears which
has a new feature for which I already have created an API extension. See
DVB-T2 as an example: I had the API definition ready and tested about a
year before the first public driver appeared. But I couldn't merge it
upstream without submitting a driver. The result of course is that
everybody else who wanted to develop a DVB-T2 driver during that period
of time needed to create his own API, which IMO is worse than having a
new API (well, two or three #defines or additions to enums) without
in-kernel users.

>> On the other hand, S2API was merged upstream with many unused "DTV_xxx"
>> commands and unused structs in the public header, being incomplete at
>> the same time (e.g. missing DiSEqC support and signal quality
>> measurements functions).
> 
> Yes, this was a big mistake. It should never happen again. On that time,
> I trusted that the developer that proposed S2API would provide us both API 
> documentation and the missing features, as promised, with unfortunately
> didn't happen.
> 
> This is one more reason for me to not accept anymore patches that adds incomplete
> stuff at the Kernel API's: a new API patch series now needs to provide:
>    - API bits;
>    - Documentation;
>    - driver using it.
> 
> This is the only way to be sure that everything is all set, and to warrant that
> other drivers using the API will behave like the first one that added it.

It does not warrant anything, because both drivers and APIs do contain
bugs and oversights, and first implementations are usually worst. You
can't foresee the future, so APIs will eventually evolve, no matter
whether submitted together with a driver or without.

>>> So, keeping the in-kernel unused ioctl's don't bring any real benefit, as vendors
>>> can still do their forks, and applications designed to work with those hardware 
>>> need to support the vendor's stack.
>>
>> Can you please list all unused ioctls? As you know, av7110 uses some of
>> them and Manu is currently developing another open source driver using
>> the audio and video APIs. Please don't pretend that all ioctls are
>> unused to justify a removal of the whole API.
> 
> a make htmldocs will list what API calls aren't documented:
> 
> Error: no ID for constraint linkend: AUDIO_GET_PTS.
> Error: no ID for constraint linkend: AUDIO_BILINGUAL_CHANNEL_SELECT.
> Error: no ID for constraint linkend: CA_RESET.
> Error: no ID for constraint linkend: CA_GET_CAP.
> Error: no ID for constraint linkend: CA_GET_SLOT_INFO.
> Error: no ID for constraint linkend: CA_GET_DESCR_INFO.
> Error: no ID for constraint linkend: CA_GET_MSG.
> Error: no ID for constraint linkend: CA_SEND_MSG.
> Error: no ID for constraint linkend: CA_SET_DESCR.
> Error: no ID for constraint linkend: CA_SET_PID.
> Error: no ID for constraint linkend: DMX_GET_PES_PIDS.
> Error: no ID for constraint linkend: DMX_GET_CAPS.
> Error: no ID for constraint linkend: DMX_SET_SOURCE.
> Error: no ID for constraint linkend: DMX_ADD_PID.
> Error: no ID for constraint linkend: DMX_REMOVE_PID.
> Error: no ID for constraint linkend: DTV-ENUM-DELSYS.
> Error: no ID for constraint linkend: NET_ADD_IF.
> Error: no ID for constraint linkend: NET_REMOVE_IF.
> Error: no ID for constraint linkend: NET_GET_IF.
> Error: no ID for constraint linkend: VIDEO_GET_SIZE.
> Error: no ID for constraint linkend: VIDEO_GET_FRAME_RATE.
> Error: no ID for constraint linkend: VIDEO_GET_PTS.
> Error: no ID for constraint linkend: VIDEO_GET_FRAME_COUNT.
> Error: no ID for constraint linkend: VIDEO_COMMAND.
> Error: no ID for constraint linkend: VIDEO_TRY_COMMAND.
> 
> As far as I remember, the audio/video ioctl's there aren't used. I've made
> a presentation in Prague where I listed what's in usage. I think I've sent
> it to the meeting's public mailing list. I'll put it on a public repository
> when I have some time.

Undocumented doesn't mean unused.

VIDEO_GET_SIZE is used by av7110.

I wouldn't miss VIDEO_COMMAND and VIDEO_TRY_COMMAND. I have no idea why
they were added by Hans in the first place, duplicating many existing
commands. I also wouldn't miss VIDEO_GET_FRAME_COUNT, which was added by
Hans in the same patch. I don't know what this was good for. Ditto for
AUDIO_BILINGUAL_CHANNEL_SELECT.

Of the a/v ioctls listed above I'm using AUDIO_GET_PTS, VIDEO_GET_SIZE,
VIDEO_GET_PTS, VIDEO_GET_FRAME_RATE. I think it would be trivial to
implement them for the av7110. I guess Manu's driver will be using them
anyway.

>>> On the other hand, keeping an outdated API that doesn't fit well for the vendors
>>> that want to upstream their STB drivers is bad, as it creates confusion for
>>> them, and prevents innovation, as they may try to workaround on the limitation of
>>> an API designed for the first generation DVB standards.
>>
>> Can you elaborate which parts of the current generation DVB standards
>> limit the use of the audio and video API, apart from the missing video
>> codec flags, which were sent to the mailing list as a patch in 2006?
> 
> Making an exhaustive list takes some time, but one of the big missing part
> is the pipeline setting. SoC devices may have several ways to configure the
> pipelines, any may have some processing blocks in the middle of the image
> processing. It may also need to share buffers with the video adapter of the
> SoC. All those features are there at the V4L2 core, and are provided via
> the V4L2 subdev and the Media Controller API's. All those discussions are
> under heavy development since 2008. Re-implementing it at the DVB API
> would be to re-invent the wheel.
> 
> Also, SoC devices may have analog TV, Web cams, grabber sources, digital
> TV, etc as input, and, after decoded, using the same pipeline for outputing
> or displaying the video.

See, it has nothing to do with DVB standards. One more of your spurious
arguments just vanished.

>> As already said in another mail today, a comment explaining the
>> existence and benefits of the V4L video decoder API at the top of
>> linux/dvb/{audio,video}.h would stop the confusion you're talking about.
> 
> It would be really nice if you, Manu and Oliver could be there in Prague,
> as those things were discussed there with other Kernelspace and userspace
> developers. This is the kind of discussion that could take a large amount
> of time to discuss and come to a common understanding via email.

You should know that there were good reasons for many people not to
attend the event. It's OK to discuss stuff at a meeting with random
people, but you should listen to other people's opinions afterwards, too.

*But* whatever you decided in Prague, just do it, but without breaking
the API. That's all we want. Nothing more, nothing less.

> I'll seek for some time to write something about that. Maybe the others that
> followed the discussions could write a summary about it.
> 
> Maybe we could try, instead, to set some audio or video conference with the
> interested parties (or even a discussion on irc?).
> 
>> Btw.: How does V4l replace osd.h and audio.h? I know that osd.h has been
>> deprecated for many years, but all reasoning I've heard in this thread
>> until now was that V4L was superior to the DVB video decoder API.
> 
> OSD is currently not supported directly, although I think that the proper
> way for doing it is via the shared buffer API, e. g., doing OSD composition
> inside the video adapter. While V4L2 is well-known for video input, it also
> supports video output, and the shared buffer API is enhancing it by allowing
> to share a video buffer with the GPU.
> 
> The V4L2 API has several ioctl's to control the audio of the stream, like
> selecting the language, SAP, stereo, etc. The DVB implementation for audio
> demod status (pause, play, etc) is the same kind of control that is done at
> the video part. So, the Hans proposal is to use the same ioctl's for both
> audio and video. This approach doesn't allow things like pausing audio while
> keeping video running, but this doesn't seem to make much sense, anyway.

So you're duplicating audio APIs at V4L2 and think it's better than
duplicating them in DVB with respect to ALSA?

Can you control pass-through of digital audio to SPDIF for example? Can
you control which decoder should be the master when synchronizing AV?

>>> That's what Hans patches are addressing.
>>>
>>> If you have a better approach, feel free to suggest it, provided that, at the end,
>>> the API that aren't used by non-legacy drivers are removed (or moved to driver's
>>> specific ioctl's).
>>
>> OK. Can we agree on waiting for Manu's "non-legacy" driver to get
>> merged? After that we can remove unused ioctls - and only those. I
>> assume that "legacy" in your sentence means "unable to decode H.264",
>> which is a little bit odd, considering that large amounts of SDTV STBs
>> are still being sold worldwide and considering that analogue TV is still
>> being used in more than a handful of locations.
> 
> Legacy, in my sentence means legacy hardware.

So what is legacy hardware? PCI? Everything that's older than 3 years?
Everything you can't buy at Amazon?

> The thing is that, while the audio/video DVB API would make some sense at
> av7110 time, with SoC designs, it become obsolete as a hole, as it is not
> enough to replace V4L2/ALSA/MC/subdev API's, and changing it to fulfill
> today's needs would require a very large amount of re-work on something
> that it is already there.

I'm currently actively using the API on three different families of
SoCs. And yes, even on new ones. Please tell me again that my work is
obsolete.

Nobody wants to replace V4L2/ALSA/MC/subdev APIs. I don't know why
you're writing that. Do whatever you want with those APIs but don't
break DVB.

> So, I fail to see how waiting for Manu's driver would change it. In any case,
> I'm not on a hurry. So, should discuss it more, in order to properly
> address the evolution of the media API.

Manu's driver will show you how to the DVB API fulfills today's needs
for DVB.

Again, at this point in time there is no "media API".

Regards,
Andreas

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 25-11-2011 10:00, Andreas Oberritter escreveu:
> On 24.11.2011 19:47, Mauro Carvalho Chehab wrote:
>> Em 24-11-2011 16:13, Manu Abraham escreveu:
>>> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab
>>> <mchehab@redhat.com> wrote:
>>>> Em 24-11-2011 16:01, Manu Abraham escreveu:
>>>>> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>>>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>>>>>> new API, but - pretty please - don't just blindly remove audio.h and
>>>>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>>>>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>>>>>> those out-of-tree drivers merged, but it isn't possible for many
>>>>>>> reasons. And even if they were merged, you'd say "Port them and your
>>>>>>> apps to V4L". No! That's not an option.
>>>>>>
>>>>>> I'm not breaking anything. All apps will still work.
>>>>>>
>>>>>> One option (and it depends on whether people like it or not) is to have
>>>>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>>>>>> that these headers need to be replaced by the new av7110.h.
>>>>>
>>>>>
>>>>> That won't work with other non av7110 hardware.
>>>>
>>>> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put
>>>> a warning at the existing headers as-is, for now, putting them to be removed
>>>> for a new kernel version, like 3.4.
>>>
>>>
>>> No, that's not an option. The to-be merged saa716x driver depends on it.
>>
>> If the driver is not merged yet, it can be changed.
>>
>>> A DVB alone device need not depend V4L2 for it's operation.
>>
>> Why not? DVB drivers with IR should implement the input/event/IR API. DVB drivers with net
>> should implement the Linux Network API.
> 
> DVB doesn't specify IR. There's no such thing like a DVB IR device.
> 
> IP over DVB is implemented transparently. No driver needs to do anything
> but register its device's MAC address, therefore no driver implements
> the Linux Network API.
> 
>> There is nothing wrong on using the ALSA API for audio and the V4L2 API for video,
>> as both API fits the needs for decoding audio and video streams, and new features
>> could be added there when needed.
> 
> Yes. There's nothing wrong with it and I'm not complaining. I don't care
> about the implementation of the API in ivtv either. Just don't remove
> the API from dvb-core, period.
> 
>> Duplicated API's that become legacy are removed with time. Just to mention two
>> notable cases, this happened with the old audio stack (OSS), with the old Wireless
>> stack.
> 
> I can still use iwconfig and linux/wireless.h is still available on my
> system.

Yes, but both iwconfig and the API changed.

> ALSA still provides OSS emulation and the real OSS stack was marked
> deprecated but still present for ages. 

OSS driver submission stopped years ago. I remember it clearly as they denied cx88-oss 
driver submission (2004 or 2005). The saa7134-oss and bttv-oss drivers were dropped in 2007[1]
in favor of the alsa drivers. The only hardware that are still there at OSS are the 
legacy ones that probably no alsa developer has anymore.

[1] http://kerneltrap.org/mailarchive/linux-kernel/2007/11/9/398438/thread

> In contrast, you want to remove a
> stable API and introduce a new *completely untested* API between 3.3 and
> 3.4.

Please read the patches again. The API for the devices are still there:
any binary compiled for older kernels will still work with av7110 and ivtv.
With the patches applied, the only difference is that the header file has
renamed, as they were moved to device-specific headers.

It should be noticed that, while both av7110 and ivtv uses the same ioctl's, av7110
creates devices over /dev/dvb, while ivtv uses it over /dev/video?. So, in practice, 
each driver has a different API.

There are no plans to remove the API for av7110. 

As discussed on this thread, it seems that the agreed plans for the ivtv API is to put
it into the standard kernel procedure to get rid of legacy API. That means that the API 
will be there for a few kernel versions.

Hans proposal is to remove the ivtv API on 3.8, with seems reasonable. So, the first
API removal will happen in about 18 months from now (assuming about 2 months per kernel 
version).

>> Do you have any issues that needs to be addressed by the V4L2 API for it to fit
>> on your needs?
> 
> I don't want to be forced to use the V4L2 API for no reason and no gain.

As already explained on the other email, there are gains on using it, like the support
for other types of encoding, the pipeline setup, sub-device control, shared buffer interface
with GPU, proper support for SoC, etc.

Also, currently, just one device uses it (av7110). I don't think that the chipset is
still manufactured. At least Google didn't help finding anything:
	http://www.google.com/search?q=av7110&tbm=shop&hl=en

On the other hand, there are thousands of devices using V4L2 API.

As both API's provide support for decoded video, one API has to be deprecated in favor
to the other. We should select for deprecation the one that is more restrictive
and that has just one driver using it.

> 
>>> Also, it doesn't
>>> make any sense to have device specific headers to be used by an application,
>>> when drivers share more than one commonality.
>>
>> The only in-kernel driver using audio/video/osd is av7110.
> 
> Once again: Manu is going to submit a new driver soon.

The API is there for several years (since 2002?), with just one driver supporting it.
It shouldn't be hard to convert Manu's work to the V4L2. I can help him on converting
his driver to use the V4L2 API if needed.

> You're trying to remove an API that you've never used. The people who
> use the API want it to stay.

As I said, it will stay there. Nobody will remove av7110 or remove the old API from it.

The idea is that no new driver should use it, as it is a legacy one-driver-only API.

If your complain is about the removal of audio.h, video.h and osd.h, then my proposal is
to keep it there, writing a text that they are part of a deprecated API, but keeping
the rest of the patches and not accepting anymore any submission using them, removing
the ioctl's that aren't used by av7110 from them.

Regards,
Mauro

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Manu Abraham]

On Fri, Nov 25, 2011 at 7:18 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 25-11-2011 10:00, Andreas Oberritter escreveu:
>> On 24.11.2011 19:47, Mauro Carvalho Chehab wrote:
>>> Em 24-11-2011 16:13, Manu Abraham escreveu:
>>>> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab
>>>> <mchehab@redhat.com> wrote:
>>>>> Em 24-11-2011 16:01, Manu Abraham escreveu:
>>>>>> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>>>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>>>>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>>>>>>> new API, but - pretty please - don't just blindly remove audio.h and
>>>>>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>>>>>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>>>>>>> those out-of-tree drivers merged, but it isn't possible for many
>>>>>>>> reasons. And even if they were merged, you'd say "Port them and your
>>>>>>>> apps to V4L". No! That's not an option.
>>>>>>>
>>>>>>> I'm not breaking anything. All apps will still work.
>>>>>>>
>>>>>>> One option (and it depends on whether people like it or not) is to have
>>>>>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>>>>>>> that these headers need to be replaced by the new av7110.h.
>>>>>>
>>>>>>
>>>>>> That won't work with other non av7110 hardware.
>>>>>
>>>>> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put
>>>>> a warning at the existing headers as-is, for now, putting them to be removed
>>>>> for a new kernel version, like 3.4.
>>>>
>>>>
>>>> No, that's not an option. The to-be merged saa716x driver depends on it.
>>>
>>> If the driver is not merged yet, it can be changed.
>>>
>>>> A DVB alone device need not depend V4L2 for it's operation.
>>>
>>> Why not? DVB drivers with IR should implement the input/event/IR API. DVB drivers with net
>>> should implement the Linux Network API.
>>
>> DVB doesn't specify IR. There's no such thing like a DVB IR device.
>>
>> IP over DVB is implemented transparently. No driver needs to do anything
>> but register its device's MAC address, therefore no driver implements
>> the Linux Network API.
>>
>>> There is nothing wrong on using the ALSA API for audio and the V4L2 API for video,
>>> as both API fits the needs for decoding audio and video streams, and new features
>>> could be added there when needed.
>>
>> Yes. There's nothing wrong with it and I'm not complaining. I don't care
>> about the implementation of the API in ivtv either. Just don't remove
>> the API from dvb-core, period.
>>
>>> Duplicated API's that become legacy are removed with time. Just to mention two
>>> notable cases, this happened with the old audio stack (OSS), with the old Wireless
>>> stack.
>>
>> I can still use iwconfig and linux/wireless.h is still available on my
>> system.
>
> Yes, but both iwconfig and the API changed.
>
>> ALSA still provides OSS emulation and the real OSS stack was marked
>> deprecated but still present for ages.
>
> OSS driver submission stopped years ago. I remember it clearly as they denied cx88-oss
> driver submission (2004 or 2005). The saa7134-oss and bttv-oss drivers were dropped in 2007[1]
> in favor of the alsa drivers. The only hardware that are still there at OSS are the
> legacy ones that probably no alsa developer has anymore.
>
> [1] http://kerneltrap.org/mailarchive/linux-kernel/2007/11/9/398438/thread
>
>> In contrast, you want to remove a
>> stable API and introduce a new *completely untested* API between 3.3 and
>> 3.4.
>
> Please read the patches again. The API for the devices are still there:
> any binary compiled for older kernels will still work with av7110 and ivtv.
> With the patches applied, the only difference is that the header file has
> renamed, as they were moved to device-specific headers.
>
> It should be noticed that, while both av7110 and ivtv uses the same ioctl's, av7110
> creates devices over /dev/dvb, while ivtv uses it over /dev/video?. So, in practice,
> each driver has a different API.
>
> There are no plans to remove the API for av7110.
>
> As discussed on this thread, it seems that the agreed plans for the ivtv API is to put
> it into the standard kernel procedure to get rid of legacy API. That means that the API
> will be there for a few kernel versions.
>
> Hans proposal is to remove the ivtv API on 3.8, with seems reasonable. So, the first
> API removal will happen in about 18 months from now (assuming about 2 months per kernel
> version).
>
>>> Do you have any issues that needs to be addressed by the V4L2 API for it to fit
>>> on your needs?
>>
>> I don't want to be forced to use the V4L2 API for no reason and no gain.
>
> As already explained on the other email, there are gains on using it, like the support
> for other types of encoding, the pipeline setup, sub-device control, shared buffer interface
> with GPU, proper support for SoC, etc.
>
> Also, currently, just one device uses it (av7110). I don't think that the chipset is
> still manufactured. At least Google didn't help finding anything:
>        http://www.google.com/search?q=av7110&tbm=shop&hl=en
>
> On the other hand, there are thousands of devices using V4L2 API.
>
> As both API's provide support for decoded video, one API has to be deprecated in favor
> to the other. We should select for deprecation the one that is more restrictive
> and that has just one driver using it.
>
>>
>>>> Also, it doesn't
>>>> make any sense to have device specific headers to be used by an application,
>>>> when drivers share more than one commonality.
>>>
>>> The only in-kernel driver using audio/video/osd is av7110.
>>
>> Once again: Manu is going to submit a new driver soon.
>
> The API is there for several years (since 2002?), with just one driver supporting it.
> It shouldn't be hard to convert Manu's work to the V4L2. I can help him on converting
> his driver to use the V4L2 API if needed.


No, thanks. As i mentioned, there is no plan to use V4L/2 for a DVB
alone device.

Regards,
Manu

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Andreas Oberritter]

On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
> If your complain is about the removal of audio.h, video.h

We're back on topic, thank you!

> and osd.h, then my proposal is
> to keep it there, writing a text that they are part of a deprecated API,

That's exactly what I proposed. Well, you shouldn't write "deprecated",
because it's not. Just explain - inside this text - when V4L2 should be
preferred over DVB.

> but keeping
> the rest of the patches

Which ones?

> and not accepting anymore any submission using them

Why? First you complain about missing users and then don't want to allow
any new ones.

>, removing
> the ioctl's that aren't used by av7110 from them.

That's just stupid. I can easily provide a list of used and valuable
ioctls, which need to remain present in order to not break userspace
applications.

Btw.: It's not easy to submit a driver for a SoC. Even if you are
legally allowed to do it, you have to first merge and maintain the board
support code before even thinking about multimedia.

Regards,
Andreas

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 25-11-2011 10:55, Andreas Oberritter escreveu:
> On 25.11.2011 03:44, Mauro Carvalho Chehab wrote:
>> Em 24-11-2011 23:09, Andreas Oberritter escreveu:
>>> On 24.11.2011 19:25, Mauro Carvalho Chehab wrote:
>>>> Em 24-11-2011 16:07, Andreas Oberritter escreveu:
>>>>> On 24.11.2011 18:58, Mauro Carvalho Chehab wrote:
>>>>>> Em 24-11-2011 15:51, Andreas Oberritter escreveu:
>>>
>>> You're encouraging people to do their own stuff instead of using and
>>> contributing to a common API?
>>
>> Not at all, but this is what happens when drivers are out-of-tree.
>> The only way to avoid it to happen is to merge the drivers upstream.
> 
> Well, you're right. But only because you artificially made it the only
> way to contribute to the API.
> 
>>> Anyway, you're talking about the DVB API as a whole, which of course
>>> diverges a little bit from upstream in every implementation, because
>>> patches to enhance the API are generally rejected if no in-kernel driver
>>> uses the new function/flag/whatever at the time of its introduction. I
>>> would have submitted many more API enhancements in the past, if you
>>> wouldn't force that strict policy. Instead I usually have to wait until
>>> another developer does the same job and then merge our work.
>>
>> There are no restrictions for you to merge your API enhancements with your drivers.
> 
> I guess you're misunderstanding. I don't need to merge *my* enhancements
> with *my* drivers. I need to merge upstream API changes with my local
> API changes, whenever they are done, i.e. when a device appears which
> has a new feature for which I already have created an API extension. See
> DVB-T2 as an example: I had the API definition ready and tested about a
> year before the first public driver appeared. But I couldn't merge it
> upstream without submitting a driver. The result of course is that
> everybody else who wanted to develop a DVB-T2 driver during that period
> of time needed to create his own API, which IMO is worse than having a
> new API (well, two or three #defines or additions to enums) without
> in-kernel users.

You're free to submit API enhancements patches to the ML. I will only be merged
after having some kernel driver using it. 

The thing with kernel API's is that they should be there for a long period
(well, an API that nobody uses inside the kernel can be changed anytime, 
but still people complain about changing that). 

An API without a public implementation can't prove its value for the 
reviewers.

>>> On the other hand, S2API was merged upstream with many unused "DTV_xxx"
>>> commands and unused structs in the public header, being incomplete at
>>> the same time (e.g. missing DiSEqC support and signal quality
>>> measurements functions).
>>
>> Yes, this was a big mistake. It should never happen again. On that time,
>> I trusted that the developer that proposed S2API would provide us both API 
>> documentation and the missing features, as promised, with unfortunately
>> didn't happen.
>>
>> This is one more reason for me to not accept anymore patches that adds incomplete
>> stuff at the Kernel API's: a new API patch series now needs to provide:
>>    - API bits;
>>    - Documentation;
>>    - driver using it.
>>
>> This is the only way to be sure that everything is all set, and to warrant that
>> other drivers using the API will behave like the first one that added it.
> 
> It does not warrant anything, because both drivers and APIs do contain
> bugs and oversights, and first implementations are usually worst. You
> can't foresee the future, so APIs will eventually evolve, no matter
> whether submitted together with a driver or without.

Reviewers work better when they can actually look on an implementation for the API.

>>>> So, keeping the in-kernel unused ioctl's don't bring any real benefit, as vendors
>>>> can still do their forks, and applications designed to work with those hardware 
>>>> need to support the vendor's stack.
>>>
>>> Can you please list all unused ioctls? As you know, av7110 uses some of
>>> them and Manu is currently developing another open source driver using
>>> the audio and video APIs. Please don't pretend that all ioctls are
>>> unused to justify a removal of the whole API.
>>
>> a make htmldocs will list what API calls aren't documented:
>>
>> Error: no ID for constraint linkend: AUDIO_GET_PTS.
>> Error: no ID for constraint linkend: AUDIO_BILINGUAL_CHANNEL_SELECT.
>> Error: no ID for constraint linkend: CA_RESET.
>> Error: no ID for constraint linkend: CA_GET_CAP.
>> Error: no ID for constraint linkend: CA_GET_SLOT_INFO.
>> Error: no ID for constraint linkend: CA_GET_DESCR_INFO.
>> Error: no ID for constraint linkend: CA_GET_MSG.
>> Error: no ID for constraint linkend: CA_SEND_MSG.
>> Error: no ID for constraint linkend: CA_SET_DESCR.
>> Error: no ID for constraint linkend: CA_SET_PID.
>> Error: no ID for constraint linkend: DMX_GET_PES_PIDS.
>> Error: no ID for constraint linkend: DMX_GET_CAPS.
>> Error: no ID for constraint linkend: DMX_SET_SOURCE.
>> Error: no ID for constraint linkend: DMX_ADD_PID.
>> Error: no ID for constraint linkend: DMX_REMOVE_PID.
>> Error: no ID for constraint linkend: DTV-ENUM-DELSYS.
>> Error: no ID for constraint linkend: NET_ADD_IF.
>> Error: no ID for constraint linkend: NET_REMOVE_IF.
>> Error: no ID for constraint linkend: NET_GET_IF.
>> Error: no ID for constraint linkend: VIDEO_GET_SIZE.
>> Error: no ID for constraint linkend: VIDEO_GET_FRAME_RATE.
>> Error: no ID for constraint linkend: VIDEO_GET_PTS.
>> Error: no ID for constraint linkend: VIDEO_GET_FRAME_COUNT.
>> Error: no ID for constraint linkend: VIDEO_COMMAND.
>> Error: no ID for constraint linkend: VIDEO_TRY_COMMAND.
>>
>> As far as I remember, the audio/video ioctl's there aren't used. I've made
>> a presentation in Prague where I listed what's in usage. I think I've sent
>> it to the meeting's public mailing list. I'll put it on a public repository
>> when I have some time.
> 
> Undocumented doesn't mean unused.

No, but I did some effort to add some basic documentation to the ones I've
seen at the code (or at least, at the core).

As I said, the list of used/unused ioctl's are at the presentation I've sent
to the Workshop 2011 mailing list:
	http://www.linuxtv.org/pipermail/workshop-2011/2011-October/000075.html
The attachment is at:
	http://www.linuxtv.org/pipermail/workshop-2011/attachments/20111021/4030a71a/attachment-0001.odp

slides 5 and 6.

> VIDEO_GET_SIZE is used by av7110.
> I wouldn't miss VIDEO_COMMAND and VIDEO_TRY_COMMAND. I have no idea why
> they were added by Hans in the first place, duplicating many existing
> commands. I also wouldn't miss VIDEO_GET_FRAME_COUNT, which was added by
> Hans in the same patch. I don't know what this was good for. Ditto for
> AUDIO_BILINGUAL_CHANNEL_SELECT.
> 
> Of the a/v ioctls listed above I'm using AUDIO_GET_PTS, VIDEO_GET_SIZE,
> VIDEO_GET_PTS, VIDEO_GET_FRAME_RATE. I think it would be trivial to
> implement them for the av7110. I guess Manu's driver will be using them
> anyway.
> 
>>>> On the other hand, keeping an outdated API that doesn't fit well for the vendors
>>>> that want to upstream their STB drivers is bad, as it creates confusion for
>>>> them, and prevents innovation, as they may try to workaround on the limitation of
>>>> an API designed for the first generation DVB standards.
>>>
>>> Can you elaborate which parts of the current generation DVB standards
>>> limit the use of the audio and video API, apart from the missing video
>>> codec flags, which were sent to the mailing list as a patch in 2006?
>>
>> Making an exhaustive list takes some time, but one of the big missing part
>> is the pipeline setting. SoC devices may have several ways to configure the
>> pipelines, any may have some processing blocks in the middle of the image
>> processing. It may also need to share buffers with the video adapter of the
>> SoC. All those features are there at the V4L2 core, and are provided via
>> the V4L2 subdev and the Media Controller API's. All those discussions are
>> under heavy development since 2008. Re-implementing it at the DVB API
>> would be to re-invent the wheel.
>>
>> Also, SoC devices may have analog TV, Web cams, grabber sources, digital
>> TV, etc as input, and, after decoded, using the same pipeline for outputing
>> or displaying the video.
> 
> See, it has nothing to do with DVB standards. One more of your spurious
> arguments just vanished.

I never said it is related to DVB standards. It is related to dealing with
audio and video streams.

>>> As already said in another mail today, a comment explaining the
>>> existence and benefits of the V4L video decoder API at the top of
>>> linux/dvb/{audio,video}.h would stop the confusion you're talking about.
>>
>> It would be really nice if you, Manu and Oliver could be there in Prague,
>> as those things were discussed there with other Kernelspace and userspace
>> developers. This is the kind of discussion that could take a large amount
>> of time to discuss and come to a common understanding via email.
> 
> You should know that there were good reasons for many people not to
> attend the event. It's OK to discuss stuff at a meeting with random
> people, but you should listen to other people's opinions afterwards, too.

Sure.

> *But* whatever you decided in Prague, just do it, but without breaking
> the API. That's all we want. Nothing more, nothing less.
> 
>> I'll seek for some time to write something about that. Maybe the others that
>> followed the discussions could write a summary about it.
>>
>> Maybe we could try, instead, to set some audio or video conference with the
>> interested parties (or even a discussion on irc?).
>>
>>> Btw.: How does V4l replace osd.h and audio.h? I know that osd.h has been
>>> deprecated for many years, but all reasoning I've heard in this thread
>>> until now was that V4L was superior to the DVB video decoder API.
>>
>> OSD is currently not supported directly, although I think that the proper
>> way for doing it is via the shared buffer API, e. g., doing OSD composition
>> inside the video adapter. While V4L2 is well-known for video input, it also
>> supports video output, and the shared buffer API is enhancing it by allowing
>> to share a video buffer with the GPU.
>>
>> The V4L2 API has several ioctl's to control the audio of the stream, like
>> selecting the language, SAP, stereo, etc. The DVB implementation for audio
>> demod status (pause, play, etc) is the same kind of control that is done at
>> the video part. So, the Hans proposal is to use the same ioctl's for both
>> audio and video. This approach doesn't allow things like pausing audio while
>> keeping video running, but this doesn't seem to make much sense, anyway.
> 
> So you're duplicating audio APIs at V4L2 and think it's better than
> duplicating them in DVB with respect to ALSA?

The V4L2 API complements the ALSA API. Audio streaming, audio format negotiation
etc are via the ALSA API.

> Can you control pass-through of digital audio to SPDIF for example? Can
> you control which decoder should be the master when synchronizing AV?

Patches for that are being proposed and should be merged soon. They are part
of the set of patches under discussion with ALSA people, as part of the Media
Controller API.

>>>> That's what Hans patches are addressing.
>>>>
>>>> If you have a better approach, feel free to suggest it, provided that, at the end,
>>>> the API that aren't used by non-legacy drivers are removed (or moved to driver's
>>>> specific ioctl's).
>>>
>>> OK. Can we agree on waiting for Manu's "non-legacy" driver to get
>>> merged? After that we can remove unused ioctls - and only those. I
>>> assume that "legacy" in your sentence means "unable to decode H.264",
>>> which is a little bit odd, considering that large amounts of SDTV STBs
>>> are still being sold worldwide and considering that analogue TV is still
>>> being used in more than a handful of locations.
>>
>> Legacy, in my sentence means legacy hardware.
> 
> So what is legacy hardware? PCI? Everything that's older than 3 years?
> Everything you can't buy at Amazon?

Devices that use chips that aren't manufactured anymore for several years are
legacy.

> 
>> The thing is that, while the audio/video DVB API would make some sense at
>> av7110 time, with SoC designs, it become obsolete as a hole, as it is not
>> enough to replace V4L2/ALSA/MC/subdev API's, and changing it to fulfill
>> today's needs would require a very large amount of re-work on something
>> that it is already there.
> 
> I'm currently actively using the API on three different families of
> SoCs. And yes, even on new ones.

Ok, but all of this is out of the tree. The only driver in kernel that would be affected 
on a change at audio/video/osd headers is av7110.

> Please tell me again that my work is
> obsolete.

As you said, you also have your out-of-tree API enhancements. I can't
say anything about your work, as I'm not seeing anything related to the
SoC devices you're working with inside the kernel tree.

> Nobody wants to replace V4L2/ALSA/MC/subdev APIs. I don't know why
> you're writing that. Do whatever you want with those APIs but don't
> break DVB.
> 
>> So, I fail to see how waiting for Manu's driver would change it. In any case,
>> I'm not on a hurry. So, should discuss it more, in order to properly
>> address the evolution of the media API.
> 
> Manu's driver will show you how to the DVB API fulfills today's needs
> for DVB.
> 
> Again, at this point in time there is no "media API".
> 
> Regards,
> Andreas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Hans Verkuil]

On Friday, November 25, 2011 14:48:02 Mauro Carvalho Chehab wrote:
> Em 25-11-2011 10:00, Andreas Oberritter escreveu:
> > On 24.11.2011 19:47, Mauro Carvalho Chehab wrote:
> >> Em 24-11-2011 16:13, Manu Abraham escreveu:
> >>> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab
> >>> <mchehab@redhat.com> wrote:
> >>>> Em 24-11-2011 16:01, Manu Abraham escreveu:
> >>>>> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> >>>>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
> >>>>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
> >>>>>>> new API, but - pretty please - don't just blindly remove audio.h and
> >>>>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
> >>>>>>> *and more importantly* by applications. Yes, I know, you'd like to see
> >>>>>>> those out-of-tree drivers merged, but it isn't possible for many
> >>>>>>> reasons. And even if they were merged, you'd say "Port them and your
> >>>>>>> apps to V4L". No! That's not an option.
> >>>>>>
> >>>>>> I'm not breaking anything. All apps will still work.
> >>>>>>
> >>>>>> One option (and it depends on whether people like it or not) is to have
> >>>>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
> >>>>>> that these headers need to be replaced by the new av7110.h.
> >>>>>
> >>>>>
> >>>>> That won't work with other non av7110 hardware.
> >>>>
> >>>> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put
> >>>> a warning at the existing headers as-is, for now, putting them to be removed
> >>>> for a new kernel version, like 3.4.
> >>>
> >>>
> >>> No, that's not an option. The to-be merged saa716x driver depends on it.
> >>
> >> If the driver is not merged yet, it can be changed.
> >>
> >>> A DVB alone device need not depend V4L2 for it's operation.
> >>
> >> Why not? DVB drivers with IR should implement the input/event/IR API. DVB drivers with net
> >> should implement the Linux Network API.
> > 
> > DVB doesn't specify IR. There's no such thing like a DVB IR device.
> > 
> > IP over DVB is implemented transparently. No driver needs to do anything
> > but register its device's MAC address, therefore no driver implements
> > the Linux Network API.
> > 
> >> There is nothing wrong on using the ALSA API for audio and the V4L2 API for video,
> >> as both API fits the needs for decoding audio and video streams, and new features
> >> could be added there when needed.
> > 
> > Yes. There's nothing wrong with it and I'm not complaining. I don't care
> > about the implementation of the API in ivtv either. Just don't remove
> > the API from dvb-core, period.
> > 
> >> Duplicated API's that become legacy are removed with time. Just to mention two
> >> notable cases, this happened with the old audio stack (OSS), with the old Wireless
> >> stack.
> > 
> > I can still use iwconfig and linux/wireless.h is still available on my
> > system.
> 
> Yes, but both iwconfig and the API changed.
> 
> > ALSA still provides OSS emulation and the real OSS stack was marked
> > deprecated but still present for ages. 
> 
> OSS driver submission stopped years ago. I remember it clearly as they denied cx88-oss 
> driver submission (2004 or 2005). The saa7134-oss and bttv-oss drivers were dropped in 2007[1]
> in favor of the alsa drivers. The only hardware that are still there at OSS are the 
> legacy ones that probably no alsa developer has anymore.
> 
> [1] http://kerneltrap.org/mailarchive/linux-kernel/2007/11/9/398438/thread
> 
> > In contrast, you want to remove a
> > stable API and introduce a new *completely untested* API between 3.3 and
> > 3.4.
> 
> Please read the patches again. The API for the devices are still there:
> any binary compiled for older kernels will still work with av7110 and ivtv.
> With the patches applied, the only difference is that the header file has
> renamed, as they were moved to device-specific headers.
> 
> It should be noticed that, while both av7110 and ivtv uses the same ioctl's, av7110
> creates devices over /dev/dvb, while ivtv uses it over /dev/video?. So, in practice, 
> each driver has a different API.
> 
> There are no plans to remove the API for av7110. 
> 
> As discussed on this thread, it seems that the agreed plans for the ivtv API is to put
> it into the standard kernel procedure to get rid of legacy API. That means that the API 
> will be there for a few kernel versions.
> 
> Hans proposal is to remove the ivtv API on 3.8, with seems reasonable. So, the first
> API removal will happen in about 18 months from now (assuming about 2 months per kernel 
> version).
> 
> >> Do you have any issues that needs to be addressed by the V4L2 API for it to fit
> >> on your needs?
> > 
> > I don't want to be forced to use the V4L2 API for no reason and no gain.
> 
> As already explained on the other email, there are gains on using it, like the support
> for other types of encoding, the pipeline setup, sub-device control, shared buffer interface
> with GPU, proper support for SoC, etc.
> 
> Also, currently, just one device uses it (av7110). I don't think that the chipset is
> still manufactured. At least Google didn't help finding anything:
> 	http://www.google.com/search?q=av7110&tbm=shop&hl=en
> 
> On the other hand, there are thousands of devices using V4L2 API.
> 
> As both API's provide support for decoded video, one API has to be deprecated in favor
> to the other. We should select for deprecation the one that is more restrictive
> and that has just one driver using it.
> 
> > 
> >>> Also, it doesn't
> >>> make any sense to have device specific headers to be used by an application,
> >>> when drivers share more than one commonality.
> >>
> >> The only in-kernel driver using audio/video/osd is av7110.
> > 
> > Once again: Manu is going to submit a new driver soon.
> 
> The API is there for several years (since 2002?), with just one driver supporting it.
> It shouldn't be hard to convert Manu's work to the V4L2. I can help him on converting
> his driver to use the V4L2 API if needed.
> 
> > You're trying to remove an API that you've never used. The people who
> > use the API want it to stay.
> 
> As I said, it will stay there. Nobody will remove av7110 or remove the old API from it.
> 
> The idea is that no new driver should use it, as it is a legacy one-driver-only API.
> 
> If your complain is about the removal of audio.h, video.h and osd.h, then my proposal is
> to keep it there, writing a text that they are part of a deprecated API, but keeping
> the rest of the patches and not accepting anymore any submission using them, removing
> the ioctl's that aren't used by av7110 from them.

I have no problem with that. Something along those lines was my initial idea anyway,
but I forgot about it.

I've taken a quick look at Manu's driver: it uses very few ioctls from audio.h and
video.h and it seems that that driver uses the video device as a classic video output
device able to handle compressed video (I presume an elementary video stream).

Using V4L for the video part is easy. But where it becomes a bit more complicated is
with the audio device. I assume again that it receives a compressed audio stream
(is that correct?), and alsa doesn't handle that yet. I believe Samsung ran into the
same issue. For raw audio an alsa output is the logical choice, but for compressed
audio it is not so clear.

BTW, how does the OSD part work on saa716x? The only supported ioctl just gives data
to the chip, but it's not clear to me how that data should be interpreted. Pointers
are welcome.

The big picture that we should look at is that there are too many subsystems
involved in video output: drm, fbdev, v4l, and also dvb. Since there are only two
in-kernel drivers that use it, and one of those (ivtv) is easy to convert to a V4L
API, it makes sense to limit that API to just the remaining driver (av7110).

I hope and expect that we will have opportunities next year to talk to the
other subsystems (drm in particular) to improve cooperation and code sharing
between us.

With the ever increasing impact of SoCs in particular it is important to work
on that. This patch series is one (small) part of that.

Regards,

	Hans

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Hans Verkuil]

On Friday, November 25, 2011 16:18:52 Mauro Carvalho Chehab wrote:
> The V4L2 API complements the ALSA API. Audio streaming, audio format negotiation
> etc are via the ALSA API.
> 
> > Can you control pass-through of digital audio to SPDIF for example? Can
> > you control which decoder should be the master when synchronizing AV?
> 
> Patches for that are being proposed and should be merged soon. They are part
> of the set of patches under discussion with ALSA people, as part of the Media
> Controller API.

Can you provide a link to those patches? I haven't seen anything cross-posted
to linux-media.

Regards,

	Hans

Re: [RFCv2 PATCH 10/12] av7110: replace audio.h, video.h and osd.h by av7110.h.

[Klaus Schmidinger]

On 24.11.2011 14:39, Hans Verkuil wrote:
> From: Hans Verkuil<hans.verkuil@cisco.com>
>
> Create a new public header, av7110.h, that contains all the av7110
> specific audio, video and osd APIs that used to be defined in dvb/audio.h,
> dvb/video.h and dvb/osd.h. These APIs are no longer part of DVBv5 but are
> now av7110-specific.
>
> This decision was taken during the 2011 Prague V4L-DVB workshop.
>
> Ideally av7110 would be converted to use the replacement V4L2 MPEG
> decoder API, but that's a huge job for such an old driver.
>
> Signed-off-by: Hans Verkuil<hans.verkuil@cisco.com>

This would break applications, especially VDR.
I therefore strongly oppose this!
You may introduce new APIs as you like, but don't break the
existing ones that have worked for many years.

Nacked-by: Klaus Schmidinger <Klaus.Schmidinger@tvdr.de>

Klaus

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 25-11-2011 12:41, Andreas Oberritter escreveu:
> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>> If your complain is about the removal of audio.h, video.h
> 
> We're back on topic, thank you!
> 
>> and osd.h, then my proposal is
>> to keep it there, writing a text that they are part of a deprecated API,
> 
> That's exactly what I proposed. Well, you shouldn't write "deprecated",
> because it's not. Just explain - inside this text - when V4L2 should be
> preferred over DVB.

It is deprecated, as the API is not growing to fulfill today's needs, and
no patches adding new stuff to it to it will be accepted anymore.

>> but keeping
>> the rest of the patches
> 
> Which ones?

V4L2, ivtv and DocBook patches.

>> and not accepting anymore any submission using them
> 
> Why? First you complain about missing users and then don't want to allow
> any new ones.

I didn't complain about missing users. What I've said is that, between a
one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
the one-user API and mark it as deprecated.

Also, today's needs are properly already covered by V4L/ALSA/MC/subdev. 
It is easier to add what's missing there for DVB than to work the other
way around, and deprecate V4L2/ALSA/MC/subdev.

>> , removing
>> the ioctl's that aren't used by av7110 from them.
> 
> That's just stupid. I can easily provide a list of used and valuable
> ioctls, which need to remain present in order to not break userspace
> applications.

Those ioctl's aren't used by any Kernel driver, and not even documented.
So, why to keep/maintain them?

> Btw.: It's not easy to submit a driver for a SoC. Even if you are
> legally allowed to do it, you have to first merge and maintain the board
> support code before even thinking about multimedia.

Yes, I know that there's a long road for SoC drivers addition. Fortunately,
several vendors are now working to put their stuff upstream.

I heard that there are some upcoming changes intended to simplify it a little bit,
trying to make the architecture a little more generic, and put board-specific
configuration on userspace. I dunno the details.

Regards,
Mauro.

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 25-11-2011 13:22, Hans Verkuil escreveu:
> On Friday, November 25, 2011 14:48:02 Mauro Carvalho Chehab wrote:
>> Em 25-11-2011 10:00, Andreas Oberritter escreveu:
>>> On 24.11.2011 19:47, Mauro Carvalho Chehab wrote:
>>>> Em 24-11-2011 16:13, Manu Abraham escreveu:
>>>>> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab
>>>>> <mchehab@redhat.com> wrote:
>>>>>> Em 24-11-2011 16:01, Manu Abraham escreveu:
>>>>>>> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>>>>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>>>>>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>>>>>>>> new API, but - pretty please - don't just blindly remove audio.h and
>>>>>>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>>>>>>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>>>>>>>> those out-of-tree drivers merged, but it isn't possible for many
>>>>>>>>> reasons. And even if they were merged, you'd say "Port them and your
>>>>>>>>> apps to V4L". No! That's not an option.
>>>>>>>>
>>>>>>>> I'm not breaking anything. All apps will still work.
>>>>>>>>
>>>>>>>> One option (and it depends on whether people like it or not) is to have
>>>>>>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>>>>>>>> that these headers need to be replaced by the new av7110.h.
>>>>>>>
>>>>>>>
>>>>>>> That won't work with other non av7110 hardware.
>>>>>>
>>>>>> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put
>>>>>> a warning at the existing headers as-is, for now, putting them to be removed
>>>>>> for a new kernel version, like 3.4.
>>>>>
>>>>>
>>>>> No, that's not an option. The to-be merged saa716x driver depends on it.
>>>>
>>>> If the driver is not merged yet, it can be changed.
>>>>
>>>>> A DVB alone device need not depend V4L2 for it's operation.
>>>>
>>>> Why not? DVB drivers with IR should implement the input/event/IR API. DVB drivers with net
>>>> should implement the Linux Network API.
>>>
>>> DVB doesn't specify IR. There's no such thing like a DVB IR device.
>>>
>>> IP over DVB is implemented transparently. No driver needs to do anything
>>> but register its device's MAC address, therefore no driver implements
>>> the Linux Network API.
>>>
>>>> There is nothing wrong on using the ALSA API for audio and the V4L2 API for video,
>>>> as both API fits the needs for decoding audio and video streams, and new features
>>>> could be added there when needed.
>>>
>>> Yes. There's nothing wrong with it and I'm not complaining. I don't care
>>> about the implementation of the API in ivtv either. Just don't remove
>>> the API from dvb-core, period.
>>>
>>>> Duplicated API's that become legacy are removed with time. Just to mention two
>>>> notable cases, this happened with the old audio stack (OSS), with the old Wireless
>>>> stack.
>>>
>>> I can still use iwconfig and linux/wireless.h is still available on my
>>> system.
>>
>> Yes, but both iwconfig and the API changed.
>>
>>> ALSA still provides OSS emulation and the real OSS stack was marked
>>> deprecated but still present for ages. 
>>
>> OSS driver submission stopped years ago. I remember it clearly as they denied cx88-oss 
>> driver submission (2004 or 2005). The saa7134-oss and bttv-oss drivers were dropped in 2007[1]
>> in favor of the alsa drivers. The only hardware that are still there at OSS are the 
>> legacy ones that probably no alsa developer has anymore.
>>
>> [1] http://kerneltrap.org/mailarchive/linux-kernel/2007/11/9/398438/thread
>>
>>> In contrast, you want to remove a
>>> stable API and introduce a new *completely untested* API between 3.3 and
>>> 3.4.
>>
>> Please read the patches again. The API for the devices are still there:
>> any binary compiled for older kernels will still work with av7110 and ivtv.
>> With the patches applied, the only difference is that the header file has
>> renamed, as they were moved to device-specific headers.
>>
>> It should be noticed that, while both av7110 and ivtv uses the same ioctl's, av7110
>> creates devices over /dev/dvb, while ivtv uses it over /dev/video?. So, in practice, 
>> each driver has a different API.
>>
>> There are no plans to remove the API for av7110. 
>>
>> As discussed on this thread, it seems that the agreed plans for the ivtv API is to put
>> it into the standard kernel procedure to get rid of legacy API. That means that the API 
>> will be there for a few kernel versions.
>>
>> Hans proposal is to remove the ivtv API on 3.8, with seems reasonable. So, the first
>> API removal will happen in about 18 months from now (assuming about 2 months per kernel 
>> version).
>>
>>>> Do you have any issues that needs to be addressed by the V4L2 API for it to fit
>>>> on your needs?
>>>
>>> I don't want to be forced to use the V4L2 API for no reason and no gain.
>>
>> As already explained on the other email, there are gains on using it, like the support
>> for other types of encoding, the pipeline setup, sub-device control, shared buffer interface
>> with GPU, proper support for SoC, etc.
>>
>> Also, currently, just one device uses it (av7110). I don't think that the chipset is
>> still manufactured. At least Google didn't help finding anything:
>> 	http://www.google.com/search?q=av7110&tbm=shop&hl=en
>>
>> On the other hand, there are thousands of devices using V4L2 API.
>>
>> As both API's provide support for decoded video, one API has to be deprecated in favor
>> to the other. We should select for deprecation the one that is more restrictive
>> and that has just one driver using it.
>>
>>>
>>>>> Also, it doesn't
>>>>> make any sense to have device specific headers to be used by an application,
>>>>> when drivers share more than one commonality.
>>>>
>>>> The only in-kernel driver using audio/video/osd is av7110.
>>>
>>> Once again: Manu is going to submit a new driver soon.
>>
>> The API is there for several years (since 2002?), with just one driver supporting it.
>> It shouldn't be hard to convert Manu's work to the V4L2. I can help him on converting
>> his driver to use the V4L2 API if needed.
>>
>>> You're trying to remove an API that you've never used. The people who
>>> use the API want it to stay.
>>
>> As I said, it will stay there. Nobody will remove av7110 or remove the old API from it.
>>
>> The idea is that no new driver should use it, as it is a legacy one-driver-only API.
>>
>> If your complain is about the removal of audio.h, video.h and osd.h, then my proposal is
>> to keep it there, writing a text that they are part of a deprecated API, but keeping
>> the rest of the patches and not accepting anymore any submission using them, removing
>> the ioctl's that aren't used by av7110 from them.
> 
> I have no problem with that. Something along those lines was my initial idea anyway,
> but I forgot about it.
> 
> I've taken a quick look at Manu's driver: it uses very few ioctls from audio.h and
> video.h and it seems that that driver uses the video device as a classic video output
> device able to handle compressed video (I presume an elementary video stream).
> 
> Using V4L for the video part is easy. But where it becomes a bit more complicated is
> with the audio device. I assume again that it receives a compressed audio stream
> (is that correct?), and alsa doesn't handle that yet. I believe Samsung ran into the
> same issue. For raw audio an alsa output is the logical choice, but for compressed
> audio it is not so clear.

Sure that alsa doesn't handle compressed audio? a quick grep for MPEG under drivers/sound 
shows several things related to MPEG audio support:

$ git grep -i mpeg sound|wc -l
92

$ git grep -i mpeg sound

...
sound/core/pcm.c: FORMAT(MPEG),
sound/core/pcm.c: case AFMT_MPEG:
sound/core/pcm.c:         return "MPEG";
sound/core/pcm_misc.c:    [SNDRV_PCM_FORMAT_MPEG] = {
sound/drivers/vx/vx_cmd.h:#define MASK_VALID_PIPE_MPEG_PARAM      0x000040
sound/drivers/vx/vx_cmd.h:#define MASK_SET_PIPE_MPEG_PARAM        0x000002
sound/drivers/vx/vx_cmd.h:#define P_PREPARE_FOR_MPEG3_MASK                                0x02
sound/drivers/vx/vx_core.c:       if (chip->audio_info & VX_AUDIO_INFO_MPEG1)
sound/drivers/vx/vx_core.c:               snd_iprintf(buffer, " mpeg1");
sound/drivers/vx/vx_core.c:       if (chip->audio_info & VX_AUDIO_INFO_MPEG2)
sound/drivers/vx/vx_core.c:               snd_iprintf(buffer, " mpeg2");
...


So, I think that alsa accepts compressed audio.

> BTW, how does the OSD part work on saa716x? The only supported ioctl just gives data
> to the chip, but it's not clear to me how that data should be interpreted. Pointers
> are welcome.
> 
> The big picture that we should look at is that there are too many subsystems
> involved in video output: drm, fbdev, v4l, and also dvb. Since there are only two
> in-kernel drivers that use it, and one of those (ivtv) is easy to convert to a V4L
> API, it makes sense to limit that API to just the remaining driver (av7110).
> 
> I hope and expect that we will have opportunities next year to talk to the
> other subsystems (drm in particular) to improve cooperation and code sharing
> between us.
> 
> With the ever increasing impact of SoCs in particular it is important to work
> on that. This patch series is one (small) part of that.
> 
> Regards,
> 
> 	Hans
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Manu Abraham]

On Fri, Nov 25, 2011 at 8:52 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> On Friday, November 25, 2011 14:48:02 Mauro Carvalho Chehab wrote:
>> Em 25-11-2011 10:00, Andreas Oberritter escreveu:
>> > On 24.11.2011 19:47, Mauro Carvalho Chehab wrote:
>> >> Em 24-11-2011 16:13, Manu Abraham escreveu:
>> >>> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab
>> >>> <mchehab@redhat.com> wrote:
>> >>>> Em 24-11-2011 16:01, Manu Abraham escreveu:
>> >>>>> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> >>>>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>> >>>>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>> >>>>>>> new API, but - pretty please - don't just blindly remove audio.h and
>> >>>>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>> >>>>>>> *and more importantly* by applications. Yes, I know, you'd like to see
>> >>>>>>> those out-of-tree drivers merged, but it isn't possible for many
>> >>>>>>> reasons. And even if they were merged, you'd say "Port them and your
>> >>>>>>> apps to V4L". No! That's not an option.
>> >>>>>>
>> >>>>>> I'm not breaking anything. All apps will still work.
>> >>>>>>
>> >>>>>> One option (and it depends on whether people like it or not) is to have
>> >>>>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>> >>>>>> that these headers need to be replaced by the new av7110.h.
>> >>>>>
>> >>>>>
>> >>>>> That won't work with other non av7110 hardware.
>> >>>>
>> >>>> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put
>> >>>> a warning at the existing headers as-is, for now, putting them to be removed
>> >>>> for a new kernel version, like 3.4.
>> >>>
>> >>>
>> >>> No, that's not an option. The to-be merged saa716x driver depends on it.
>> >>
>> >> If the driver is not merged yet, it can be changed.
>> >>
>> >>> A DVB alone device need not depend V4L2 for it's operation.
>> >>
>> >> Why not? DVB drivers with IR should implement the input/event/IR API. DVB drivers with net
>> >> should implement the Linux Network API.
>> >
>> > DVB doesn't specify IR. There's no such thing like a DVB IR device.
>> >
>> > IP over DVB is implemented transparently. No driver needs to do anything
>> > but register its device's MAC address, therefore no driver implements
>> > the Linux Network API.
>> >
>> >> There is nothing wrong on using the ALSA API for audio and the V4L2 API for video,
>> >> as both API fits the needs for decoding audio and video streams, and new features
>> >> could be added there when needed.
>> >
>> > Yes. There's nothing wrong with it and I'm not complaining. I don't care
>> > about the implementation of the API in ivtv either. Just don't remove
>> > the API from dvb-core, period.
>> >
>> >> Duplicated API's that become legacy are removed with time. Just to mention two
>> >> notable cases, this happened with the old audio stack (OSS), with the old Wireless
>> >> stack.
>> >
>> > I can still use iwconfig and linux/wireless.h is still available on my
>> > system.
>>
>> Yes, but both iwconfig and the API changed.
>>
>> > ALSA still provides OSS emulation and the real OSS stack was marked
>> > deprecated but still present for ages.
>>
>> OSS driver submission stopped years ago. I remember it clearly as they denied cx88-oss
>> driver submission (2004 or 2005). The saa7134-oss and bttv-oss drivers were dropped in 2007[1]
>> in favor of the alsa drivers. The only hardware that are still there at OSS are the
>> legacy ones that probably no alsa developer has anymore.
>>
>> [1] http://kerneltrap.org/mailarchive/linux-kernel/2007/11/9/398438/thread
>>
>> > In contrast, you want to remove a
>> > stable API and introduce a new *completely untested* API between 3.3 and
>> > 3.4.
>>
>> Please read the patches again. The API for the devices are still there:
>> any binary compiled for older kernels will still work with av7110 and ivtv.
>> With the patches applied, the only difference is that the header file has
>> renamed, as they were moved to device-specific headers.
>>
>> It should be noticed that, while both av7110 and ivtv uses the same ioctl's, av7110
>> creates devices over /dev/dvb, while ivtv uses it over /dev/video?. So, in practice,
>> each driver has a different API.
>>
>> There are no plans to remove the API for av7110.
>>
>> As discussed on this thread, it seems that the agreed plans for the ivtv API is to put
>> it into the standard kernel procedure to get rid of legacy API. That means that the API
>> will be there for a few kernel versions.
>>
>> Hans proposal is to remove the ivtv API on 3.8, with seems reasonable. So, the first
>> API removal will happen in about 18 months from now (assuming about 2 months per kernel
>> version).
>>
>> >> Do you have any issues that needs to be addressed by the V4L2 API for it to fit
>> >> on your needs?
>> >
>> > I don't want to be forced to use the V4L2 API for no reason and no gain.
>>
>> As already explained on the other email, there are gains on using it, like the support
>> for other types of encoding, the pipeline setup, sub-device control, shared buffer interface
>> with GPU, proper support for SoC, etc.
>>
>> Also, currently, just one device uses it (av7110). I don't think that the chipset is
>> still manufactured. At least Google didn't help finding anything:
>>       http://www.google.com/search?q=av7110&tbm=shop&hl=en
>>
>> On the other hand, there are thousands of devices using V4L2 API.
>>
>> As both API's provide support for decoded video, one API has to be deprecated in favor
>> to the other. We should select for deprecation the one that is more restrictive
>> and that has just one driver using it.
>>
>> >
>> >>> Also, it doesn't
>> >>> make any sense to have device specific headers to be used by an application,
>> >>> when drivers share more than one commonality.
>> >>
>> >> The only in-kernel driver using audio/video/osd is av7110.
>> >
>> > Once again: Manu is going to submit a new driver soon.
>>
>> The API is there for several years (since 2002?), with just one driver supporting it.
>> It shouldn't be hard to convert Manu's work to the V4L2. I can help him on converting
>> his driver to use the V4L2 API if needed.
>>
>> > You're trying to remove an API that you've never used. The people who
>> > use the API want it to stay.
>>
>> As I said, it will stay there. Nobody will remove av7110 or remove the old API from it.
>>
>> The idea is that no new driver should use it, as it is a legacy one-driver-only API.
>>
>> If your complain is about the removal of audio.h, video.h and osd.h, then my proposal is
>> to keep it there, writing a text that they are part of a deprecated API, but keeping
>> the rest of the patches and not accepting anymore any submission using them, removing
>> the ioctl's that aren't used by av7110 from them.
>
> I have no problem with that. Something along those lines was my initial idea anyway,
> but I forgot about it.
>
> I've taken a quick look at Manu's driver: it uses very few ioctls from audio.h and
> video.h and it seems that that driver uses the video device as a classic video output
> device able to handle compressed video (I presume an elementary video stream).


How will you handle CI+ ? The CI+ descrambler is tightly married to
the DVB decoder.
So you will move the CA API also to V4L, eventually ?

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 25-11-2011 13:25, Hans Verkuil escreveu:
> On Friday, November 25, 2011 16:18:52 Mauro Carvalho Chehab wrote:
>> The V4L2 API complements the ALSA API. Audio streaming, audio format negotiation
>> etc are via the ALSA API.
>>
>>> Can you control pass-through of digital audio to SPDIF for example? Can
>>> you control which decoder should be the master when synchronizing AV?
>>
>> Patches for that are being proposed and should be merged soon. They are part
>> of the set of patches under discussion with ALSA people, as part of the Media
>> Controller API.
> 
> Can you provide a link to those patches? I haven't seen anything cross-posted
> to linux-media.

That was my understanding when I was discussing with Sakari about the MC presentation
for KS. I'll double check with him if he can provide us more details about the
status of this subject.

Regards,
Mauro

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Andreas Oberritter]

On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>>> If your complain is about the removal of audio.h, video.h
>>
>> We're back on topic, thank you!
>>
>>> and osd.h, then my proposal is
>>> to keep it there, writing a text that they are part of a deprecated API,
>>
>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
>> because it's not. Just explain - inside this text - when V4L2 should be
>> preferred over DVB.
> 
> It is deprecated, as the API is not growing to fulfill today's needs, and
> no patches adding new stuff to it to it will be accepted anymore.

Haha, nice one. "It doesn't grow because I don't allow it to." Great!

>>> but keeping
>>> the rest of the patches
>>
>> Which ones?
> 
> V4L2, ivtv and DocBook patches.

Fine.

>>> and not accepting anymore any submission using them
>>
>> Why? First you complain about missing users and then don't want to allow
>> any new ones.
> 
> I didn't complain about missing users. What I've said is that, between a
> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
> the one-user API and mark it as deprecated.

Your assumtion about only one user still isn't true.

> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev. 
> It is easier to add what's missing there for DVB than to work the other
> way around, and deprecate V4L2/ALSA/MC/subdev.

Yes. Please! Add it! But leave the DVB API alone!

>>> , removing
>>> the ioctl's that aren't used by av7110 from them.
>>
>> That's just stupid. I can easily provide a list of used and valuable
>> ioctls, which need to remain present in order to not break userspace
>> applications.
> 
> Those ioctl's aren't used by any Kernel driver, and not even documented.
> So, why to keep/maintain them?

If you already deprecated it, why bother deleting random stuff from it
that people are using?

There's a difference in keeping and maintaining something. You don't
need to maintain ioctls that haven't changed in years. Deleting
something is more work than letting it there to be used by those who
want to.

>> Btw.: It's not easy to submit a driver for a SoC. Even if you are
>> legally allowed to do it, you have to first merge and maintain the board
>> support code before even thinking about multimedia.
> 
> Yes, I know that there's a long road for SoC drivers addition. Fortunately,
> several vendors are now working to put their stuff upstream.
> 
> I heard that there are some upcoming changes intended to simplify it a little bit,
> trying to make the architecture a little more generic, and put board-specific
> configuration on userspace. I dunno the details.

Thanks for your help.

Regards,
Andreas

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 25-11-2011 13:58, Manu Abraham escreveu:
> On Fri, Nov 25, 2011 at 8:52 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> On Friday, November 25, 2011 14:48:02 Mauro Carvalho Chehab wrote:
>>> Em 25-11-2011 10:00, Andreas Oberritter escreveu:
>>>> On 24.11.2011 19:47, Mauro Carvalho Chehab wrote:
>>>>> Em 24-11-2011 16:13, Manu Abraham escreveu:
>>>>>> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab
>>>>>> <mchehab@redhat.com> wrote:
>>>>>>> Em 24-11-2011 16:01, Manu Abraham escreveu:
>>>>>>>> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>>>>>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>>>>>>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>>>>>>>>> new API, but - pretty please - don't just blindly remove audio.h and
>>>>>>>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>>>>>>>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>>>>>>>>> those out-of-tree drivers merged, but it isn't possible for many
>>>>>>>>>> reasons. And even if they were merged, you'd say "Port them and your
>>>>>>>>>> apps to V4L". No! That's not an option.
>>>>>>>>>
>>>>>>>>> I'm not breaking anything. All apps will still work.
>>>>>>>>>
>>>>>>>>> One option (and it depends on whether people like it or not) is to have
>>>>>>>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>>>>>>>>> that these headers need to be replaced by the new av7110.h.
>>>>>>>>
>>>>>>>>
>>>>>>>> That won't work with other non av7110 hardware.
>>>>>>>
>>>>>>> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put
>>>>>>> a warning at the existing headers as-is, for now, putting them to be removed
>>>>>>> for a new kernel version, like 3.4.
>>>>>>
>>>>>>
>>>>>> No, that's not an option. The to-be merged saa716x driver depends on it.
>>>>>
>>>>> If the driver is not merged yet, it can be changed.
>>>>>
>>>>>> A DVB alone device need not depend V4L2 for it's operation.
>>>>>
>>>>> Why not? DVB drivers with IR should implement the input/event/IR API. DVB drivers with net
>>>>> should implement the Linux Network API.
>>>>
>>>> DVB doesn't specify IR. There's no such thing like a DVB IR device.
>>>>
>>>> IP over DVB is implemented transparently. No driver needs to do anything
>>>> but register its device's MAC address, therefore no driver implements
>>>> the Linux Network API.
>>>>
>>>>> There is nothing wrong on using the ALSA API for audio and the V4L2 API for video,
>>>>> as both API fits the needs for decoding audio and video streams, and new features
>>>>> could be added there when needed.
>>>>
>>>> Yes. There's nothing wrong with it and I'm not complaining. I don't care
>>>> about the implementation of the API in ivtv either. Just don't remove
>>>> the API from dvb-core, period.
>>>>
>>>>> Duplicated API's that become legacy are removed with time. Just to mention two
>>>>> notable cases, this happened with the old audio stack (OSS), with the old Wireless
>>>>> stack.
>>>>
>>>> I can still use iwconfig and linux/wireless.h is still available on my
>>>> system.
>>>
>>> Yes, but both iwconfig and the API changed.
>>>
>>>> ALSA still provides OSS emulation and the real OSS stack was marked
>>>> deprecated but still present for ages.
>>>
>>> OSS driver submission stopped years ago. I remember it clearly as they denied cx88-oss
>>> driver submission (2004 or 2005). The saa7134-oss and bttv-oss drivers were dropped in 2007[1]
>>> in favor of the alsa drivers. The only hardware that are still there at OSS are the
>>> legacy ones that probably no alsa developer has anymore.
>>>
>>> [1] http://kerneltrap.org/mailarchive/linux-kernel/2007/11/9/398438/thread
>>>
>>>> In contrast, you want to remove a
>>>> stable API and introduce a new *completely untested* API between 3.3 and
>>>> 3.4.
>>>
>>> Please read the patches again. The API for the devices are still there:
>>> any binary compiled for older kernels will still work with av7110 and ivtv.
>>> With the patches applied, the only difference is that the header file has
>>> renamed, as they were moved to device-specific headers.
>>>
>>> It should be noticed that, while both av7110 and ivtv uses the same ioctl's, av7110
>>> creates devices over /dev/dvb, while ivtv uses it over /dev/video?. So, in practice,
>>> each driver has a different API.
>>>
>>> There are no plans to remove the API for av7110.
>>>
>>> As discussed on this thread, it seems that the agreed plans for the ivtv API is to put
>>> it into the standard kernel procedure to get rid of legacy API. That means that the API
>>> will be there for a few kernel versions.
>>>
>>> Hans proposal is to remove the ivtv API on 3.8, with seems reasonable. So, the first
>>> API removal will happen in about 18 months from now (assuming about 2 months per kernel
>>> version).
>>>
>>>>> Do you have any issues that needs to be addressed by the V4L2 API for it to fit
>>>>> on your needs?
>>>>
>>>> I don't want to be forced to use the V4L2 API for no reason and no gain.
>>>
>>> As already explained on the other email, there are gains on using it, like the support
>>> for other types of encoding, the pipeline setup, sub-device control, shared buffer interface
>>> with GPU, proper support for SoC, etc.
>>>
>>> Also, currently, just one device uses it (av7110). I don't think that the chipset is
>>> still manufactured. At least Google didn't help finding anything:
>>>       http://www.google.com/search?q=av7110&tbm=shop&hl=en
>>>
>>> On the other hand, there are thousands of devices using V4L2 API.
>>>
>>> As both API's provide support for decoded video, one API has to be deprecated in favor
>>> to the other. We should select for deprecation the one that is more restrictive
>>> and that has just one driver using it.
>>>
>>>>
>>>>>> Also, it doesn't
>>>>>> make any sense to have device specific headers to be used by an application,
>>>>>> when drivers share more than one commonality.
>>>>>
>>>>> The only in-kernel driver using audio/video/osd is av7110.
>>>>
>>>> Once again: Manu is going to submit a new driver soon.
>>>
>>> The API is there for several years (since 2002?), with just one driver supporting it.
>>> It shouldn't be hard to convert Manu's work to the V4L2. I can help him on converting
>>> his driver to use the V4L2 API if needed.
>>>
>>>> You're trying to remove an API that you've never used. The people who
>>>> use the API want it to stay.
>>>
>>> As I said, it will stay there. Nobody will remove av7110 or remove the old API from it.
>>>
>>> The idea is that no new driver should use it, as it is a legacy one-driver-only API.
>>>
>>> If your complain is about the removal of audio.h, video.h and osd.h, then my proposal is
>>> to keep it there, writing a text that they are part of a deprecated API, but keeping
>>> the rest of the patches and not accepting anymore any submission using them, removing
>>> the ioctl's that aren't used by av7110 from them.
>>
>> I have no problem with that. Something along those lines was my initial idea anyway,
>> but I forgot about it.
>>
>> I've taken a quick look at Manu's driver: it uses very few ioctls from audio.h and
>> video.h and it seems that that driver uses the video device as a classic video output
>> device able to handle compressed video (I presume an elementary video stream).
> 
> 
> How will you handle CI+ ? The CI+ descrambler is tightly married to
> the DVB decoder.
> So you will move the CA API also to V4L, eventually ?

No. The idea is to integrate frontend, demux and ca at the Media Controller, in order
to allow complex devices to use it. This should solve the issues with:
	drivers/staging/media/cxd2099/

allowing to move it out of staging.

Regards,
Mauro

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Manu Abraham]

On Fri, Nov 25, 2011 at 9:33 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 25-11-2011 13:58, Manu Abraham escreveu:
>> On Fri, Nov 25, 2011 at 8:52 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>> On Friday, November 25, 2011 14:48:02 Mauro Carvalho Chehab wrote:
>>>> Em 25-11-2011 10:00, Andreas Oberritter escreveu:
>>>>> On 24.11.2011 19:47, Mauro Carvalho Chehab wrote:
>>>>>> Em 24-11-2011 16:13, Manu Abraham escreveu:
>>>>>>> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab
>>>>>>> <mchehab@redhat.com> wrote:
>>>>>>>> Em 24-11-2011 16:01, Manu Abraham escreveu:
>>>>>>>>> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>>>>>>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>>>>>>>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>>>>>>>>>> new API, but - pretty please - don't just blindly remove audio.h and
>>>>>>>>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>>>>>>>>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>>>>>>>>>> those out-of-tree drivers merged, but it isn't possible for many
>>>>>>>>>>> reasons. And even if they were merged, you'd say "Port them and your
>>>>>>>>>>> apps to V4L". No! That's not an option.
>>>>>>>>>>
>>>>>>>>>> I'm not breaking anything. All apps will still work.
>>>>>>>>>>
>>>>>>>>>> One option (and it depends on whether people like it or not) is to have
>>>>>>>>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>>>>>>>>>> that these headers need to be replaced by the new av7110.h.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That won't work with other non av7110 hardware.
>>>>>>>>
>>>>>>>> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put
>>>>>>>> a warning at the existing headers as-is, for now, putting them to be removed
>>>>>>>> for a new kernel version, like 3.4.
>>>>>>>
>>>>>>>
>>>>>>> No, that's not an option. The to-be merged saa716x driver depends on it.
>>>>>>
>>>>>> If the driver is not merged yet, it can be changed.
>>>>>>
>>>>>>> A DVB alone device need not depend V4L2 for it's operation.
>>>>>>
>>>>>> Why not? DVB drivers with IR should implement the input/event/IR API. DVB drivers with net
>>>>>> should implement the Linux Network API.
>>>>>
>>>>> DVB doesn't specify IR. There's no such thing like a DVB IR device.
>>>>>
>>>>> IP over DVB is implemented transparently. No driver needs to do anything
>>>>> but register its device's MAC address, therefore no driver implements
>>>>> the Linux Network API.
>>>>>
>>>>>> There is nothing wrong on using the ALSA API for audio and the V4L2 API for video,
>>>>>> as both API fits the needs for decoding audio and video streams, and new features
>>>>>> could be added there when needed.
>>>>>
>>>>> Yes. There's nothing wrong with it and I'm not complaining. I don't care
>>>>> about the implementation of the API in ivtv either. Just don't remove
>>>>> the API from dvb-core, period.
>>>>>
>>>>>> Duplicated API's that become legacy are removed with time. Just to mention two
>>>>>> notable cases, this happened with the old audio stack (OSS), with the old Wireless
>>>>>> stack.
>>>>>
>>>>> I can still use iwconfig and linux/wireless.h is still available on my
>>>>> system.
>>>>
>>>> Yes, but both iwconfig and the API changed.
>>>>
>>>>> ALSA still provides OSS emulation and the real OSS stack was marked
>>>>> deprecated but still present for ages.
>>>>
>>>> OSS driver submission stopped years ago. I remember it clearly as they denied cx88-oss
>>>> driver submission (2004 or 2005). The saa7134-oss and bttv-oss drivers were dropped in 2007[1]
>>>> in favor of the alsa drivers. The only hardware that are still there at OSS are the
>>>> legacy ones that probably no alsa developer has anymore.
>>>>
>>>> [1] http://kerneltrap.org/mailarchive/linux-kernel/2007/11/9/398438/thread
>>>>
>>>>> In contrast, you want to remove a
>>>>> stable API and introduce a new *completely untested* API between 3.3 and
>>>>> 3.4.
>>>>
>>>> Please read the patches again. The API for the devices are still there:
>>>> any binary compiled for older kernels will still work with av7110 and ivtv.
>>>> With the patches applied, the only difference is that the header file has
>>>> renamed, as they were moved to device-specific headers.
>>>>
>>>> It should be noticed that, while both av7110 and ivtv uses the same ioctl's, av7110
>>>> creates devices over /dev/dvb, while ivtv uses it over /dev/video?. So, in practice,
>>>> each driver has a different API.
>>>>
>>>> There are no plans to remove the API for av7110.
>>>>
>>>> As discussed on this thread, it seems that the agreed plans for the ivtv API is to put
>>>> it into the standard kernel procedure to get rid of legacy API. That means that the API
>>>> will be there for a few kernel versions.
>>>>
>>>> Hans proposal is to remove the ivtv API on 3.8, with seems reasonable. So, the first
>>>> API removal will happen in about 18 months from now (assuming about 2 months per kernel
>>>> version).
>>>>
>>>>>> Do you have any issues that needs to be addressed by the V4L2 API for it to fit
>>>>>> on your needs?
>>>>>
>>>>> I don't want to be forced to use the V4L2 API for no reason and no gain.
>>>>
>>>> As already explained on the other email, there are gains on using it, like the support
>>>> for other types of encoding, the pipeline setup, sub-device control, shared buffer interface
>>>> with GPU, proper support for SoC, etc.
>>>>
>>>> Also, currently, just one device uses it (av7110). I don't think that the chipset is
>>>> still manufactured. At least Google didn't help finding anything:
>>>>       http://www.google.com/search?q=av7110&tbm=shop&hl=en
>>>>
>>>> On the other hand, there are thousands of devices using V4L2 API.
>>>>
>>>> As both API's provide support for decoded video, one API has to be deprecated in favor
>>>> to the other. We should select for deprecation the one that is more restrictive
>>>> and that has just one driver using it.
>>>>
>>>>>
>>>>>>> Also, it doesn't
>>>>>>> make any sense to have device specific headers to be used by an application,
>>>>>>> when drivers share more than one commonality.
>>>>>>
>>>>>> The only in-kernel driver using audio/video/osd is av7110.
>>>>>
>>>>> Once again: Manu is going to submit a new driver soon.
>>>>
>>>> The API is there for several years (since 2002?), with just one driver supporting it.
>>>> It shouldn't be hard to convert Manu's work to the V4L2. I can help him on converting
>>>> his driver to use the V4L2 API if needed.
>>>>
>>>>> You're trying to remove an API that you've never used. The people who
>>>>> use the API want it to stay.
>>>>
>>>> As I said, it will stay there. Nobody will remove av7110 or remove the old API from it.
>>>>
>>>> The idea is that no new driver should use it, as it is a legacy one-driver-only API.
>>>>
>>>> If your complain is about the removal of audio.h, video.h and osd.h, then my proposal is
>>>> to keep it there, writing a text that they are part of a deprecated API, but keeping
>>>> the rest of the patches and not accepting anymore any submission using them, removing
>>>> the ioctl's that aren't used by av7110 from them.
>>>
>>> I have no problem with that. Something along those lines was my initial idea anyway,
>>> but I forgot about it.
>>>
>>> I've taken a quick look at Manu's driver: it uses very few ioctls from audio.h and
>>> video.h and it seems that that driver uses the video device as a classic video output
>>> device able to handle compressed video (I presume an elementary video stream).
>>
>>
>> How will you handle CI+ ? The CI+ descrambler is tightly married to
>> the DVB decoder.
>> So you will move the CA API also to V4L, eventually ?
>
> No. The idea is to integrate frontend, demux and ca at the Media Controller,


You don't understand any godamn thing, do you ? Please do your homework,
before you post crap to the ML.


> in order
> to allow complex devices to use it. This should solve the issues with:
>        drivers/staging/media/cxd2099/
>
> allowing to move it out of staging.


That was pure politics from your side. Many said the same before,
I am not the first one to state that.

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 25-11-2011 14:03, Andreas Oberritter escreveu:
> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>>>> If your complain is about the removal of audio.h, video.h
>>>
>>> We're back on topic, thank you!
>>>
>>>> and osd.h, then my proposal is
>>>> to keep it there, writing a text that they are part of a deprecated API,
>>>
>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
>>> because it's not. Just explain - inside this text - when V4L2 should be
>>> preferred over DVB.
>>
>> It is deprecated, as the API is not growing to fulfill today's needs, and
>> no patches adding new stuff to it to it will be accepted anymore.
> 
> Haha, nice one. "It doesn't grow because I don't allow it to." Great!

No. It didn't grow because nobody cared with it for years:

Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.

Excluding Hans changes for using it on a pure V4L device, and other trivial
patches not related to API changes, the last API change on audio.h and video.h 
was this patch:
	commit f05cce863fa399dd79c5aa3896d608b8b86d8030
	Author: Andreas Oberritter <obi@linuxtv.org>
	Date:   Mon Feb 27 00:09:00 2006 -0300

	    V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls

	(yet not used on any upstream driver)

An then:
	commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
	Author: Linus Torvalds <torvalds@ppc970.osdl.org>
	Date:   Sat Apr 16 15:20:36 2005 -0700

	    Linux-2.6.12-rc2

No changes adding support for any in-kernel driver were ever added there.

So, it didn't grow over the last 5 or 6 years because nobody submitted
driver patches requiring new things or _even_ using it.

> 
>>>> but keeping
>>>> the rest of the patches
>>>
>>> Which ones?
>>
>> V4L2, ivtv and DocBook patches.
> 
> Fine.
> 
>>>> and not accepting anymore any submission using them
>>>
>>> Why? First you complain about missing users and then don't want to allow
>>> any new ones.
>>
>> I didn't complain about missing users. What I've said is that, between a
>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
>> the one-user API and mark it as deprecated.
> 
> Your assumtion about only one user still isn't true.
> 
>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev. 
>> It is easier to add what's missing there for DVB than to work the other
>> way around, and deprecate V4L2/ALSA/MC/subdev.
> 
> Yes. Please! Add it! But leave the DVB API alone!
> 
>>>> , removing
>>>> the ioctl's that aren't used by av7110 from them.
>>>
>>> That's just stupid. I can easily provide a list of used and valuable
>>> ioctls, which need to remain present in order to not break userspace
>>> applications.
>>
>> Those ioctl's aren't used by any Kernel driver, and not even documented.
>> So, why to keep/maintain them?
> 
> If you already deprecated it, why bother deleting random stuff from it
> that people are using?
> 
> There's a difference in keeping and maintaining something. You don't
> need to maintain ioctls that haven't changed in years. Deleting
> something is more work than letting it there to be used by those who
> want to.

Ok. Let's just keep the headers as is, just adding a comment that it is now
considered superseded.

>>> Btw.: It's not easy to submit a driver for a SoC. Even if you are
>>> legally allowed to do it, you have to first merge and maintain the board
>>> support code before even thinking about multimedia.
>>
>> Yes, I know that there's a long road for SoC drivers addition. Fortunately,
>> several vendors are now working to put their stuff upstream.
>>
>> I heard that there are some upcoming changes intended to simplify it a little bit,
>> trying to make the architecture a little more generic, and put board-specific
>> configuration on userspace. I dunno the details.
> 
> Thanks for your help.
> 
> Regards,
> Andreas

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Manu Abraham]

On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>>>>> If your complain is about the removal of audio.h, video.h
>>>>
>>>> We're back on topic, thank you!
>>>>
>>>>> and osd.h, then my proposal is
>>>>> to keep it there, writing a text that they are part of a deprecated API,
>>>>
>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
>>>> because it's not. Just explain - inside this text - when V4L2 should be
>>>> preferred over DVB.
>>>
>>> It is deprecated, as the API is not growing to fulfill today's needs, and
>>> no patches adding new stuff to it to it will be accepted anymore.
>>
>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
>
> No. It didn't grow because nobody cared with it for years:
>
> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
>
> Excluding Hans changes for using it on a pure V4L device, and other trivial
> patches not related to API changes, the last API change on audio.h and video.h
> was this patch:
>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
>        Author: Andreas Oberritter <obi@linuxtv.org>
>        Date:   Mon Feb 27 00:09:00 2006 -0300
>
>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
>
>        (yet not used on any upstream driver)
>
> An then:
>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
>        Date:   Sat Apr 16 15:20:36 2005 -0700
>
>            Linux-2.6.12-rc2
>
> No changes adding support for any in-kernel driver were ever added there.
>
> So, it didn't grow over the last 5 or 6 years because nobody submitted
> driver patches requiring new things or _even_ using it.
>
>>
>>>>> but keeping
>>>>> the rest of the patches
>>>>
>>>> Which ones?
>>>
>>> V4L2, ivtv and DocBook patches.
>>
>> Fine.
>>
>>>>> and not accepting anymore any submission using them
>>>>
>>>> Why? First you complain about missing users and then don't want to allow
>>>> any new ones.
>>>
>>> I didn't complain about missing users. What I've said is that, between a
>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
>>> the one-user API and mark it as deprecated.
>>
>> Your assumtion about only one user still isn't true.
>>
>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
>>> It is easier to add what's missing there for DVB than to work the other
>>> way around, and deprecate V4L2/ALSA/MC/subdev.
>>
>> Yes. Please! Add it! But leave the DVB API alone!
>>
>>>>> , removing
>>>>> the ioctl's that aren't used by av7110 from them.
>>>>
>>>> That's just stupid. I can easily provide a list of used and valuable
>>>> ioctls, which need to remain present in order to not break userspace
>>>> applications.
>>>
>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
>>> So, why to keep/maintain them?
>>
>> If you already deprecated it, why bother deleting random stuff from it
>> that people are using?
>>
>> There's a difference in keeping and maintaining something. You don't
>> need to maintain ioctls that haven't changed in years. Deleting
>> something is more work than letting it there to be used by those who
>> want to.
>
> Ok. Let's just keep the headers as is, just adding a comment that it is now
> considered superseded.


http://dictionary.reference.com/browse/superseded

to set aside or cause to be set aside as void, useless, or obsolete, usually
in favor of something mentioned; make obsolete: They superseded the
old statute with a new one.

No, that's not acceptable. New DVB devices as they come will make use
of the API and API changes might be applied.

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Andreas Oberritter]

On 25.11.2011 17:51, Manu Abraham wrote:
> On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
>>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
>>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
>>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>>>>>> If your complain is about the removal of audio.h, video.h
>>>>>
>>>>> We're back on topic, thank you!
>>>>>
>>>>>> and osd.h, then my proposal is
>>>>>> to keep it there, writing a text that they are part of a deprecated API,
>>>>>
>>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
>>>>> because it's not. Just explain - inside this text - when V4L2 should be
>>>>> preferred over DVB.
>>>>
>>>> It is deprecated, as the API is not growing to fulfill today's needs, and
>>>> no patches adding new stuff to it to it will be accepted anymore.
>>>
>>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
>>
>> No. It didn't grow because nobody cared with it for years:
>>
>> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
>>
>> Excluding Hans changes for using it on a pure V4L device, and other trivial
>> patches not related to API changes, the last API change on audio.h and video.h
>> was this patch:
>>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
>>        Author: Andreas Oberritter <obi@linuxtv.org>
>>        Date:   Mon Feb 27 00:09:00 2006 -0300
>>
>>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
>>
>>        (yet not used on any upstream driver)
>>
>> An then:
>>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>>        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
>>        Date:   Sat Apr 16 15:20:36 2005 -0700
>>
>>            Linux-2.6.12-rc2
>>
>> No changes adding support for any in-kernel driver were ever added there.
>>
>> So, it didn't grow over the last 5 or 6 years because nobody submitted
>> driver patches requiring new things or _even_ using it.
>>
>>>
>>>>>> but keeping
>>>>>> the rest of the patches
>>>>>
>>>>> Which ones?
>>>>
>>>> V4L2, ivtv and DocBook patches.
>>>
>>> Fine.
>>>
>>>>>> and not accepting anymore any submission using them
>>>>>
>>>>> Why? First you complain about missing users and then don't want to allow
>>>>> any new ones.
>>>>
>>>> I didn't complain about missing users. What I've said is that, between a
>>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
>>>> the one-user API and mark it as deprecated.
>>>
>>> Your assumtion about only one user still isn't true.
>>>
>>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
>>>> It is easier to add what's missing there for DVB than to work the other
>>>> way around, and deprecate V4L2/ALSA/MC/subdev.
>>>
>>> Yes. Please! Add it! But leave the DVB API alone!
>>>
>>>>>> , removing
>>>>>> the ioctl's that aren't used by av7110 from them.
>>>>>
>>>>> That's just stupid. I can easily provide a list of used and valuable
>>>>> ioctls, which need to remain present in order to not break userspace
>>>>> applications.
>>>>
>>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
>>>> So, why to keep/maintain them?
>>>
>>> If you already deprecated it, why bother deleting random stuff from it
>>> that people are using?
>>>
>>> There's a difference in keeping and maintaining something. You don't
>>> need to maintain ioctls that haven't changed in years. Deleting
>>> something is more work than letting it there to be used by those who
>>> want to.
>>
>> Ok. Let's just keep the headers as is, just adding a comment that it is now
>> considered superseded.

Thank you! This is a step into the right direction.

> http://dictionary.reference.com/browse/superseded
> 
> to set aside or cause to be set aside as void, useless, or obsolete, usually
> in favor of something mentioned; make obsolete: They superseded the
> old statute with a new one.
> 
> No, that's not acceptable. New DVB devices as they come will make use
> of the API and API changes might be applied.

Honestly, I think we all should accept this proposal and just hope that
the comment is going to be written objectively.

Regards,
Andreas

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Oliver Endriss]

On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote:
> On 25.11.2011 17:51, Manu Abraham wrote:
> > On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
> > <mchehab@redhat.com> wrote:
> >> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
> >>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
> >>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
> >>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
> >>>>>> If your complain is about the removal of audio.h, video.h
> >>>>>
> >>>>> We're back on topic, thank you!
> >>>>>
> >>>>>> and osd.h, then my proposal is
> >>>>>> to keep it there, writing a text that they are part of a deprecated API,
> >>>>>
> >>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
> >>>>> because it's not. Just explain - inside this text - when V4L2 should be
> >>>>> preferred over DVB.
> >>>>
> >>>> It is deprecated, as the API is not growing to fulfill today's needs, and
> >>>> no patches adding new stuff to it to it will be accepted anymore.
> >>>
> >>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
> >>
> >> No. It didn't grow because nobody cared with it for years:
> >>
> >> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
> >>
> >> Excluding Hans changes for using it on a pure V4L device, and other trivial
> >> patches not related to API changes, the last API change on audio.h and video.h
> >> was this patch:
> >>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
> >>        Author: Andreas Oberritter <obi@linuxtv.org>
> >>        Date:   Mon Feb 27 00:09:00 2006 -0300
> >>
> >>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
> >>
> >>        (yet not used on any upstream driver)
> >>
> >> An then:
> >>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
> >>        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
> >>        Date:   Sat Apr 16 15:20:36 2005 -0700
> >>
> >>            Linux-2.6.12-rc2
> >>
> >> No changes adding support for any in-kernel driver were ever added there.
> >>
> >> So, it didn't grow over the last 5 or 6 years because nobody submitted
> >> driver patches requiring new things or _even_ using it.
> >>
> >>>
> >>>>>> but keeping
> >>>>>> the rest of the patches
> >>>>>
> >>>>> Which ones?
> >>>>
> >>>> V4L2, ivtv and DocBook patches.
> >>>
> >>> Fine.
> >>>
> >>>>>> and not accepting anymore any submission using them
> >>>>>
> >>>>> Why? First you complain about missing users and then don't want to allow
> >>>>> any new ones.
> >>>>
> >>>> I didn't complain about missing users. What I've said is that, between a
> >>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
> >>>> the one-user API and mark it as deprecated.
> >>>
> >>> Your assumtion about only one user still isn't true.
> >>>
> >>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
> >>>> It is easier to add what's missing there for DVB than to work the other
> >>>> way around, and deprecate V4L2/ALSA/MC/subdev.
> >>>
> >>> Yes. Please! Add it! But leave the DVB API alone!
> >>>
> >>>>>> , removing
> >>>>>> the ioctl's that aren't used by av7110 from them.
> >>>>>
> >>>>> That's just stupid. I can easily provide a list of used and valuable
> >>>>> ioctls, which need to remain present in order to not break userspace
> >>>>> applications.
> >>>>
> >>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
> >>>> So, why to keep/maintain them?
> >>>
> >>> If you already deprecated it, why bother deleting random stuff from it
> >>> that people are using?
> >>>
> >>> There's a difference in keeping and maintaining something. You don't
> >>> need to maintain ioctls that haven't changed in years. Deleting
> >>> something is more work than letting it there to be used by those who
> >>> want to.
> >>
> >> Ok. Let's just keep the headers as is, just adding a comment that it is now
> >> considered superseded.
> 
> Thank you! This is a step into the right direction.
> 
> > http://dictionary.reference.com/browse/superseded
> > 
> > to set aside or cause to be set aside as void, useless, or obsolete, usually
> > in favor of something mentioned; make obsolete: They superseded the
> > old statute with a new one.
> > 
> > No, that's not acceptable. New DVB devices as they come will make use
> > of the API and API changes might be applied.
> 
> Honestly, I think we all should accept this proposal and just hope that
> the comment is going to be written objectively.

'Hoping' is not enough for me anymore. I am deeply disappointed.
Mauro and Hans have severely damaged my trust, that v4ldvb APIs are
stable in Linux, and how things are handled in this project.

So I request a public statement from the subsystem maintainer that
1. The DVB Decoder API will not be removed.
2. It can be updated if required (e.g. adding a missing function).
3. New drivers are allowed to use this architecture.
4. These driver will be accepted, if they follow the kernel standards.

The reason is simple: I need to know, whether this project is still
worth investing some time, or it is better to do something else.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------
Oliver Endriss                         ESCAPE GmbH
e-mail:  o.endriss@escape-edv.de       EDV-Loesungen
phone:   +49 (0)7722 21504             Birkenweg 9
fax:     +49 (0)7722 21510             D-78098 Triberg
----------------------------------------------------------------

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Manu Abraham]

On Sat, Nov 26, 2011 at 11:25 AM, Oliver Endriss <o.endriss@gmx.de> wrote:
> On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote:
>> On 25.11.2011 17:51, Manu Abraham wrote:
>> > On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
>> > <mchehab@redhat.com> wrote:
>> >> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
>> >>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
>> >>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
>> >>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>> >>>>>> If your complain is about the removal of audio.h, video.h
>> >>>>>
>> >>>>> We're back on topic, thank you!
>> >>>>>
>> >>>>>> and osd.h, then my proposal is
>> >>>>>> to keep it there, writing a text that they are part of a deprecated API,
>> >>>>>
>> >>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
>> >>>>> because it's not. Just explain - inside this text - when V4L2 should be
>> >>>>> preferred over DVB.
>> >>>>
>> >>>> It is deprecated, as the API is not growing to fulfill today's needs, and
>> >>>> no patches adding new stuff to it to it will be accepted anymore.
>> >>>
>> >>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
>> >>
>> >> No. It didn't grow because nobody cared with it for years:
>> >>
>> >> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
>> >>
>> >> Excluding Hans changes for using it on a pure V4L device, and other trivial
>> >> patches not related to API changes, the last API change on audio.h and video.h
>> >> was this patch:
>> >>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
>> >>        Author: Andreas Oberritter <obi@linuxtv.org>
>> >>        Date:   Mon Feb 27 00:09:00 2006 -0300
>> >>
>> >>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
>> >>
>> >>        (yet not used on any upstream driver)
>> >>
>> >> An then:
>> >>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>> >>        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
>> >>        Date:   Sat Apr 16 15:20:36 2005 -0700
>> >>
>> >>            Linux-2.6.12-rc2
>> >>
>> >> No changes adding support for any in-kernel driver were ever added there.
>> >>
>> >> So, it didn't grow over the last 5 or 6 years because nobody submitted
>> >> driver patches requiring new things or _even_ using it.
>> >>
>> >>>
>> >>>>>> but keeping
>> >>>>>> the rest of the patches
>> >>>>>
>> >>>>> Which ones?
>> >>>>
>> >>>> V4L2, ivtv and DocBook patches.
>> >>>
>> >>> Fine.
>> >>>
>> >>>>>> and not accepting anymore any submission using them
>> >>>>>
>> >>>>> Why? First you complain about missing users and then don't want to allow
>> >>>>> any new ones.
>> >>>>
>> >>>> I didn't complain about missing users. What I've said is that, between a
>> >>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
>> >>>> the one-user API and mark it as deprecated.
>> >>>
>> >>> Your assumtion about only one user still isn't true.
>> >>>
>> >>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
>> >>>> It is easier to add what's missing there for DVB than to work the other
>> >>>> way around, and deprecate V4L2/ALSA/MC/subdev.
>> >>>
>> >>> Yes. Please! Add it! But leave the DVB API alone!
>> >>>
>> >>>>>> , removing
>> >>>>>> the ioctl's that aren't used by av7110 from them.
>> >>>>>
>> >>>>> That's just stupid. I can easily provide a list of used and valuable
>> >>>>> ioctls, which need to remain present in order to not break userspace
>> >>>>> applications.
>> >>>>
>> >>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
>> >>>> So, why to keep/maintain them?
>> >>>
>> >>> If you already deprecated it, why bother deleting random stuff from it
>> >>> that people are using?
>> >>>
>> >>> There's a difference in keeping and maintaining something. You don't
>> >>> need to maintain ioctls that haven't changed in years. Deleting
>> >>> something is more work than letting it there to be used by those who
>> >>> want to.
>> >>
>> >> Ok. Let's just keep the headers as is, just adding a comment that it is now
>> >> considered superseded.
>>
>> Thank you! This is a step into the right direction.
>>
>> > http://dictionary.reference.com/browse/superseded
>> >
>> > to set aside or cause to be set aside as void, useless, or obsolete, usually
>> > in favor of something mentioned; make obsolete: They superseded the
>> > old statute with a new one.
>> >
>> > No, that's not acceptable. New DVB devices as they come will make use
>> > of the API and API changes might be applied.
>>
>> Honestly, I think we all should accept this proposal and just hope that
>> the comment is going to be written objectively.
>
> 'Hoping' is not enough for me anymore. I am deeply disappointed.
> Mauro and Hans have severely damaged my trust, that v4ldvb APIs are
> stable in Linux, and how things are handled in this project.
>
> So I request a public statement from the subsystem maintainer that
> 1. The DVB Decoder API will not be removed.
> 2. It can be updated if required (e.g. adding a missing function).
> 3. New drivers are allowed to use this architecture.
> 4. These driver will be accepted, if they follow the kernel standards.
>
> The reason is simple: I need to know, whether this project is still
> worth investing some time, or it is better to do something else.
>


I for one, share the same thoughts as Oliver. Mauro has always been
too clever with words, to play politics and hence my lack of trust in Mauro.
So, I request a statement from Mauro just as Oliver stated.

+1

Regards,
Manu

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Hans Verkuil]

On Friday, November 25, 2011 16:52:00 Mauro Carvalho Chehab wrote:
> Em 25-11-2011 13:22, Hans Verkuil escreveu:
> > Using V4L for the video part is easy. But where it becomes a bit more complicated is
> > with the audio device. I assume again that it receives a compressed audio stream
> > (is that correct?), and alsa doesn't handle that yet. I believe Samsung ran into the
> > same issue. For raw audio an alsa output is the logical choice, but for compressed
> > audio it is not so clear.
> 
> Sure that alsa doesn't handle compressed audio? a quick grep for MPEG under drivers/sound 
> shows several things related to MPEG audio support:
> 
> $ git grep -i mpeg sound|wc -l
> 92
> 
> $ git grep -i mpeg sound
> 
> ...
> sound/core/pcm.c: FORMAT(MPEG),
> sound/core/pcm.c: case AFMT_MPEG:
> sound/core/pcm.c:         return "MPEG";
> sound/core/pcm_misc.c:    [SNDRV_PCM_FORMAT_MPEG] = {
> sound/drivers/vx/vx_cmd.h:#define MASK_VALID_PIPE_MPEG_PARAM      0x000040
> sound/drivers/vx/vx_cmd.h:#define MASK_SET_PIPE_MPEG_PARAM        0x000002
> sound/drivers/vx/vx_cmd.h:#define P_PREPARE_FOR_MPEG3_MASK                                0x02
> sound/drivers/vx/vx_core.c:       if (chip->audio_info & VX_AUDIO_INFO_MPEG1)
> sound/drivers/vx/vx_core.c:               snd_iprintf(buffer, " mpeg1");
> sound/drivers/vx/vx_core.c:       if (chip->audio_info & VX_AUDIO_INFO_MPEG2)
> sound/drivers/vx/vx_core.c:               snd_iprintf(buffer, " mpeg2");
> ...
> 
> 
> So, I think that alsa accepts compressed audio.

Nice. I was told once that they didn't support it, but I'm clearly wrong.
Both MPEG and AC3 audio is supported.

Regards,

	Hans

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 26-11-2011 03:55, Oliver Endriss escreveu:
> On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote:
>> On 25.11.2011 17:51, Manu Abraham wrote:
>>> On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
>>> <mchehab@redhat.com> wrote:
>>>> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
>>>>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
>>>>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
>>>>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>>>>>>>> If your complain is about the removal of audio.h, video.h
>>>>>>>
>>>>>>> We're back on topic, thank you!
>>>>>>>
>>>>>>>> and osd.h, then my proposal is
>>>>>>>> to keep it there, writing a text that they are part of a deprecated API,
>>>>>>>
>>>>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
>>>>>>> because it's not. Just explain - inside this text - when V4L2 should be
>>>>>>> preferred over DVB.
>>>>>>
>>>>>> It is deprecated, as the API is not growing to fulfill today's needs, and
>>>>>> no patches adding new stuff to it to it will be accepted anymore.
>>>>>
>>>>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
>>>>
>>>> No. It didn't grow because nobody cared with it for years:
>>>>
>>>> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
>>>>
>>>> Excluding Hans changes for using it on a pure V4L device, and other trivial
>>>> patches not related to API changes, the last API change on audio.h and video.h
>>>> was this patch:
>>>>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
>>>>        Author: Andreas Oberritter <obi@linuxtv.org>
>>>>        Date:   Mon Feb 27 00:09:00 2006 -0300
>>>>
>>>>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
>>>>
>>>>        (yet not used on any upstream driver)
>>>>
>>>> An then:
>>>>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>>>>        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
>>>>        Date:   Sat Apr 16 15:20:36 2005 -0700
>>>>
>>>>            Linux-2.6.12-rc2
>>>>
>>>> No changes adding support for any in-kernel driver were ever added there.
>>>>
>>>> So, it didn't grow over the last 5 or 6 years because nobody submitted
>>>> driver patches requiring new things or _even_ using it.
>>>>
>>>>>
>>>>>>>> but keeping
>>>>>>>> the rest of the patches
>>>>>>>
>>>>>>> Which ones?
>>>>>>
>>>>>> V4L2, ivtv and DocBook patches.
>>>>>
>>>>> Fine.
>>>>>
>>>>>>>> and not accepting anymore any submission using them
>>>>>>>
>>>>>>> Why? First you complain about missing users and then don't want to allow
>>>>>>> any new ones.
>>>>>>
>>>>>> I didn't complain about missing users. What I've said is that, between a
>>>>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
>>>>>> the one-user API and mark it as deprecated.
>>>>>
>>>>> Your assumtion about only one user still isn't true.
>>>>>
>>>>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
>>>>>> It is easier to add what's missing there for DVB than to work the other
>>>>>> way around, and deprecate V4L2/ALSA/MC/subdev.
>>>>>
>>>>> Yes. Please! Add it! But leave the DVB API alone!
>>>>>
>>>>>>>> , removing
>>>>>>>> the ioctl's that aren't used by av7110 from them.
>>>>>>>
>>>>>>> That's just stupid. I can easily provide a list of used and valuable
>>>>>>> ioctls, which need to remain present in order to not break userspace
>>>>>>> applications.
>>>>>>
>>>>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
>>>>>> So, why to keep/maintain them?
>>>>>
>>>>> If you already deprecated it, why bother deleting random stuff from it
>>>>> that people are using?
>>>>>
>>>>> There's a difference in keeping and maintaining something. You don't
>>>>> need to maintain ioctls that haven't changed in years. Deleting
>>>>> something is more work than letting it there to be used by those who
>>>>> want to.
>>>>
>>>> Ok. Let's just keep the headers as is, just adding a comment that it is now
>>>> considered superseded.
>>
>> Thank you! This is a step into the right direction.
>>
>>> http://dictionary.reference.com/browse/superseded
>>>
>>> to set aside or cause to be set aside as void, useless, or obsolete, usually
>>> in favor of something mentioned; make obsolete: They superseded the
>>> old statute with a new one.
>>>
>>> No, that's not acceptable. New DVB devices as they come will make use
>>> of the API and API changes might be applied.
>>
>> Honestly, I think we all should accept this proposal and just hope that
>> the comment is going to be written objectively.
> 
> 'Hoping' is not enough for me anymore. I am deeply disappointed.
> Mauro and Hans have severely damaged my trust, that v4ldvb APIs are
> stable in Linux, and how things are handled in this project.
> 
> So I request a public statement from the subsystem maintainer that
> 1. The DVB Decoder API will not be removed.
> 2. It can be updated if required (e.g. adding a missing function).
> 3. New drivers are allowed to use this architecture.
> 4. These driver will be accepted, if they follow the kernel standards.
> 
> The reason is simple: I need to know, whether this project is still
> worth investing some time, or it is better to do something else.
> 

What it is agreed so far is to keep it there untouched, doing the evolution
for the decoder API via V4L2, in order to merge efforts on decoding
features, and use the proper existing systems to output decoded audio and
video streams (ALSA and V4L2). 

In other words, (item 1) the headers will stay there, with a note pointing 
that the evolution will be via V4L2. As the evolution will follow another
direction, I don't agree it your items 2, 3 and 4.

Regards,
Mauro.

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Hans Verkuil]

On Saturday, November 26, 2011 06:55:52 Oliver Endriss wrote:
> On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote:
> > On 25.11.2011 17:51, Manu Abraham wrote:
> > > On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
> > > <mchehab@redhat.com> wrote:
> > >> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
> > >>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
> > >>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
> > >>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
> > >>>>>> If your complain is about the removal of audio.h, video.h
> > >>>>>
> > >>>>> We're back on topic, thank you!
> > >>>>>
> > >>>>>> and osd.h, then my proposal is
> > >>>>>> to keep it there, writing a text that they are part of a deprecated API,
> > >>>>>
> > >>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
> > >>>>> because it's not. Just explain - inside this text - when V4L2 should be
> > >>>>> preferred over DVB.
> > >>>>
> > >>>> It is deprecated, as the API is not growing to fulfill today's needs, and
> > >>>> no patches adding new stuff to it to it will be accepted anymore.
> > >>>
> > >>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
> > >>
> > >> No. It didn't grow because nobody cared with it for years:
> > >>
> > >> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
> > >>
> > >> Excluding Hans changes for using it on a pure V4L device, and other trivial
> > >> patches not related to API changes, the last API change on audio.h and video.h
> > >> was this patch:
> > >>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
> > >>        Author: Andreas Oberritter <obi@linuxtv.org>
> > >>        Date:   Mon Feb 27 00:09:00 2006 -0300
> > >>
> > >>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
> > >>
> > >>        (yet not used on any upstream driver)
> > >>
> > >> An then:
> > >>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
> > >>        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
> > >>        Date:   Sat Apr 16 15:20:36 2005 -0700
> > >>
> > >>            Linux-2.6.12-rc2
> > >>
> > >> No changes adding support for any in-kernel driver were ever added there.
> > >>
> > >> So, it didn't grow over the last 5 or 6 years because nobody submitted
> > >> driver patches requiring new things or _even_ using it.
> > >>
> > >>>
> > >>>>>> but keeping
> > >>>>>> the rest of the patches
> > >>>>>
> > >>>>> Which ones?
> > >>>>
> > >>>> V4L2, ivtv and DocBook patches.
> > >>>
> > >>> Fine.
> > >>>
> > >>>>>> and not accepting anymore any submission using them
> > >>>>>
> > >>>>> Why? First you complain about missing users and then don't want to allow
> > >>>>> any new ones.
> > >>>>
> > >>>> I didn't complain about missing users. What I've said is that, between a
> > >>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
> > >>>> the one-user API and mark it as deprecated.
> > >>>
> > >>> Your assumtion about only one user still isn't true.
> > >>>
> > >>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
> > >>>> It is easier to add what's missing there for DVB than to work the other
> > >>>> way around, and deprecate V4L2/ALSA/MC/subdev.
> > >>>
> > >>> Yes. Please! Add it! But leave the DVB API alone!
> > >>>
> > >>>>>> , removing
> > >>>>>> the ioctl's that aren't used by av7110 from them.
> > >>>>>
> > >>>>> That's just stupid. I can easily provide a list of used and valuable
> > >>>>> ioctls, which need to remain present in order to not break userspace
> > >>>>> applications.
> > >>>>
> > >>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
> > >>>> So, why to keep/maintain them?
> > >>>
> > >>> If you already deprecated it, why bother deleting random stuff from it
> > >>> that people are using?
> > >>>
> > >>> There's a difference in keeping and maintaining something. You don't
> > >>> need to maintain ioctls that haven't changed in years. Deleting
> > >>> something is more work than letting it there to be used by those who
> > >>> want to.
> > >>
> > >> Ok. Let's just keep the headers as is, just adding a comment that it is now
> > >> considered superseded.
> > 
> > Thank you! This is a step into the right direction.
> > 
> > > http://dictionary.reference.com/browse/superseded
> > > 
> > > to set aside or cause to be set aside as void, useless, or obsolete, usually
> > > in favor of something mentioned; make obsolete: They superseded the
> > > old statute with a new one.
> > > 
> > > No, that's not acceptable. New DVB devices as they come will make use
> > > of the API and API changes might be applied.
> > 
> > Honestly, I think we all should accept this proposal and just hope that
> > the comment is going to be written objectively.
> 
> 'Hoping' is not enough for me anymore. I am deeply disappointed.
> Mauro and Hans have severely damaged my trust, that v4ldvb APIs are
> stable in Linux, and how things are handled in this project.
> 
> So I request a public statement from the subsystem maintainer that
> 1. The DVB Decoder API will not be removed.
> 2. It can be updated if required (e.g. adding a missing function).
> 3. New drivers are allowed to use this architecture.
> 4. These driver will be accepted, if they follow the kernel standards.
> 
> The reason is simple: I need to know, whether this project is still
> worth investing some time, or it is better to do something else.

1) There are two APIs that do the same thing: the DVB decoder API and the
   V4L2 API.
2) That's bad because it confuses driver developers and application developers
   who have to support *two* APIs to do the same thing.
3) The DVB decoder API is used in only one DVB driver (av7110), and in one
   V4L2 driver (ivtv). The latter is easily converted to V4L2 which leaves only
   one driver, av7110.
4) A decoder API has nothing to do with DVB as a standard, it simply takes
   the output of the DVB part of the hardware and decodes it to the output.
   That's basic V4L2 functionality.
5) Video output is present in quite a few V4L2 drivers (10 at a quick count)
   and that already includes support for decoders (just not decoder operations
   like PLAY/STOP/PAUSE/RESUME etc., that's where the V4L2 additions come in).
   Note that most of the video output drivers these days are from SoCs. That's
   where all the activity is these days. Ensuring that SoC vendors know what to
   do and that they have the right APIs and frameworks is an important part of
   our work these days.
6) So with 10 V4L2 video output drivers and 1 DVB output driver it is not
   hard to see that the easiest solution is to make the DVB decoder API an
   av7110-specific API and prohibit its use for new drivers.

What should be done with the existing audio.h, video.h and osd.h headers is
a separate issue. I believe that keeping them indefinitely is a bad move in
the long term if we decide to remove the DVB decoder API but that's just
my experience with similar situations (the removal of V4L1 springs to mind).
But I'll just follow what Mauro decides.

Yes, there are out-of-tree drivers that use the DVB decoder API. You know
the rules: if you are out-of-tree you do not count. That's true for everyone
maintaining an out-of-tree driver. I've maintained the out-of-tree ivtv
driver at the time and I know the pain. And that's also why SoC vendors are
now trying to get their video hardware supported in the kernel, because once
it is in much of that pain disappears.

Finally I want to mention again that the DVB subsystem isn't an ivory tower.
It doesn't exist in isolation. Particularly with the ever increasing
integration of video capabilities (include DVB) on SoCs cooperation between
subsystems is ever more important and will only increase in the future.

Regards,

	Hans

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 26-11-2011 09:32, Mauro Carvalho Chehab escreveu:
> Em 26-11-2011 03:55, Oliver Endriss escreveu:
>> On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote:
>>> On 25.11.2011 17:51, Manu Abraham wrote:
>>>> On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
>>>> <mchehab@redhat.com> wrote:
>>>>> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
>>>>>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
>>>>>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
>>>>>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>>>>>>>>> If your complain is about the removal of audio.h, video.h
>>>>>>>>
>>>>>>>> We're back on topic, thank you!
>>>>>>>>
>>>>>>>>> and osd.h, then my proposal is
>>>>>>>>> to keep it there, writing a text that they are part of a deprecated API,
>>>>>>>>
>>>>>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
>>>>>>>> because it's not. Just explain - inside this text - when V4L2 should be
>>>>>>>> preferred over DVB.
>>>>>>>
>>>>>>> It is deprecated, as the API is not growing to fulfill today's needs, and
>>>>>>> no patches adding new stuff to it to it will be accepted anymore.
>>>>>>
>>>>>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
>>>>>
>>>>> No. It didn't grow because nobody cared with it for years:
>>>>>
>>>>> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
>>>>>
>>>>> Excluding Hans changes for using it on a pure V4L device, and other trivial
>>>>> patches not related to API changes, the last API change on audio.h and video.h
>>>>> was this patch:
>>>>>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
>>>>>        Author: Andreas Oberritter <obi@linuxtv.org>
>>>>>        Date:   Mon Feb 27 00:09:00 2006 -0300
>>>>>
>>>>>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
>>>>>
>>>>>        (yet not used on any upstream driver)
>>>>>
>>>>> An then:
>>>>>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>>>>>        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
>>>>>        Date:   Sat Apr 16 15:20:36 2005 -0700
>>>>>
>>>>>            Linux-2.6.12-rc2
>>>>>
>>>>> No changes adding support for any in-kernel driver were ever added there.
>>>>>
>>>>> So, it didn't grow over the last 5 or 6 years because nobody submitted
>>>>> driver patches requiring new things or _even_ using it.
>>>>>
>>>>>>
>>>>>>>>> but keeping
>>>>>>>>> the rest of the patches
>>>>>>>>
>>>>>>>> Which ones?
>>>>>>>
>>>>>>> V4L2, ivtv and DocBook patches.
>>>>>>
>>>>>> Fine.
>>>>>>
>>>>>>>>> and not accepting anymore any submission using them
>>>>>>>>
>>>>>>>> Why? First you complain about missing users and then don't want to allow
>>>>>>>> any new ones.
>>>>>>>
>>>>>>> I didn't complain about missing users. What I've said is that, between a
>>>>>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
>>>>>>> the one-user API and mark it as deprecated.
>>>>>>
>>>>>> Your assumtion about only one user still isn't true.
>>>>>>
>>>>>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
>>>>>>> It is easier to add what's missing there for DVB than to work the other
>>>>>>> way around, and deprecate V4L2/ALSA/MC/subdev.
>>>>>>
>>>>>> Yes. Please! Add it! But leave the DVB API alone!
>>>>>>
>>>>>>>>> , removing
>>>>>>>>> the ioctl's that aren't used by av7110 from them.
>>>>>>>>
>>>>>>>> That's just stupid. I can easily provide a list of used and valuable
>>>>>>>> ioctls, which need to remain present in order to not break userspace
>>>>>>>> applications.
>>>>>>>
>>>>>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
>>>>>>> So, why to keep/maintain them?
>>>>>>
>>>>>> If you already deprecated it, why bother deleting random stuff from it
>>>>>> that people are using?
>>>>>>
>>>>>> There's a difference in keeping and maintaining something. You don't
>>>>>> need to maintain ioctls that haven't changed in years. Deleting
>>>>>> something is more work than letting it there to be used by those who
>>>>>> want to.
>>>>>
>>>>> Ok. Let's just keep the headers as is, just adding a comment that it is now
>>>>> considered superseded.
>>>
>>> Thank you! This is a step into the right direction.
>>>
>>>> http://dictionary.reference.com/browse/superseded
>>>>
>>>> to set aside or cause to be set aside as void, useless, or obsolete, usually
>>>> in favor of something mentioned; make obsolete: They superseded the
>>>> old statute with a new one.
>>>>
>>>> No, that's not acceptable. New DVB devices as they come will make use
>>>> of the API and API changes might be applied.
>>>
>>> Honestly, I think we all should accept this proposal and just hope that
>>> the comment is going to be written objectively.
>>
>> 'Hoping' is not enough for me anymore. I am deeply disappointed.
>> Mauro and Hans have severely damaged my trust, that v4ldvb APIs are
>> stable in Linux, and how things are handled in this project.
>>
>> So I request a public statement from the subsystem maintainer that
>> 1. The DVB Decoder API will not be removed.
>> 2. It can be updated if required (e.g. adding a missing function).
>> 3. New drivers are allowed to use this architecture.
>> 4. These driver will be accepted, if they follow the kernel standards.
>>
>> The reason is simple: I need to know, whether this project is still
>> worth investing some time, or it is better to do something else.
>>
> 
> What it is agreed so far is to keep it there untouched, doing the evolution
> for the decoder API via V4L2, in order to merge efforts on decoding
> features, and use the proper existing systems to output decoded audio and
> video streams (ALSA and V4L2). 
> 
> In other words, (item 1) the headers will stay there, with a note pointing 
> that the evolution will be via V4L2. As the evolution will follow another
> direction, I don't agree it your items 2, 3 and 4.

A small addendum: drivers can still be merged at staging. I can help the efforts
of porting them to use ALSA/V4L2.

Regards,
Mauro

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Oliver Endriss]

On Saturday 26 November 2011 12:59:11 Mauro Carvalho Chehab wrote:
> Em 26-11-2011 09:32, Mauro Carvalho Chehab escreveu:
> > Em 26-11-2011 03:55, Oliver Endriss escreveu:
> >> On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote:
> >>> On 25.11.2011 17:51, Manu Abraham wrote:
> >>>> On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
> >>>> <mchehab@redhat.com> wrote:
> >>>>> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
> >>>>>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
> >>>>>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
> >>>>>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
> >>>>>>>>> If your complain is about the removal of audio.h, video.h
> >>>>>>>>
> >>>>>>>> We're back on topic, thank you!
> >>>>>>>>
> >>>>>>>>> and osd.h, then my proposal is
> >>>>>>>>> to keep it there, writing a text that they are part of a deprecated API,
> >>>>>>>>
> >>>>>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
> >>>>>>>> because it's not. Just explain - inside this text - when V4L2 should be
> >>>>>>>> preferred over DVB.
> >>>>>>>
> >>>>>>> It is deprecated, as the API is not growing to fulfill today's needs, and
> >>>>>>> no patches adding new stuff to it to it will be accepted anymore.
> >>>>>>
> >>>>>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
> >>>>>
> >>>>> No. It didn't grow because nobody cared with it for years:
> >>>>>
> >>>>> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
> >>>>>
> >>>>> Excluding Hans changes for using it on a pure V4L device, and other trivial
> >>>>> patches not related to API changes, the last API change on audio.h and video.h
> >>>>> was this patch:
> >>>>>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
> >>>>>        Author: Andreas Oberritter <obi@linuxtv.org>
> >>>>>        Date:   Mon Feb 27 00:09:00 2006 -0300
> >>>>>
> >>>>>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
> >>>>>
> >>>>>        (yet not used on any upstream driver)
> >>>>>
> >>>>> An then:
> >>>>>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
> >>>>>        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
> >>>>>        Date:   Sat Apr 16 15:20:36 2005 -0700
> >>>>>
> >>>>>            Linux-2.6.12-rc2
> >>>>>
> >>>>> No changes adding support for any in-kernel driver were ever added there.
> >>>>>
> >>>>> So, it didn't grow over the last 5 or 6 years because nobody submitted
> >>>>> driver patches requiring new things or _even_ using it.
> >>>>>
> >>>>>>
> >>>>>>>>> but keeping
> >>>>>>>>> the rest of the patches
> >>>>>>>>
> >>>>>>>> Which ones?
> >>>>>>>
> >>>>>>> V4L2, ivtv and DocBook patches.
> >>>>>>
> >>>>>> Fine.
> >>>>>>
> >>>>>>>>> and not accepting anymore any submission using them
> >>>>>>>>
> >>>>>>>> Why? First you complain about missing users and then don't want to allow
> >>>>>>>> any new ones.
> >>>>>>>
> >>>>>>> I didn't complain about missing users. What I've said is that, between a
> >>>>>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
> >>>>>>> the one-user API and mark it as deprecated.
> >>>>>>
> >>>>>> Your assumtion about only one user still isn't true.
> >>>>>>
> >>>>>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
> >>>>>>> It is easier to add what's missing there for DVB than to work the other
> >>>>>>> way around, and deprecate V4L2/ALSA/MC/subdev.
> >>>>>>
> >>>>>> Yes. Please! Add it! But leave the DVB API alone!
> >>>>>>
> >>>>>>>>> , removing
> >>>>>>>>> the ioctl's that aren't used by av7110 from them.
> >>>>>>>>
> >>>>>>>> That's just stupid. I can easily provide a list of used and valuable
> >>>>>>>> ioctls, which need to remain present in order to not break userspace
> >>>>>>>> applications.
> >>>>>>>
> >>>>>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
> >>>>>>> So, why to keep/maintain them?
> >>>>>>
> >>>>>> If you already deprecated it, why bother deleting random stuff from it
> >>>>>> that people are using?
> >>>>>>
> >>>>>> There's a difference in keeping and maintaining something. You don't
> >>>>>> need to maintain ioctls that haven't changed in years. Deleting
> >>>>>> something is more work than letting it there to be used by those who
> >>>>>> want to.
> >>>>>
> >>>>> Ok. Let's just keep the headers as is, just adding a comment that it is now
> >>>>> considered superseded.
> >>>
> >>> Thank you! This is a step into the right direction.
> >>>
> >>>> http://dictionary.reference.com/browse/superseded
> >>>>
> >>>> to set aside or cause to be set aside as void, useless, or obsolete, usually
> >>>> in favor of something mentioned; make obsolete: They superseded the
> >>>> old statute with a new one.
> >>>>
> >>>> No, that's not acceptable. New DVB devices as they come will make use
> >>>> of the API and API changes might be applied.
> >>>
> >>> Honestly, I think we all should accept this proposal and just hope that
> >>> the comment is going to be written objectively.
> >>
> >> 'Hoping' is not enough for me anymore. I am deeply disappointed.
> >> Mauro and Hans have severely damaged my trust, that v4ldvb APIs are
> >> stable in Linux, and how things are handled in this project.
> >>
> >> So I request a public statement from the subsystem maintainer that
> >> 1. The DVB Decoder API will not be removed.
> >> 2. It can be updated if required (e.g. adding a missing function).
> >> 3. New drivers are allowed to use this architecture.
> >> 4. These driver will be accepted, if they follow the kernel standards.
> >>
> >> The reason is simple: I need to know, whether this project is still
> >> worth investing some time, or it is better to do something else.
> >>
> > 
> > What it is agreed so far is to keep it there untouched, doing the evolution
> > for the decoder API via V4L2, in order to merge efforts on decoding
> > features, and use the proper existing systems to output decoded audio and
> > video streams (ALSA and V4L2). 
> > 
> > In other words, (item 1) the headers will stay there, with a note pointing 
> > that the evolution will be via V4L2. As the evolution will follow another
> > direction, I don't agree it your items 2, 3 and 4.
> 
> A small addendum: drivers can still be merged at staging. I can help the efforts
> of porting them to use ALSA/V4L2.

Thanks for the clarification. This is exactly what I expected.
New drivers using the old API will end up in staging, and stay there
until they are converted to the new API.

I think it is time to think about drivers in user-space...

Bye,
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------
Oliver Endriss                         ESCAPE GmbH
e-mail:  o.endriss@escape-edv.de       EDV-Loesungen
phone:   +49 (0)7722 21504             Birkenweg 9
fax:     +49 (0)7722 21510             D-78098 Triberg
----------------------------------------------------------------

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Andreas Oberritter]

On 26.11.2011 12:49, Hans Verkuil wrote:
> On Saturday, November 26, 2011 06:55:52 Oliver Endriss wrote:
>> On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote:
>>> On 25.11.2011 17:51, Manu Abraham wrote:
>>>> On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
>>>> <mchehab@redhat.com> wrote:
>>>>> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
>>>>>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
>>>>>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
>>>>>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>>>>>>>>> If your complain is about the removal of audio.h, video.h
>>>>>>>>
>>>>>>>> We're back on topic, thank you!
>>>>>>>>
>>>>>>>>> and osd.h, then my proposal is
>>>>>>>>> to keep it there, writing a text that they are part of a deprecated API,
>>>>>>>>
>>>>>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
>>>>>>>> because it's not. Just explain - inside this text - when V4L2 should be
>>>>>>>> preferred over DVB.
>>>>>>>
>>>>>>> It is deprecated, as the API is not growing to fulfill today's needs, and
>>>>>>> no patches adding new stuff to it to it will be accepted anymore.
>>>>>>
>>>>>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
>>>>>
>>>>> No. It didn't grow because nobody cared with it for years:
>>>>>
>>>>> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
>>>>>
>>>>> Excluding Hans changes for using it on a pure V4L device, and other trivial
>>>>> patches not related to API changes, the last API change on audio.h and video.h
>>>>> was this patch:
>>>>>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
>>>>>        Author: Andreas Oberritter <obi@linuxtv.org>
>>>>>        Date:   Mon Feb 27 00:09:00 2006 -0300
>>>>>
>>>>>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
>>>>>
>>>>>        (yet not used on any upstream driver)
>>>>>
>>>>> An then:
>>>>>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>>>>>        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
>>>>>        Date:   Sat Apr 16 15:20:36 2005 -0700
>>>>>
>>>>>            Linux-2.6.12-rc2
>>>>>
>>>>> No changes adding support for any in-kernel driver were ever added there.
>>>>>
>>>>> So, it didn't grow over the last 5 or 6 years because nobody submitted
>>>>> driver patches requiring new things or _even_ using it.
>>>>>
>>>>>>
>>>>>>>>> but keeping
>>>>>>>>> the rest of the patches
>>>>>>>>
>>>>>>>> Which ones?
>>>>>>>
>>>>>>> V4L2, ivtv and DocBook patches.
>>>>>>
>>>>>> Fine.
>>>>>>
>>>>>>>>> and not accepting anymore any submission using them
>>>>>>>>
>>>>>>>> Why? First you complain about missing users and then don't want to allow
>>>>>>>> any new ones.
>>>>>>>
>>>>>>> I didn't complain about missing users. What I've said is that, between a
>>>>>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
>>>>>>> the one-user API and mark it as deprecated.
>>>>>>
>>>>>> Your assumtion about only one user still isn't true.
>>>>>>
>>>>>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
>>>>>>> It is easier to add what's missing there for DVB than to work the other
>>>>>>> way around, and deprecate V4L2/ALSA/MC/subdev.
>>>>>>
>>>>>> Yes. Please! Add it! But leave the DVB API alone!
>>>>>>
>>>>>>>>> , removing
>>>>>>>>> the ioctl's that aren't used by av7110 from them.
>>>>>>>>
>>>>>>>> That's just stupid. I can easily provide a list of used and valuable
>>>>>>>> ioctls, which need to remain present in order to not break userspace
>>>>>>>> applications.
>>>>>>>
>>>>>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
>>>>>>> So, why to keep/maintain them?
>>>>>>
>>>>>> If you already deprecated it, why bother deleting random stuff from it
>>>>>> that people are using?
>>>>>>
>>>>>> There's a difference in keeping and maintaining something. You don't
>>>>>> need to maintain ioctls that haven't changed in years. Deleting
>>>>>> something is more work than letting it there to be used by those who
>>>>>> want to.
>>>>>
>>>>> Ok. Let's just keep the headers as is, just adding a comment that it is now
>>>>> considered superseded.
>>>
>>> Thank you! This is a step into the right direction.
>>>
>>>> http://dictionary.reference.com/browse/superseded
>>>>
>>>> to set aside or cause to be set aside as void, useless, or obsolete, usually
>>>> in favor of something mentioned; make obsolete: They superseded the
>>>> old statute with a new one.
>>>>
>>>> No, that's not acceptable. New DVB devices as they come will make use
>>>> of the API and API changes might be applied.
>>>
>>> Honestly, I think we all should accept this proposal and just hope that
>>> the comment is going to be written objectively.
>>
>> 'Hoping' is not enough for me anymore. I am deeply disappointed.
>> Mauro and Hans have severely damaged my trust, that v4ldvb APIs are
>> stable in Linux, and how things are handled in this project.
>>
>> So I request a public statement from the subsystem maintainer that
>> 1. The DVB Decoder API will not be removed.
>> 2. It can be updated if required (e.g. adding a missing function).
>> 3. New drivers are allowed to use this architecture.
>> 4. These driver will be accepted, if they follow the kernel standards.
>>
>> The reason is simple: I need to know, whether this project is still
>> worth investing some time, or it is better to do something else.
> 
> 1) There are two APIs that do the same thing: the DVB decoder API and the
>    V4L2 API.
> 2) That's bad because it confuses driver developers and application developers
>    who have to support *two* APIs to do the same thing.

I've heard that more than once now from you and Mauro, but can you name
anyone who's actually so confused that it justifies creating confusion
for other people by breaking stuff?

Nobody has to support two APIs. You can choose which API to implement,
depending on what applications you want to be compatible to. Removing
one API doesn't make all applications compatible to the other one.

> 3) The DVB decoder API is used in only one DVB driver (av7110), and in one
>    V4L2 driver (ivtv). The latter is easily converted to V4L2 which leaves only
>    one driver, av7110.

OK. av7110 is the only driver implementing the DVB decoder API in-tree
and has always been. You're implying that it's not easy to convert it to
V4L2. Are you going to change V4L2 in a way that make it easy to convert
existing drivers *and* applications?

> 4) A decoder API has nothing to do with DVB as a standard, it simply takes
>    the output of the DVB part of the hardware and decodes it to the output.
>    That's basic V4L2 functionality.

A TS demux has nothing to do with DVB as a standard either, because it's
MPEG, not DVB. Still it's implemented in dvb-core. Should we remove it,
too, to break some more applications for fun?

> 5) Video output is present in quite a few V4L2 drivers (10 at a quick count)
>    and that already includes support for decoders (just not decoder operations
>    like PLAY/STOP/PAUSE/RESUME etc., that's where the V4L2 additions come in).
>    Note that most of the video output drivers these days are from SoCs. That's
>    where all the activity is these days. Ensuring that SoC vendors know what to
>    do and that they have the right APIs and frameworks is an important part of
>    our work these days.

That's very nice. If this API is attractive enough, I'm sure everybody
will switch to it eventually by choice.

> 6) So with 10 V4L2 video output drivers and 1 DVB output driver it is not
>    hard to see that the easiest solution is to make the DVB decoder API an
>    av7110-specific API and prohibit its use for new drivers.

So should we remove the few existing DVB-T2 drivers, too, because there
are way more DVB-T drivers and both basically just receive terrestrial
digital signals?

> What should be done with the existing audio.h, video.h and osd.h headers is
> a separate issue. I believe that keeping them indefinitely is a bad move in
> the long term if we decide to remove the DVB decoder API but that's just
> my experience with similar situations (the removal of V4L1 springs to mind).
> But I'll just follow what Mauro decides.

The name V4L2 implies that it's a successor of V4L1 and thus that its
goal was to replace V4L1. That somehow differs from DVB, unless you're
going to provide demux, frontend and CA APIs in V4L2, too. I'd really
like this to happen, if the result is going to be superior to the status
quo. However, please, without annoying all the people that much.

Second, by moving all contents of audio.h, video.h and osd.h to a *new*
header (av7110.h) that's going to stay, you're just breaking something
without even removing anything. Application developers won't magically
start to implement V4L2, but instead they will be forced by you to use
autoconf et al to detect the presence of av7110.h and use it instead.
What would be solved then?

> Yes, there are out-of-tree drivers that use the DVB decoder API. You know
> the rules: if you are out-of-tree you do not count. That's true for everyone
> maintaining an out-of-tree driver. I've maintained the out-of-tree ivtv
> driver at the time and I know the pain. And that's also why SoC vendors are
> now trying to get their video hardware supported in the kernel, because once
> it is in much of that pain disappears.

Until now, there was no pain involved for users of DVB decoder APIs.
You're causing it.

> Finally I want to mention again that the DVB subsystem isn't an ivory tower.
> It doesn't exist in isolation. Particularly with the ever increasing
> integration of video capabilities (include DVB) on SoCs cooperation between
> subsystems is ever more important and will only increase in the future.

Just provide an acceptable, attractive solution and everybody is going
to be your friend and follow your proposals.

Breaking user interfaces instead to force your interpretation of
"evolution" on other people is a no-go.

Currently, there is no guide on how to port applications using the DVB
decoder API to V4L2, right?

You're just creating a V4L2 API extension and pretend that it's well
established. Is there any proof that your API is complete enough to be
used as a drop-in replacement for DVB developers?

Have a nice weekend,
Andreas

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Manu Abraham]

On Sat, Nov 26, 2011 at 5:19 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> On Saturday, November 26, 2011 06:55:52 Oliver Endriss wrote:
>> On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote:
>> > On 25.11.2011 17:51, Manu Abraham wrote:
>> > > On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
>> > > <mchehab@redhat.com> wrote:
>> > >> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
>> > >>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
>> > >>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
>> > >>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>> > >>>>>> If your complain is about the removal of audio.h, video.h
>> > >>>>>
>> > >>>>> We're back on topic, thank you!
>> > >>>>>
>> > >>>>>> and osd.h, then my proposal is
>> > >>>>>> to keep it there, writing a text that they are part of a deprecated API,
>> > >>>>>
>> > >>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
>> > >>>>> because it's not. Just explain - inside this text - when V4L2 should be
>> > >>>>> preferred over DVB.
>> > >>>>
>> > >>>> It is deprecated, as the API is not growing to fulfill today's needs, and
>> > >>>> no patches adding new stuff to it to it will be accepted anymore.
>> > >>>
>> > >>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
>> > >>
>> > >> No. It didn't grow because nobody cared with it for years:
>> > >>
>> > >> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
>> > >>
>> > >> Excluding Hans changes for using it on a pure V4L device, and other trivial
>> > >> patches not related to API changes, the last API change on audio.h and video.h
>> > >> was this patch:
>> > >>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
>> > >>        Author: Andreas Oberritter <obi@linuxtv.org>
>> > >>        Date:   Mon Feb 27 00:09:00 2006 -0300
>> > >>
>> > >>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
>> > >>
>> > >>        (yet not used on any upstream driver)
>> > >>
>> > >> An then:
>> > >>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>> > >>        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
>> > >>        Date:   Sat Apr 16 15:20:36 2005 -0700
>> > >>
>> > >>            Linux-2.6.12-rc2
>> > >>
>> > >> No changes adding support for any in-kernel driver were ever added there.
>> > >>
>> > >> So, it didn't grow over the last 5 or 6 years because nobody submitted
>> > >> driver patches requiring new things or _even_ using it.
>> > >>
>> > >>>
>> > >>>>>> but keeping
>> > >>>>>> the rest of the patches
>> > >>>>>
>> > >>>>> Which ones?
>> > >>>>
>> > >>>> V4L2, ivtv and DocBook patches.
>> > >>>
>> > >>> Fine.
>> > >>>
>> > >>>>>> and not accepting anymore any submission using them
>> > >>>>>
>> > >>>>> Why? First you complain about missing users and then don't want to allow
>> > >>>>> any new ones.
>> > >>>>
>> > >>>> I didn't complain about missing users. What I've said is that, between a
>> > >>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
>> > >>>> the one-user API and mark it as deprecated.
>> > >>>
>> > >>> Your assumtion about only one user still isn't true.
>> > >>>
>> > >>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
>> > >>>> It is easier to add what's missing there for DVB than to work the other
>> > >>>> way around, and deprecate V4L2/ALSA/MC/subdev.
>> > >>>
>> > >>> Yes. Please! Add it! But leave the DVB API alone!
>> > >>>
>> > >>>>>> , removing
>> > >>>>>> the ioctl's that aren't used by av7110 from them.
>> > >>>>>
>> > >>>>> That's just stupid. I can easily provide a list of used and valuable
>> > >>>>> ioctls, which need to remain present in order to not break userspace
>> > >>>>> applications.
>> > >>>>
>> > >>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
>> > >>>> So, why to keep/maintain them?
>> > >>>
>> > >>> If you already deprecated it, why bother deleting random stuff from it
>> > >>> that people are using?
>> > >>>
>> > >>> There's a difference in keeping and maintaining something. You don't
>> > >>> need to maintain ioctls that haven't changed in years. Deleting
>> > >>> something is more work than letting it there to be used by those who
>> > >>> want to.
>> > >>
>> > >> Ok. Let's just keep the headers as is, just adding a comment that it is now
>> > >> considered superseded.
>> >
>> > Thank you! This is a step into the right direction.
>> >
>> > > http://dictionary.reference.com/browse/superseded
>> > >
>> > > to set aside or cause to be set aside as void, useless, or obsolete, usually
>> > > in favor of something mentioned; make obsolete: They superseded the
>> > > old statute with a new one.
>> > >
>> > > No, that's not acceptable. New DVB devices as they come will make use
>> > > of the API and API changes might be applied.
>> >
>> > Honestly, I think we all should accept this proposal and just hope that
>> > the comment is going to be written objectively.
>>
>> 'Hoping' is not enough for me anymore. I am deeply disappointed.
>> Mauro and Hans have severely damaged my trust, that v4ldvb APIs are
>> stable in Linux, and how things are handled in this project.
>>
>> So I request a public statement from the subsystem maintainer that
>> 1. The DVB Decoder API will not be removed.
>> 2. It can be updated if required (e.g. adding a missing function).
>> 3. New drivers are allowed to use this architecture.
>> 4. These driver will be accepted, if they follow the kernel standards.
>>
>> The reason is simple: I need to know, whether this project is still
>> worth investing some time, or it is better to do something else.
>
> 1) There are two APIs that do the same thing: the DVB decoder API and the
>   V4L2 API.
> 2) That's bad because it confuses driver developers and application developers
>   who have to support *two* APIs to do the same thing.
> 3) The DVB decoder API is used in only one DVB driver (av7110), and in one
>   V4L2 driver (ivtv). The latter is easily converted to V4L2 which leaves only
>   one driver, av7110.
> 4) A decoder API has nothing to do with DVB as a standard, it simply takes
>   the output of the DVB part of the hardware and decodes it to the output.
>   That's basic V4L2 functionality.


It does, with newer scrambling systems, the decoder is tightly tied to the
CA system(s) associated.

According to the CI+ specification:

"It is mandatory for the Application MMI to provide limited control
over the MPEG
decoders which enable the broadcast video and audio of the current service to
be presented, additionally a full frame I-frame may be used to provide rich
graphics backgrounds. The MMI Application may deny the application MMI
control of the MPEG decoder if a resource conflict results."

What you are talking about is FTA decoders which don't have any scrambling
control, but almost all newer DVB decoders supporting CI+ work that way.
If you look at any new digital TV/service, it comes with CI+ and many providers
switching over.

Because of a wrong decision, users cannot be denied using the same.

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Manu Abraham]

On Sat, Nov 26, 2011 at 5:19 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> On Saturday, November 26, 2011 06:55:52 Oliver Endriss wrote:
>> On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote:
>> > On 25.11.2011 17:51, Manu Abraham wrote:
>> > > On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
>> > > <mchehab@redhat.com> wrote:
>> > >> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
>> > >>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
>> > >>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
>> > >>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>> > >>>>>> If your complain is about the removal of audio.h, video.h
>> > >>>>>
>> > >>>>> We're back on topic, thank you!
>> > >>>>>
>> > >>>>>> and osd.h, then my proposal is
>> > >>>>>> to keep it there, writing a text that they are part of a deprecated API,
>> > >>>>>
>> > >>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
>> > >>>>> because it's not. Just explain - inside this text - when V4L2 should be
>> > >>>>> preferred over DVB.
>> > >>>>
>> > >>>> It is deprecated, as the API is not growing to fulfill today's needs, and
>> > >>>> no patches adding new stuff to it to it will be accepted anymore.
>> > >>>
>> > >>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
>> > >>
>> > >> No. It didn't grow because nobody cared with it for years:
>> > >>
>> > >> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
>> > >>
>> > >> Excluding Hans changes for using it on a pure V4L device, and other trivial
>> > >> patches not related to API changes, the last API change on audio.h and video.h
>> > >> was this patch:
>> > >>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
>> > >>        Author: Andreas Oberritter <obi@linuxtv.org>
>> > >>        Date:   Mon Feb 27 00:09:00 2006 -0300
>> > >>
>> > >>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
>> > >>
>> > >>        (yet not used on any upstream driver)
>> > >>
>> > >> An then:
>> > >>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>> > >>        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
>> > >>        Date:   Sat Apr 16 15:20:36 2005 -0700
>> > >>
>> > >>            Linux-2.6.12-rc2
>> > >>
>> > >> No changes adding support for any in-kernel driver were ever added there.
>> > >>
>> > >> So, it didn't grow over the last 5 or 6 years because nobody submitted
>> > >> driver patches requiring new things or _even_ using it.
>> > >>
>> > >>>
>> > >>>>>> but keeping
>> > >>>>>> the rest of the patches
>> > >>>>>
>> > >>>>> Which ones?
>> > >>>>
>> > >>>> V4L2, ivtv and DocBook patches.
>> > >>>
>> > >>> Fine.
>> > >>>
>> > >>>>>> and not accepting anymore any submission using them
>> > >>>>>
>> > >>>>> Why? First you complain about missing users and then don't want to allow
>> > >>>>> any new ones.
>> > >>>>
>> > >>>> I didn't complain about missing users. What I've said is that, between a
>> > >>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
>> > >>>> the one-user API and mark it as deprecated.
>> > >>>
>> > >>> Your assumtion about only one user still isn't true.
>> > >>>
>> > >>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
>> > >>>> It is easier to add what's missing there for DVB than to work the other
>> > >>>> way around, and deprecate V4L2/ALSA/MC/subdev.
>> > >>>
>> > >>> Yes. Please! Add it! But leave the DVB API alone!
>> > >>>
>> > >>>>>> , removing
>> > >>>>>> the ioctl's that aren't used by av7110 from them.
>> > >>>>>
>> > >>>>> That's just stupid. I can easily provide a list of used and valuable
>> > >>>>> ioctls, which need to remain present in order to not break userspace
>> > >>>>> applications.
>> > >>>>
>> > >>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
>> > >>>> So, why to keep/maintain them?
>> > >>>
>> > >>> If you already deprecated it, why bother deleting random stuff from it
>> > >>> that people are using?
>> > >>>
>> > >>> There's a difference in keeping and maintaining something. You don't
>> > >>> need to maintain ioctls that haven't changed in years. Deleting
>> > >>> something is more work than letting it there to be used by those who
>> > >>> want to.
>> > >>
>> > >> Ok. Let's just keep the headers as is, just adding a comment that it is now
>> > >> considered superseded.
>> >
>> > Thank you! This is a step into the right direction.
>> >
>> > > http://dictionary.reference.com/browse/superseded
>> > >
>> > > to set aside or cause to be set aside as void, useless, or obsolete, usually
>> > > in favor of something mentioned; make obsolete: They superseded the
>> > > old statute with a new one.
>> > >
>> > > No, that's not acceptable. New DVB devices as they come will make use
>> > > of the API and API changes might be applied.
>> >
>> > Honestly, I think we all should accept this proposal and just hope that
>> > the comment is going to be written objectively.
>>
>> 'Hoping' is not enough for me anymore. I am deeply disappointed.
>> Mauro and Hans have severely damaged my trust, that v4ldvb APIs are
>> stable in Linux, and how things are handled in this project.
>>
>> So I request a public statement from the subsystem maintainer that
>> 1. The DVB Decoder API will not be removed.
>> 2. It can be updated if required (e.g. adding a missing function).
>> 3. New drivers are allowed to use this architecture.
>> 4. These driver will be accepted, if they follow the kernel standards.
>>
>> The reason is simple: I need to know, whether this project is still
>> worth investing some time, or it is better to do something else.
>
> 1) There are two APIs that do the same thing: the DVB decoder API and the
>   V4L2 API.
> 2) That's bad because it confuses driver developers and application developers
>   who have to support *two* APIs to do the same thing.
> 3) The DVB decoder API is used in only one DVB driver (av7110), and in one
>   V4L2 driver (ivtv). The latter is easily converted to V4L2 which leaves only
>   one driver, av7110.
> 4) A decoder API has nothing to do with DVB as a standard, it simply takes
>   the output of the DVB part of the hardware and decodes it to the output.
>   That's basic V4L2 functionality.
> 5) Video output is present in quite a few V4L2 drivers (10 at a quick count)
>   and that already includes support for decoders (just not decoder operations
>   like PLAY/STOP/PAUSE/RESUME etc., that's where the V4L2 additions come in).
>   Note that most of the video output drivers these days are from SoCs. That's
>   where all the activity is these days. Ensuring that SoC vendors know what to
>   do and that they have the right APIs and frameworks is an important part of
>   our work these days.
> 6) So with 10 V4L2 video output drivers and 1 DVB output driver it is not
>   hard to see that the easiest solution is to make the DVB decoder API an
>   av7110-specific API and prohibit its use for new drivers.


As I said, moving all those to V4L makes it even more harder/impossible to be
used by DVB devices as used with newer descrambling systems where it is tightly
integrated, unless you move all of DVB to V4L, which then is more like moving
ALSA, Networking and others into V4L. Doesn't make any sense at all.

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 26-11-2011 18:27, Andreas Oberritter escreveu:
> On 26.11.2011 12:49, Hans Verkuil wrote:
>> On Saturday, November 26, 2011 06:55:52 Oliver Endriss wrote:
>>> On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote:
>>>> On 25.11.2011 17:51, Manu Abraham wrote:
>>>>> On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
>>>>> <mchehab@redhat.com> wrote:
>>>>>> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
>>>>>>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
>>>>>>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
>>>>>>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>>>>>>>>>> If your complain is about the removal of audio.h, video.h
>>>>>>>>>
>>>>>>>>> We're back on topic, thank you!
>>>>>>>>>
>>>>>>>>>> and osd.h, then my proposal is
>>>>>>>>>> to keep it there, writing a text that they are part of a deprecated API,
>>>>>>>>>
>>>>>>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
>>>>>>>>> because it's not. Just explain - inside this text - when V4L2 should be
>>>>>>>>> preferred over DVB.
>>>>>>>>
>>>>>>>> It is deprecated, as the API is not growing to fulfill today's needs, and
>>>>>>>> no patches adding new stuff to it to it will be accepted anymore.
>>>>>>>
>>>>>>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
>>>>>>
>>>>>> No. It didn't grow because nobody cared with it for years:
>>>>>>
>>>>>> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
>>>>>>
>>>>>> Excluding Hans changes for using it on a pure V4L device, and other trivial
>>>>>> patches not related to API changes, the last API change on audio.h and video.h
>>>>>> was this patch:
>>>>>>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
>>>>>>        Author: Andreas Oberritter <obi@linuxtv.org>
>>>>>>        Date:   Mon Feb 27 00:09:00 2006 -0300
>>>>>>
>>>>>>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
>>>>>>
>>>>>>        (yet not used on any upstream driver)
>>>>>>
>>>>>> An then:
>>>>>>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>>>>>>        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
>>>>>>        Date:   Sat Apr 16 15:20:36 2005 -0700
>>>>>>
>>>>>>            Linux-2.6.12-rc2
>>>>>>
>>>>>> No changes adding support for any in-kernel driver were ever added there.
>>>>>>
>>>>>> So, it didn't grow over the last 5 or 6 years because nobody submitted
>>>>>> driver patches requiring new things or _even_ using it.
>>>>>>
>>>>>>>
>>>>>>>>>> but keeping
>>>>>>>>>> the rest of the patches
>>>>>>>>>
>>>>>>>>> Which ones?
>>>>>>>>
>>>>>>>> V4L2, ivtv and DocBook patches.
>>>>>>>
>>>>>>> Fine.
>>>>>>>
>>>>>>>>>> and not accepting anymore any submission using them
>>>>>>>>>
>>>>>>>>> Why? First you complain about missing users and then don't want to allow
>>>>>>>>> any new ones.
>>>>>>>>
>>>>>>>> I didn't complain about missing users. What I've said is that, between a
>>>>>>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
>>>>>>>> the one-user API and mark it as deprecated.
>>>>>>>
>>>>>>> Your assumtion about only one user still isn't true.
>>>>>>>
>>>>>>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
>>>>>>>> It is easier to add what's missing there for DVB than to work the other
>>>>>>>> way around, and deprecate V4L2/ALSA/MC/subdev.
>>>>>>>
>>>>>>> Yes. Please! Add it! But leave the DVB API alone!
>>>>>>>
>>>>>>>>>> , removing
>>>>>>>>>> the ioctl's that aren't used by av7110 from them.
>>>>>>>>>
>>>>>>>>> That's just stupid. I can easily provide a list of used and valuable
>>>>>>>>> ioctls, which need to remain present in order to not break userspace
>>>>>>>>> applications.
>>>>>>>>
>>>>>>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
>>>>>>>> So, why to keep/maintain them?
>>>>>>>
>>>>>>> If you already deprecated it, why bother deleting random stuff from it
>>>>>>> that people are using?
>>>>>>>
>>>>>>> There's a difference in keeping and maintaining something. You don't
>>>>>>> need to maintain ioctls that haven't changed in years. Deleting
>>>>>>> something is more work than letting it there to be used by those who
>>>>>>> want to.
>>>>>>
>>>>>> Ok. Let's just keep the headers as is, just adding a comment that it is now
>>>>>> considered superseded.
>>>>
>>>> Thank you! This is a step into the right direction.
>>>>
>>>>> http://dictionary.reference.com/browse/superseded
>>>>>
>>>>> to set aside or cause to be set aside as void, useless, or obsolete, usually
>>>>> in favor of something mentioned; make obsolete: They superseded the
>>>>> old statute with a new one.
>>>>>
>>>>> No, that's not acceptable. New DVB devices as they come will make use
>>>>> of the API and API changes might be applied.
>>>>
>>>> Honestly, I think we all should accept this proposal and just hope that
>>>> the comment is going to be written objectively.
>>>
>>> 'Hoping' is not enough for me anymore. I am deeply disappointed.
>>> Mauro and Hans have severely damaged my trust, that v4ldvb APIs are
>>> stable in Linux, and how things are handled in this project.
>>>
>>> So I request a public statement from the subsystem maintainer that
>>> 1. The DVB Decoder API will not be removed.
>>> 2. It can be updated if required (e.g. adding a missing function).
>>> 3. New drivers are allowed to use this architecture.
>>> 4. These driver will be accepted, if they follow the kernel standards.
>>>
>>> The reason is simple: I need to know, whether this project is still
>>> worth investing some time, or it is better to do something else.
>>
>> 1) There are two APIs that do the same thing: the DVB decoder API and the
>>    V4L2 API.
>> 2) That's bad because it confuses driver developers and application developers
>>    who have to support *two* APIs to do the same thing.
> 
> I've heard that more than once now from you and Mauro, but can you name
> anyone who's actually so confused that it justifies creating confusion
> for other people by breaking stuff?
> 
> Nobody has to support two APIs. You can choose which API to implement,
> depending on what applications you want to be compatible to. Removing
> one API doesn't make all applications compatible to the other one.
> 
>> 3) The DVB decoder API is used in only one DVB driver (av7110), and in one
>>    V4L2 driver (ivtv). The latter is easily converted to V4L2 which leaves only
>>    one driver, av7110.
> 
> OK. av7110 is the only driver implementing the DVB decoder API in-tree
> and has always been. You're implying that it's not easy to convert it to
> V4L2. Are you going to change V4L2 in a way that make it easy to convert
> existing drivers *and* applications?

It shouldn't be hard to support av7110 at V4L2, but it requires someone with the
hardware for doing that.

> 
>> 4) A decoder API has nothing to do with DVB as a standard, it simply takes
>>    the output of the DVB part of the hardware and decodes it to the output.
>>    That's basic V4L2 functionality.
> 
> A TS demux has nothing to do with DVB as a standard either, because it's
> MPEG, not DVB. Still it's implemented in dvb-core. Should we remove it,
> too, to break some more applications for fun?

There's no duplication with TS demux, as only the DVB API does that.

>> 5) Video output is present in quite a few V4L2 drivers (10 at a quick count)
>>    and that already includes support for decoders (just not decoder operations
>>    like PLAY/STOP/PAUSE/RESUME etc., that's where the V4L2 additions come in).
>>    Note that most of the video output drivers these days are from SoCs. That's
>>    where all the activity is these days. Ensuring that SoC vendors know what to
>>    do and that they have the right APIs and frameworks is an important part of
>>    our work these days.
> 
> That's very nice. If this API is attractive enough, I'm sure everybody
> will switch to it eventually by choice.
> 
>> 6) So with 10 V4L2 video output drivers and 1 DVB output driver it is not
>>    hard to see that the easiest solution is to make the DVB decoder API an
>>    av7110-specific API and prohibit its use for new drivers.
> 
> So should we remove the few existing DVB-T2 drivers, too, because there
> are way more DVB-T drivers and both basically just receive terrestrial
> digital signals?

Please don't use silly arguments. The efforts are to solve API conflicts,
not to remove drivers. There's just one API that supports DVB T/T2. It should
be kept there, growing to support newer standards as needed.

Yet, if someone comes with a patch proposing adding a new API outside the DVB API 
for a supported or a new delivery system, such patch will be rejected, and the
developer will be pointed to use the right API's.

>> What should be done with the existing audio.h, video.h and osd.h headers is
>> a separate issue. I believe that keeping them indefinitely is a bad move in
>> the long term if we decide to remove the DVB decoder API but that's just
>> my experience with similar situations (the removal of V4L1 springs to mind).
>> But I'll just follow what Mauro decides.
> 
> The name V4L2 implies that it's a successor of V4L1 and thus that its
> goal was to replace V4L1. That somehow differs from DVB, unless you're
> going to provide demux, frontend and CA APIs in V4L2, too. I'd really
> like this to happen, if the result is going to be superior to the status
> quo. However, please, without annoying all the people that much.

The V4L API (both versions 1 and 2) were designed to control video streams.

I don't think we should extend the V4L API to cover DVB inside it. The
frontend, demux and CI API's are well designed, and they don't conflict with
any other Linux Kernel API's. The net API integrates nicely with the Linux
network stack, so, there's nothing more to touch on them.

> Second, by moving all contents of audio.h, video.h and osd.h to a *new*
> header (av7110.h) that's going to stay, you're just breaking something
> without even removing anything. Application developers won't magically
> start to implement V4L2, but instead they will be forced by you to use
> autoconf et al to detect the presence of av7110.h and use it instead.
> What would be solved then?

We've already agreed to keep the headers there.

>> Yes, there are out-of-tree drivers that use the DVB decoder API. You know
>> the rules: if you are out-of-tree you do not count. That's true for everyone
>> maintaining an out-of-tree driver. I've maintained the out-of-tree ivtv
>> driver at the time and I know the pain. And that's also why SoC vendors are
>> now trying to get their video hardware supported in the kernel, because once
>> it is in much of that pain disappears.
> 
> Until now, there was no pain involved for users of DVB decoder APIs.
> You're causing it.

I can't see any pain on deciding that future developments should be to use
the decoder API that exists in V4L2/ALSA.

> 
>> Finally I want to mention again that the DVB subsystem isn't an ivory tower.
>> It doesn't exist in isolation. Particularly with the ever increasing
>> integration of video capabilities (include DVB) on SoCs cooperation between
>> subsystems is ever more important and will only increase in the future.
> 
> Just provide an acceptable, attractive solution and everybody is going
> to be your friend and follow your proposals.
> 
> Breaking user interfaces instead to force your interpretation of
> "evolution" on other people is a no-go.

Nobody is breaking user interfaces. Even on Hans proposal, nothing breaks,
except for the header rename. With the agreed proposal of preserving the
headers, even this won't break.

> Currently, there is no guide on how to port applications using the DVB
> decoder API to V4L2, right?
> 
> You're just creating a V4L2 API extension and pretend that it's well
> established. Is there any proof that your API is complete enough to be
> used as a drop-in replacement for DVB developers?

This is a nice example where a driver implementing the new API is
required. The ivtv driver brings usage of some requred features. As
av7110 uses a few more ioctls, a patch converting it to use V4L2 
(or adding a new driver with similar features) might need to add some
new V4L2 controls.

If you're not familiar with V4L2 (it is defined at include/linux/videodev2.h), 
the controls interface is close to the DVBv5 frontend API. Controls are used 
to adjust things like bright, contrast, white balance, encoder/decoder 
parameters, etc, and ioctl's are provided to query the supported controls,
to create user-friendy menus for them, and to get/set one or several controls.

Each control is defined as:

struct v4l2_queryctrl {
	__u32		     id;
	enum v4l2_ctrl_type  type;
	__u8		     name[32];	/* Whatever */
	__s32		     minimum;	/* Note signedness */
	__s32		     maximum;
	__s32		     step;
	__s32		     default_value;
	__u32                flags;
	__u32		     reserved[2];
};

So, they have a string name, maximum/minimum/step/default values, and can belong
to several different types, and are sub-divided into classes of control.

For example, the MPEG-1/2 stream class is currently defined as:

#define V4L2_CID_MPEG_STREAM_TYPE 		(V4L2_CID_MPEG_BASE+0)
enum v4l2_mpeg_stream_type {
	V4L2_MPEG_STREAM_TYPE_MPEG2_PS   = 0, /* MPEG-2 program stream */
	V4L2_MPEG_STREAM_TYPE_MPEG2_TS   = 1, /* MPEG-2 transport stream */
	V4L2_MPEG_STREAM_TYPE_MPEG1_SS   = 2, /* MPEG-1 system stream */
	V4L2_MPEG_STREAM_TYPE_MPEG2_DVD  = 3, /* MPEG-2 DVD-compatible stream */
	V4L2_MPEG_STREAM_TYPE_MPEG1_VCD  = 4, /* MPEG-1 VCD-compatible stream */
	V4L2_MPEG_STREAM_TYPE_MPEG2_SVCD = 5, /* MPEG-2 SVCD-compatible stream */
};
#define V4L2_CID_MPEG_STREAM_PID_PMT 		(V4L2_CID_MPEG_BASE+1)
#define V4L2_CID_MPEG_STREAM_PID_AUDIO 		(V4L2_CID_MPEG_BASE+2)
#define V4L2_CID_MPEG_STREAM_PID_VIDEO 		(V4L2_CID_MPEG_BASE+3)
#define V4L2_CID_MPEG_STREAM_PID_PCR 		(V4L2_CID_MPEG_BASE+4)
#define V4L2_CID_MPEG_STREAM_PES_ID_AUDIO 	(V4L2_CID_MPEG_BASE+5)
#define V4L2_CID_MPEG_STREAM_PES_ID_VIDEO 	(V4L2_CID_MPEG_BASE+6)
#define V4L2_CID_MPEG_STREAM_VBI_FMT 		(V4L2_CID_MPEG_BASE+7)
enum v4l2_mpeg_stream_vbi_fmt {
	V4L2_MPEG_STREAM_VBI_FMT_NONE = 0,  /* No VBI in the MPEG stream */
	V4L2_MPEG_STREAM_VBI_FMT_IVTV = 1,  /* VBI in private packets, IVTV format */
};

There are also classes for controlling MPEG video, MPEG audio decoders and
encoders, and currently it currently supports mpeg1, mpeg2, mpeg4, H.263 and H.264
(all of them with at least one driver implementing it, and properly supported
by the v4l2 core).

Regards,
Mauro

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 26-11-2011 19:58, Manu Abraham escreveu:
> On Sat, Nov 26, 2011 at 5:19 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> On Saturday, November 26, 2011 06:55:52 Oliver Endriss wrote:
>>> On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote:
>>>> On 25.11.2011 17:51, Manu Abraham wrote:
>>>>> On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
>>>>> <mchehab@redhat.com> wrote:
>>>>>> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
>>>>>>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
>>>>>>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
>>>>>>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>>>>>>>>>> If your complain is about the removal of audio.h, video.h
>>>>>>>>>
>>>>>>>>> We're back on topic, thank you!
>>>>>>>>>
>>>>>>>>>> and osd.h, then my proposal is
>>>>>>>>>> to keep it there, writing a text that they are part of a deprecated API,
>>>>>>>>>
>>>>>>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
>>>>>>>>> because it's not. Just explain - inside this text - when V4L2 should be
>>>>>>>>> preferred over DVB.
>>>>>>>>
>>>>>>>> It is deprecated, as the API is not growing to fulfill today's needs, and
>>>>>>>> no patches adding new stuff to it to it will be accepted anymore.
>>>>>>>
>>>>>>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
>>>>>>
>>>>>> No. It didn't grow because nobody cared with it for years:
>>>>>>
>>>>>> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
>>>>>>
>>>>>> Excluding Hans changes for using it on a pure V4L device, and other trivial
>>>>>> patches not related to API changes, the last API change on audio.h and video.h
>>>>>> was this patch:
>>>>>>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
>>>>>>        Author: Andreas Oberritter <obi@linuxtv.org>
>>>>>>        Date:   Mon Feb 27 00:09:00 2006 -0300
>>>>>>
>>>>>>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
>>>>>>
>>>>>>        (yet not used on any upstream driver)
>>>>>>
>>>>>> An then:
>>>>>>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>>>>>>        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
>>>>>>        Date:   Sat Apr 16 15:20:36 2005 -0700
>>>>>>
>>>>>>            Linux-2.6.12-rc2
>>>>>>
>>>>>> No changes adding support for any in-kernel driver were ever added there.
>>>>>>
>>>>>> So, it didn't grow over the last 5 or 6 years because nobody submitted
>>>>>> driver patches requiring new things or _even_ using it.
>>>>>>
>>>>>>>
>>>>>>>>>> but keeping
>>>>>>>>>> the rest of the patches
>>>>>>>>>
>>>>>>>>> Which ones?
>>>>>>>>
>>>>>>>> V4L2, ivtv and DocBook patches.
>>>>>>>
>>>>>>> Fine.
>>>>>>>
>>>>>>>>>> and not accepting anymore any submission using them
>>>>>>>>>
>>>>>>>>> Why? First you complain about missing users and then don't want to allow
>>>>>>>>> any new ones.
>>>>>>>>
>>>>>>>> I didn't complain about missing users. What I've said is that, between a
>>>>>>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
>>>>>>>> the one-user API and mark it as deprecated.
>>>>>>>
>>>>>>> Your assumtion about only one user still isn't true.
>>>>>>>
>>>>>>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
>>>>>>>> It is easier to add what's missing there for DVB than to work the other
>>>>>>>> way around, and deprecate V4L2/ALSA/MC/subdev.
>>>>>>>
>>>>>>> Yes. Please! Add it! But leave the DVB API alone!
>>>>>>>
>>>>>>>>>> , removing
>>>>>>>>>> the ioctl's that aren't used by av7110 from them.
>>>>>>>>>
>>>>>>>>> That's just stupid. I can easily provide a list of used and valuable
>>>>>>>>> ioctls, which need to remain present in order to not break userspace
>>>>>>>>> applications.
>>>>>>>>
>>>>>>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
>>>>>>>> So, why to keep/maintain them?
>>>>>>>
>>>>>>> If you already deprecated it, why bother deleting random stuff from it
>>>>>>> that people are using?
>>>>>>>
>>>>>>> There's a difference in keeping and maintaining something. You don't
>>>>>>> need to maintain ioctls that haven't changed in years. Deleting
>>>>>>> something is more work than letting it there to be used by those who
>>>>>>> want to.
>>>>>>
>>>>>> Ok. Let's just keep the headers as is, just adding a comment that it is now
>>>>>> considered superseded.
>>>>
>>>> Thank you! This is a step into the right direction.
>>>>
>>>>> http://dictionary.reference.com/browse/superseded
>>>>>
>>>>> to set aside or cause to be set aside as void, useless, or obsolete, usually
>>>>> in favor of something mentioned; make obsolete: They superseded the
>>>>> old statute with a new one.
>>>>>
>>>>> No, that's not acceptable. New DVB devices as they come will make use
>>>>> of the API and API changes might be applied.
>>>>
>>>> Honestly, I think we all should accept this proposal and just hope that
>>>> the comment is going to be written objectively.
>>>
>>> 'Hoping' is not enough for me anymore. I am deeply disappointed.
>>> Mauro and Hans have severely damaged my trust, that v4ldvb APIs are
>>> stable in Linux, and how things are handled in this project.
>>>
>>> So I request a public statement from the subsystem maintainer that
>>> 1. The DVB Decoder API will not be removed.
>>> 2. It can be updated if required (e.g. adding a missing function).
>>> 3. New drivers are allowed to use this architecture.
>>> 4. These driver will be accepted, if they follow the kernel standards.
>>>
>>> The reason is simple: I need to know, whether this project is still
>>> worth investing some time, or it is better to do something else.
>>
>> 1) There are two APIs that do the same thing: the DVB decoder API and the
>>   V4L2 API.
>> 2) That's bad because it confuses driver developers and application developers
>>   who have to support *two* APIs to do the same thing.
>> 3) The DVB decoder API is used in only one DVB driver (av7110), and in one
>>   V4L2 driver (ivtv). The latter is easily converted to V4L2 which leaves only
>>   one driver, av7110.
>> 4) A decoder API has nothing to do with DVB as a standard, it simply takes
>>   the output of the DVB part of the hardware and decodes it to the output.
>>   That's basic V4L2 functionality.
> 
> 
> It does, with newer scrambling systems, the decoder is tightly tied to the
> CA system(s) associated.
> 
> According to the CI+ specification:
> 
> "It is mandatory for the Application MMI to provide limited control
> over the MPEG
> decoders which enable the broadcast video and audio of the current service to
> be presented, additionally a full frame I-frame may be used to provide rich
> graphics backgrounds. The MMI Application may deny the application MMI
> control of the MPEG decoder if a resource conflict results."
> 
> What you are talking about is FTA decoders which don't have any scrambling
> control, but almost all newer DVB decoders supporting CI+ work that way.
> If you look at any new digital TV/service, it comes with CI+ and many providers
> switching over.
> 
> Because of a wrong decision, users cannot be denied using the same.

What is saying there doesn't tell how the implementation should happen, but only
what features should be there. The control over the MPEG decoders is directly
available either using the audio/video DVB API or the V4L API.

Also, as defined into item 3.3 - Abbreviations [1], MMI is the Man Machine Interface.
This is how ITU-T and ITU-R calls the GUI interface. Other standardization bureaus
share the same definition.

[1] http://www.ci-plus.com/data/ci_plus_specification_v1.2.pdf

As stated on item 12.1:

	The CI Plus Application MMI shall take precedence over any existing 
	application environment and may optionally be presented on the host
	native graphics plane, application plane or another display plane 
	that may exist between the host display and application, this is shown
	as a number of conceptual planes in Figure 12.3

Figure 12.3 is interesting, as it shows that the Application MMI is one of the
planes that the user will view on his screen.

A proper implementation of something like figure 12.3 is one of the things that
it is easily done via V4L2 and its integration with framebuffer and the
upcoming integration with the GPU using the shared framebuffers patches that
are under discussions between mm, media and gpu subsystems.

I can't see any way of implementing the composing of the video planes shown at 
figure 12.3 (background, video planes, optional application planes, CI Plus
Application MMI plane, Native Graphics planes) with just the DVB API.

As said there:

	The Application MMI shall support full video transparency enabling text 
	and graphics to be overlaid over the video (and possibly any native
	 application). The Application MMI has a native SD resolution of 
	720x576 pixels and shall be scaled to full screen to match the current
	video aspect ratio in both SD and HD environments.

The pipeline setup via the MC allows setting such planes, and the GPU/V4L2
shared buffer allows passing the CI+ Application MMI to the GPU. V4L2 subdev
API can be used to control the scaler required to convert from 720x576 pixels
to the displayed resolution, and to adjust the DV timings of the output.

Regards,
Mauro

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Manu Abraham]

[-- Attachment #1: Type: text/plain, Size: 10258 bytes --]

On Mon, Nov 28, 2011 at 12:33 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 26-11-2011 19:58, Manu Abraham escreveu:
>> On Sat, Nov 26, 2011 at 5:19 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>> On Saturday, November 26, 2011 06:55:52 Oliver Endriss wrote:
>>>> On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote:
>>>>> On 25.11.2011 17:51, Manu Abraham wrote:
>>>>>> On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
>>>>>> <mchehab@redhat.com> wrote:
>>>>>>> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
>>>>>>>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
>>>>>>>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
>>>>>>>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>>>>>>>>>>> If your complain is about the removal of audio.h, video.h
>>>>>>>>>>
>>>>>>>>>> We're back on topic, thank you!
>>>>>>>>>>
>>>>>>>>>>> and osd.h, then my proposal is
>>>>>>>>>>> to keep it there, writing a text that they are part of a deprecated API,
>>>>>>>>>>
>>>>>>>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
>>>>>>>>>> because it's not. Just explain - inside this text - when V4L2 should be
>>>>>>>>>> preferred over DVB.
>>>>>>>>>
>>>>>>>>> It is deprecated, as the API is not growing to fulfill today's needs, and
>>>>>>>>> no patches adding new stuff to it to it will be accepted anymore.
>>>>>>>>
>>>>>>>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
>>>>>>>
>>>>>>> No. It didn't grow because nobody cared with it for years:
>>>>>>>
>>>>>>> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
>>>>>>>
>>>>>>> Excluding Hans changes for using it on a pure V4L device, and other trivial
>>>>>>> patches not related to API changes, the last API change on audio.h and video.h
>>>>>>> was this patch:
>>>>>>>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
>>>>>>>        Author: Andreas Oberritter <obi@linuxtv.org>
>>>>>>>        Date:   Mon Feb 27 00:09:00 2006 -0300
>>>>>>>
>>>>>>>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
>>>>>>>
>>>>>>>        (yet not used on any upstream driver)
>>>>>>>
>>>>>>> An then:
>>>>>>>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>>>>>>>        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
>>>>>>>        Date:   Sat Apr 16 15:20:36 2005 -0700
>>>>>>>
>>>>>>>            Linux-2.6.12-rc2
>>>>>>>
>>>>>>> No changes adding support for any in-kernel driver were ever added there.
>>>>>>>
>>>>>>> So, it didn't grow over the last 5 or 6 years because nobody submitted
>>>>>>> driver patches requiring new things or _even_ using it.
>>>>>>>
>>>>>>>>
>>>>>>>>>>> but keeping
>>>>>>>>>>> the rest of the patches
>>>>>>>>>>
>>>>>>>>>> Which ones?
>>>>>>>>>
>>>>>>>>> V4L2, ivtv and DocBook patches.
>>>>>>>>
>>>>>>>> Fine.
>>>>>>>>
>>>>>>>>>>> and not accepting anymore any submission using them
>>>>>>>>>>
>>>>>>>>>> Why? First you complain about missing users and then don't want to allow
>>>>>>>>>> any new ones.
>>>>>>>>>
>>>>>>>>> I didn't complain about missing users. What I've said is that, between a
>>>>>>>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
>>>>>>>>> the one-user API and mark it as deprecated.
>>>>>>>>
>>>>>>>> Your assumtion about only one user still isn't true.
>>>>>>>>
>>>>>>>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
>>>>>>>>> It is easier to add what's missing there for DVB than to work the other
>>>>>>>>> way around, and deprecate V4L2/ALSA/MC/subdev.
>>>>>>>>
>>>>>>>> Yes. Please! Add it! But leave the DVB API alone!
>>>>>>>>
>>>>>>>>>>> , removing
>>>>>>>>>>> the ioctl's that aren't used by av7110 from them.
>>>>>>>>>>
>>>>>>>>>> That's just stupid. I can easily provide a list of used and valuable
>>>>>>>>>> ioctls, which need to remain present in order to not break userspace
>>>>>>>>>> applications.
>>>>>>>>>
>>>>>>>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
>>>>>>>>> So, why to keep/maintain them?
>>>>>>>>
>>>>>>>> If you already deprecated it, why bother deleting random stuff from it
>>>>>>>> that people are using?
>>>>>>>>
>>>>>>>> There's a difference in keeping and maintaining something. You don't
>>>>>>>> need to maintain ioctls that haven't changed in years. Deleting
>>>>>>>> something is more work than letting it there to be used by those who
>>>>>>>> want to.
>>>>>>>
>>>>>>> Ok. Let's just keep the headers as is, just adding a comment that it is now
>>>>>>> considered superseded.
>>>>>
>>>>> Thank you! This is a step into the right direction.
>>>>>
>>>>>> http://dictionary.reference.com/browse/superseded
>>>>>>
>>>>>> to set aside or cause to be set aside as void, useless, or obsolete, usually
>>>>>> in favor of something mentioned; make obsolete: They superseded the
>>>>>> old statute with a new one.
>>>>>>
>>>>>> No, that's not acceptable. New DVB devices as they come will make use
>>>>>> of the API and API changes might be applied.
>>>>>
>>>>> Honestly, I think we all should accept this proposal and just hope that
>>>>> the comment is going to be written objectively.
>>>>
>>>> 'Hoping' is not enough for me anymore. I am deeply disappointed.
>>>> Mauro and Hans have severely damaged my trust, that v4ldvb APIs are
>>>> stable in Linux, and how things are handled in this project.
>>>>
>>>> So I request a public statement from the subsystem maintainer that
>>>> 1. The DVB Decoder API will not be removed.
>>>> 2. It can be updated if required (e.g. adding a missing function).
>>>> 3. New drivers are allowed to use this architecture.
>>>> 4. These driver will be accepted, if they follow the kernel standards.
>>>>
>>>> The reason is simple: I need to know, whether this project is still
>>>> worth investing some time, or it is better to do something else.
>>>
>>> 1) There are two APIs that do the same thing: the DVB decoder API and the
>>>   V4L2 API.
>>> 2) That's bad because it confuses driver developers and application developers
>>>   who have to support *two* APIs to do the same thing.
>>> 3) The DVB decoder API is used in only one DVB driver (av7110), and in one
>>>   V4L2 driver (ivtv). The latter is easily converted to V4L2 which leaves only
>>>   one driver, av7110.
>>> 4) A decoder API has nothing to do with DVB as a standard, it simply takes
>>>   the output of the DVB part of the hardware and decodes it to the output.
>>>   That's basic V4L2 functionality.
>>
>>
>> It does, with newer scrambling systems, the decoder is tightly tied to the
>> CA system(s) associated.
>>
>> According to the CI+ specification:
>>
>> "It is mandatory for the Application MMI to provide limited control
>> over the MPEG
>> decoders which enable the broadcast video and audio of the current service to
>> be presented, additionally a full frame I-frame may be used to provide rich
>> graphics backgrounds. The MMI Application may deny the application MMI
>> control of the MPEG decoder if a resource conflict results."
>>
>> What you are talking about is FTA decoders which don't have any scrambling
>> control, but almost all newer DVB decoders supporting CI+ work that way.
>> If you look at any new digital TV/service, it comes with CI+ and many providers
>> switching over.
>>
>> Because of a wrong decision, users cannot be denied using the same.
>
> What is saying there doesn't tell how the implementation should happen, but only
> what features should be there. The control over the MPEG decoders is directly
> available either using the audio/video DVB API or the V4L API.
>
> Also, as defined into item 3.3 - Abbreviations [1], MMI is the Man Machine Interface.
> This is how ITU-T and ITU-R calls the GUI interface. Other standardization bureaus
> share the same definition.
>
> [1] http://www.ci-plus.com/data/ci_plus_specification_v1.2.pdf
>
> As stated on item 12.1:
>
>        The CI Plus Application MMI shall take precedence over any existing
>        application environment and may optionally be presented on the host
>        native graphics plane, application plane or another display plane
>        that may exist between the host display and application, this is shown
>        as a number of conceptual planes in Figure 12.3
>
> Figure 12.3 is interesting, as it shows that the Application MMI is one of the
> planes that the user will view on his screen.
>
> A proper implementation of something like figure 12.3 is one of the things that
> it is easily done via V4L2 and its integration with framebuffer and the
> upcoming integration with the GPU using the shared framebuffers patches that
> are under discussions between mm, media and gpu subsystems.
>
> I can't see any way of implementing the composing of the video planes shown at
> figure 12.3 (background, video planes, optional application planes, CI Plus
> Application MMI plane, Native Graphics planes) with just the DVB API.
>
> As said there:
>
>        The Application MMI shall support full video transparency enabling text
>        and graphics to be overlaid over the video (and possibly any native
>         application). The Application MMI has a native SD resolution of
>        720x576 pixels and shall be scaled to full screen to match the current
>        video aspect ratio in both SD and HD environments.
>
> The pipeline setup via the MC allows setting such planes, and the GPU/V4L2
> shared buffer allows passing the CI+ Application MMI to the GPU. V4L2 subdev
> API can be used to control the scaler required to convert from 720x576 pixels
> to the displayed resolution, and to adjust the DV timings of the output.


You don't have any planes that you can control in software. There is *no*
GPU involved, the output of the decoder goes through HDMI/HDCP to the
display. The whole concept is to avoid the user to touch/copy the video
stream/components. The host is decoder on which the MMI application
runs in secure mode. You can't take any control over those with V4L2 or
anything as you state.
You can understand the same from the attached .jpeg file

[-- Attachment #2: cip_snapshot.jpeg --]
[-- Type: image/jpeg, Size: 26108 bytes --]

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 27-11-2011 17:27, Manu Abraham escreveu:
> On Mon, Nov 28, 2011 at 12:33 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Em 26-11-2011 19:58, Manu Abraham escreveu:
>>> On Sat, Nov 26, 2011 at 5:19 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>> On Saturday, November 26, 2011 06:55:52 Oliver Endriss wrote:
>>>>> On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote:
>>>>>> On 25.11.2011 17:51, Manu Abraham wrote:
>>>>>>> On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
>>>>>>> <mchehab@redhat.com> wrote:
>>>>>>>> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
>>>>>>>>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
>>>>>>>>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
>>>>>>>>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>>>>>>>>>>>> If your complain is about the removal of audio.h, video.h
>>>>>>>>>>>
>>>>>>>>>>> We're back on topic, thank you!
>>>>>>>>>>>
>>>>>>>>>>>> and osd.h, then my proposal is
>>>>>>>>>>>> to keep it there, writing a text that they are part of a deprecated API,
>>>>>>>>>>>
>>>>>>>>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
>>>>>>>>>>> because it's not. Just explain - inside this text - when V4L2 should be
>>>>>>>>>>> preferred over DVB.
>>>>>>>>>>
>>>>>>>>>> It is deprecated, as the API is not growing to fulfill today's needs, and
>>>>>>>>>> no patches adding new stuff to it to it will be accepted anymore.
>>>>>>>>>
>>>>>>>>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
>>>>>>>>
>>>>>>>> No. It didn't grow because nobody cared with it for years:
>>>>>>>>
>>>>>>>> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
>>>>>>>>
>>>>>>>> Excluding Hans changes for using it on a pure V4L device, and other trivial
>>>>>>>> patches not related to API changes, the last API change on audio.h and video.h
>>>>>>>> was this patch:
>>>>>>>>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
>>>>>>>>        Author: Andreas Oberritter <obi@linuxtv.org>
>>>>>>>>        Date:   Mon Feb 27 00:09:00 2006 -0300
>>>>>>>>
>>>>>>>>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
>>>>>>>>
>>>>>>>>        (yet not used on any upstream driver)
>>>>>>>>
>>>>>>>> An then:
>>>>>>>>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>>>>>>>>        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
>>>>>>>>        Date:   Sat Apr 16 15:20:36 2005 -0700
>>>>>>>>
>>>>>>>>            Linux-2.6.12-rc2
>>>>>>>>
>>>>>>>> No changes adding support for any in-kernel driver were ever added there.
>>>>>>>>
>>>>>>>> So, it didn't grow over the last 5 or 6 years because nobody submitted
>>>>>>>> driver patches requiring new things or _even_ using it.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> but keeping
>>>>>>>>>>>> the rest of the patches
>>>>>>>>>>>
>>>>>>>>>>> Which ones?
>>>>>>>>>>
>>>>>>>>>> V4L2, ivtv and DocBook patches.
>>>>>>>>>
>>>>>>>>> Fine.
>>>>>>>>>
>>>>>>>>>>>> and not accepting anymore any submission using them
>>>>>>>>>>>
>>>>>>>>>>> Why? First you complain about missing users and then don't want to allow
>>>>>>>>>>> any new ones.
>>>>>>>>>>
>>>>>>>>>> I didn't complain about missing users. What I've said is that, between a
>>>>>>>>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
>>>>>>>>>> the one-user API and mark it as deprecated.
>>>>>>>>>
>>>>>>>>> Your assumtion about only one user still isn't true.
>>>>>>>>>
>>>>>>>>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
>>>>>>>>>> It is easier to add what's missing there for DVB than to work the other
>>>>>>>>>> way around, and deprecate V4L2/ALSA/MC/subdev.
>>>>>>>>>
>>>>>>>>> Yes. Please! Add it! But leave the DVB API alone!
>>>>>>>>>
>>>>>>>>>>>> , removing
>>>>>>>>>>>> the ioctl's that aren't used by av7110 from them.
>>>>>>>>>>>
>>>>>>>>>>> That's just stupid. I can easily provide a list of used and valuable
>>>>>>>>>>> ioctls, which need to remain present in order to not break userspace
>>>>>>>>>>> applications.
>>>>>>>>>>
>>>>>>>>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
>>>>>>>>>> So, why to keep/maintain them?
>>>>>>>>>
>>>>>>>>> If you already deprecated it, why bother deleting random stuff from it
>>>>>>>>> that people are using?
>>>>>>>>>
>>>>>>>>> There's a difference in keeping and maintaining something. You don't
>>>>>>>>> need to maintain ioctls that haven't changed in years. Deleting
>>>>>>>>> something is more work than letting it there to be used by those who
>>>>>>>>> want to.
>>>>>>>>
>>>>>>>> Ok. Let's just keep the headers as is, just adding a comment that it is now
>>>>>>>> considered superseded.
>>>>>>
>>>>>> Thank you! This is a step into the right direction.
>>>>>>
>>>>>>> http://dictionary.reference.com/browse/superseded
>>>>>>>
>>>>>>> to set aside or cause to be set aside as void, useless, or obsolete, usually
>>>>>>> in favor of something mentioned; make obsolete: They superseded the
>>>>>>> old statute with a new one.
>>>>>>>
>>>>>>> No, that's not acceptable. New DVB devices as they come will make use
>>>>>>> of the API and API changes might be applied.
>>>>>>
>>>>>> Honestly, I think we all should accept this proposal and just hope that
>>>>>> the comment is going to be written objectively.
>>>>>
>>>>> 'Hoping' is not enough for me anymore. I am deeply disappointed.
>>>>> Mauro and Hans have severely damaged my trust, that v4ldvb APIs are
>>>>> stable in Linux, and how things are handled in this project.
>>>>>
>>>>> So I request a public statement from the subsystem maintainer that
>>>>> 1. The DVB Decoder API will not be removed.
>>>>> 2. It can be updated if required (e.g. adding a missing function).
>>>>> 3. New drivers are allowed to use this architecture.
>>>>> 4. These driver will be accepted, if they follow the kernel standards.
>>>>>
>>>>> The reason is simple: I need to know, whether this project is still
>>>>> worth investing some time, or it is better to do something else.
>>>>
>>>> 1) There are two APIs that do the same thing: the DVB decoder API and the
>>>>   V4L2 API.
>>>> 2) That's bad because it confuses driver developers and application developers
>>>>   who have to support *two* APIs to do the same thing.
>>>> 3) The DVB decoder API is used in only one DVB driver (av7110), and in one
>>>>   V4L2 driver (ivtv). The latter is easily converted to V4L2 which leaves only
>>>>   one driver, av7110.
>>>> 4) A decoder API has nothing to do with DVB as a standard, it simply takes
>>>>   the output of the DVB part of the hardware and decodes it to the output.
>>>>   That's basic V4L2 functionality.
>>>
>>>
>>> It does, with newer scrambling systems, the decoder is tightly tied to the
>>> CA system(s) associated.
>>>
>>> According to the CI+ specification:
>>>
>>> "It is mandatory for the Application MMI to provide limited control
>>> over the MPEG
>>> decoders which enable the broadcast video and audio of the current service to
>>> be presented, additionally a full frame I-frame may be used to provide rich
>>> graphics backgrounds. The MMI Application may deny the application MMI
>>> control of the MPEG decoder if a resource conflict results."
>>>
>>> What you are talking about is FTA decoders which don't have any scrambling
>>> control, but almost all newer DVB decoders supporting CI+ work that way.
>>> If you look at any new digital TV/service, it comes with CI+ and many providers
>>> switching over.
>>>
>>> Because of a wrong decision, users cannot be denied using the same.
>>
>> What is saying there doesn't tell how the implementation should happen, but only
>> what features should be there. The control over the MPEG decoders is directly
>> available either using the audio/video DVB API or the V4L API.
>>
>> Also, as defined into item 3.3 - Abbreviations [1], MMI is the Man Machine Interface.
>> This is how ITU-T and ITU-R calls the GUI interface. Other standardization bureaus
>> share the same definition.
>>
>> [1] http://www.ci-plus.com/data/ci_plus_specification_v1.2.pdf
>>
>> As stated on item 12.1:
>>
>>        The CI Plus Application MMI shall take precedence over any existing
>>        application environment and may optionally be presented on the host
>>        native graphics plane, application plane or another display plane
>>        that may exist between the host display and application, this is shown
>>        as a number of conceptual planes in Figure 12.3
>>
>> Figure 12.3 is interesting, as it shows that the Application MMI is one of the
>> planes that the user will view on his screen.
>>
>> A proper implementation of something like figure 12.3 is one of the things that
>> it is easily done via V4L2 and its integration with framebuffer and the
>> upcoming integration with the GPU using the shared framebuffers patches that
>> are under discussions between mm, media and gpu subsystems.
>>
>> I can't see any way of implementing the composing of the video planes shown at
>> figure 12.3 (background, video planes, optional application planes, CI Plus
>> Application MMI plane, Native Graphics planes) with just the DVB API.
>>
>> As said there:
>>
>>        The Application MMI shall support full video transparency enabling text
>>        and graphics to be overlaid over the video (and possibly any native
>>         application). The Application MMI has a native SD resolution of
>>        720x576 pixels and shall be scaled to full screen to match the current
>>        video aspect ratio in both SD and HD environments.
>>
>> The pipeline setup via the MC allows setting such planes, and the GPU/V4L2
>> shared buffer allows passing the CI+ Application MMI to the GPU. V4L2 subdev
>> API can be used to control the scaler required to convert from 720x576 pixels
>> to the displayed resolution, and to adjust the DV timings of the output.
> 
> 
> You don't have any planes that you can control in software. There is *no*
> GPU involved, the output of the decoder goes through HDMI/HDCP to the
> display.

The GPU how it is called the piece of the hardware that outputs displays data.
Ok, if the device is too simple, it may use just one framebuffer for output, but,
in general, SoC chips contain several image processing blocks there, in order
to do scaling, composition, etc.

> The whole concept is to avoid the user to touch/copy the video
> stream/components. The host is decoder on which the MMI application
> runs in secure mode. You can't take any control over those with V4L2 or
> anything as you state.

Media drivers support three ways for output:

1) V4L2 output;
2) framebuffer output;
3) shared buffer between a decoder driver and the GPU.

Patches for (3) are currently under development, and several patches were already
proposed, and should reach upstream soon.

On all 3 cases, the data doesn't go to userspace. The controls are there to allow
specifying the size of the image, and its position/resolution at the screen. There
are controls for adjusting HDMI timings (e. g. resolution, frames per second, etc),
in the case of (1).

Please, don't mix V4L2 output with V4L2 input. V4L2 input is used when a decoded
video should be sent to userspace. Most V4L2 drivers are input devices (webcams,
analog TV cards, grabber cards). The ivtv card is one example of PC device that
implements both V4L2 input and output. Most SoC V4L drivers support both input
and output, and the actual setup is made by setting the pipelines, among the ones
that are supported by the hardware.

In the case of a DVB device watching to an encrypted channel using the CI+ module,
only the V4L2 output would be used.

Regards,
Mauro

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Manu Abraham]

On Mon, Nov 28, 2011 at 3:09 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 27-11-2011 17:27, Manu Abraham escreveu:
>> On Mon, Nov 28, 2011 at 12:33 AM, Mauro Carvalho Chehab
>> <mchehab@redhat.com> wrote:
>>> Em 26-11-2011 19:58, Manu Abraham escreveu:
>>>> On Sat, Nov 26, 2011 at 5:19 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>>> On Saturday, November 26, 2011 06:55:52 Oliver Endriss wrote:
>>>>>> On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote:
>>>>>>> On 25.11.2011 17:51, Manu Abraham wrote:
>>>>>>>> On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
>>>>>>>> <mchehab@redhat.com> wrote:
>>>>>>>>> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
>>>>>>>>>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
>>>>>>>>>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
>>>>>>>>>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>>>>>>>>>>>>> If your complain is about the removal of audio.h, video.h
>>>>>>>>>>>>
>>>>>>>>>>>> We're back on topic, thank you!
>>>>>>>>>>>>
>>>>>>>>>>>>> and osd.h, then my proposal is
>>>>>>>>>>>>> to keep it there, writing a text that they are part of a deprecated API,
>>>>>>>>>>>>
>>>>>>>>>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
>>>>>>>>>>>> because it's not. Just explain - inside this text - when V4L2 should be
>>>>>>>>>>>> preferred over DVB.
>>>>>>>>>>>
>>>>>>>>>>> It is deprecated, as the API is not growing to fulfill today's needs, and
>>>>>>>>>>> no patches adding new stuff to it to it will be accepted anymore.
>>>>>>>>>>
>>>>>>>>>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
>>>>>>>>>
>>>>>>>>> No. It didn't grow because nobody cared with it for years:
>>>>>>>>>
>>>>>>>>> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
>>>>>>>>>
>>>>>>>>> Excluding Hans changes for using it on a pure V4L device, and other trivial
>>>>>>>>> patches not related to API changes, the last API change on audio.h and video.h
>>>>>>>>> was this patch:
>>>>>>>>>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
>>>>>>>>>        Author: Andreas Oberritter <obi@linuxtv.org>
>>>>>>>>>        Date:   Mon Feb 27 00:09:00 2006 -0300
>>>>>>>>>
>>>>>>>>>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
>>>>>>>>>
>>>>>>>>>        (yet not used on any upstream driver)
>>>>>>>>>
>>>>>>>>> An then:
>>>>>>>>>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>>>>>>>>>        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
>>>>>>>>>        Date:   Sat Apr 16 15:20:36 2005 -0700
>>>>>>>>>
>>>>>>>>>            Linux-2.6.12-rc2
>>>>>>>>>
>>>>>>>>> No changes adding support for any in-kernel driver were ever added there.
>>>>>>>>>
>>>>>>>>> So, it didn't grow over the last 5 or 6 years because nobody submitted
>>>>>>>>> driver patches requiring new things or _even_ using it.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> but keeping
>>>>>>>>>>>>> the rest of the patches
>>>>>>>>>>>>
>>>>>>>>>>>> Which ones?
>>>>>>>>>>>
>>>>>>>>>>> V4L2, ivtv and DocBook patches.
>>>>>>>>>>
>>>>>>>>>> Fine.
>>>>>>>>>>
>>>>>>>>>>>>> and not accepting anymore any submission using them
>>>>>>>>>>>>
>>>>>>>>>>>> Why? First you complain about missing users and then don't want to allow
>>>>>>>>>>>> any new ones.
>>>>>>>>>>>
>>>>>>>>>>> I didn't complain about missing users. What I've said is that, between a
>>>>>>>>>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
>>>>>>>>>>> the one-user API and mark it as deprecated.
>>>>>>>>>>
>>>>>>>>>> Your assumtion about only one user still isn't true.
>>>>>>>>>>
>>>>>>>>>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
>>>>>>>>>>> It is easier to add what's missing there for DVB than to work the other
>>>>>>>>>>> way around, and deprecate V4L2/ALSA/MC/subdev.
>>>>>>>>>>
>>>>>>>>>> Yes. Please! Add it! But leave the DVB API alone!
>>>>>>>>>>
>>>>>>>>>>>>> , removing
>>>>>>>>>>>>> the ioctl's that aren't used by av7110 from them.
>>>>>>>>>>>>
>>>>>>>>>>>> That's just stupid. I can easily provide a list of used and valuable
>>>>>>>>>>>> ioctls, which need to remain present in order to not break userspace
>>>>>>>>>>>> applications.
>>>>>>>>>>>
>>>>>>>>>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
>>>>>>>>>>> So, why to keep/maintain them?
>>>>>>>>>>
>>>>>>>>>> If you already deprecated it, why bother deleting random stuff from it
>>>>>>>>>> that people are using?
>>>>>>>>>>
>>>>>>>>>> There's a difference in keeping and maintaining something. You don't
>>>>>>>>>> need to maintain ioctls that haven't changed in years. Deleting
>>>>>>>>>> something is more work than letting it there to be used by those who
>>>>>>>>>> want to.
>>>>>>>>>
>>>>>>>>> Ok. Let's just keep the headers as is, just adding a comment that it is now
>>>>>>>>> considered superseded.
>>>>>>>
>>>>>>> Thank you! This is a step into the right direction.
>>>>>>>
>>>>>>>> http://dictionary.reference.com/browse/superseded
>>>>>>>>
>>>>>>>> to set aside or cause to be set aside as void, useless, or obsolete, usually
>>>>>>>> in favor of something mentioned; make obsolete: They superseded the
>>>>>>>> old statute with a new one.
>>>>>>>>
>>>>>>>> No, that's not acceptable. New DVB devices as they come will make use
>>>>>>>> of the API and API changes might be applied.
>>>>>>>
>>>>>>> Honestly, I think we all should accept this proposal and just hope that
>>>>>>> the comment is going to be written objectively.
>>>>>>
>>>>>> 'Hoping' is not enough for me anymore. I am deeply disappointed.
>>>>>> Mauro and Hans have severely damaged my trust, that v4ldvb APIs are
>>>>>> stable in Linux, and how things are handled in this project.
>>>>>>
>>>>>> So I request a public statement from the subsystem maintainer that
>>>>>> 1. The DVB Decoder API will not be removed.
>>>>>> 2. It can be updated if required (e.g. adding a missing function).
>>>>>> 3. New drivers are allowed to use this architecture.
>>>>>> 4. These driver will be accepted, if they follow the kernel standards.
>>>>>>
>>>>>> The reason is simple: I need to know, whether this project is still
>>>>>> worth investing some time, or it is better to do something else.
>>>>>
>>>>> 1) There are two APIs that do the same thing: the DVB decoder API and the
>>>>>   V4L2 API.
>>>>> 2) That's bad because it confuses driver developers and application developers
>>>>>   who have to support *two* APIs to do the same thing.
>>>>> 3) The DVB decoder API is used in only one DVB driver (av7110), and in one
>>>>>   V4L2 driver (ivtv). The latter is easily converted to V4L2 which leaves only
>>>>>   one driver, av7110.
>>>>> 4) A decoder API has nothing to do with DVB as a standard, it simply takes
>>>>>   the output of the DVB part of the hardware and decodes it to the output.
>>>>>   That's basic V4L2 functionality.
>>>>
>>>>
>>>> It does, with newer scrambling systems, the decoder is tightly tied to the
>>>> CA system(s) associated.
>>>>
>>>> According to the CI+ specification:
>>>>
>>>> "It is mandatory for the Application MMI to provide limited control
>>>> over the MPEG
>>>> decoders which enable the broadcast video and audio of the current service to
>>>> be presented, additionally a full frame I-frame may be used to provide rich
>>>> graphics backgrounds. The MMI Application may deny the application MMI
>>>> control of the MPEG decoder if a resource conflict results."
>>>>
>>>> What you are talking about is FTA decoders which don't have any scrambling
>>>> control, but almost all newer DVB decoders supporting CI+ work that way.
>>>> If you look at any new digital TV/service, it comes with CI+ and many providers
>>>> switching over.
>>>>
>>>> Because of a wrong decision, users cannot be denied using the same.
>>>
>>> What is saying there doesn't tell how the implementation should happen, but only
>>> what features should be there. The control over the MPEG decoders is directly
>>> available either using the audio/video DVB API or the V4L API.
>>>
>>> Also, as defined into item 3.3 - Abbreviations [1], MMI is the Man Machine Interface.
>>> This is how ITU-T and ITU-R calls the GUI interface. Other standardization bureaus
>>> share the same definition.
>>>
>>> [1] http://www.ci-plus.com/data/ci_plus_specification_v1.2.pdf
>>>
>>> As stated on item 12.1:
>>>
>>>        The CI Plus Application MMI shall take precedence over any existing
>>>        application environment and may optionally be presented on the host
>>>        native graphics plane, application plane or another display plane
>>>        that may exist between the host display and application, this is shown
>>>        as a number of conceptual planes in Figure 12.3
>>>
>>> Figure 12.3 is interesting, as it shows that the Application MMI is one of the
>>> planes that the user will view on his screen.
>>>
>>> A proper implementation of something like figure 12.3 is one of the things that
>>> it is easily done via V4L2 and its integration with framebuffer and the
>>> upcoming integration with the GPU using the shared framebuffers patches that
>>> are under discussions between mm, media and gpu subsystems.
>>>
>>> I can't see any way of implementing the composing of the video planes shown at
>>> figure 12.3 (background, video planes, optional application planes, CI Plus
>>> Application MMI plane, Native Graphics planes) with just the DVB API.
>>>
>>> As said there:
>>>
>>>        The Application MMI shall support full video transparency enabling text
>>>        and graphics to be overlaid over the video (and possibly any native
>>>         application). The Application MMI has a native SD resolution of
>>>        720x576 pixels and shall be scaled to full screen to match the current
>>>        video aspect ratio in both SD and HD environments.
>>>
>>> The pipeline setup via the MC allows setting such planes, and the GPU/V4L2
>>> shared buffer allows passing the CI+ Application MMI to the GPU. V4L2 subdev
>>> API can be used to control the scaler required to convert from 720x576 pixels
>>> to the displayed resolution, and to adjust the DV timings of the output.
>>
>>
>> You don't have any planes that you can control in software. There is *no*
>> GPU involved, the output of the decoder goes through HDMI/HDCP to the
>> display.
>
> The GPU how it is called the piece of the hardware that outputs displays data.
> Ok, if the device is too simple, it may use just one framebuffer for output, but,
> in general, SoC chips contain several image processing blocks there, in order
> to do scaling, composition, etc.


As with a framebuffer, you get decompressed data at the host CPU. In the
case mentioned, the decompressed data is not available to the user. So you
don't have any scaling, processing etc to be done in user software. The secured
host alone has control to it, nothing else. The output of which is
directly hardware
output via HDMI/HDCP.


>
>> The whole concept is to avoid the user to touch/copy the video
>> stream/components. The host is decoder on which the MMI application
>> runs in secure mode. You can't take any control over those with V4L2 or
>> anything as you state.
>
> Media drivers support three ways for output:
>
> 1) V4L2 output;
> 2) framebuffer output;
> 3) shared buffer between a decoder driver and the GPU.
>
> Patches for (3) are currently under development, and several patches were already
> proposed, and should reach upstream soon.


As I explained above, you cannot access the secure host which does rendering
of the stream. If you had access to it, then the whole concept of
secure system would
not even exist. That's what you mean by a certified system.

Don't even dream that any vendor will allow you to have access to the secured
host pipelines, so that you can play around with those pipelines with
V4L2 or whatever
you are trying to invent.

something as simple as this: If you have a shared buffer, then what is
the security
with it ?


>
> On all 3 cases, the data doesn't go to userspace. The controls are there to allow
> specifying the size of the image, and its position/resolution at the screen. There
> are controls for adjusting HDMI timings (e. g. resolution, frames per second, etc),
> in the case of (1).


With entitlement management, you cannot directly control the stream parameters
with user controls. If you have sufficient entitlements, the secured
host will allow
you to watch the stream in HD, if not in SD in some cases. Your V4L
controls aren't
valid with regards to Copy protected data to put short. The
entitlement management
happens over the air as with EMM's/ECM's as with DVB-CI


>
> Please, don't mix V4L2 output with V4L2 input. V4L2 input is used when a decoded
> video should be sent to userspace. Most V4L2 drivers are input devices (webcams,
> analog TV cards, grabber cards). The ivtv card is one example of PC device that
> implements both V4L2 input and output. Most SoC V4L drivers support both input
> and output, and the actual setup is made by setting the pipelines, among the ones
> that are supported by the hardware.
>
> In the case of a DVB device watching to an encrypted channel using the CI+ module,
> only the V4L2 output would be used.


These aren't simple SoC's as found on mobile phones etc. Is HDCP
working with V4L ?
Well, HDCP is only the last stage, there are other things such as CI+
in that pipeline,
so things aren't pretty simple as you think.

Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Mauro Carvalho Chehab]

Em 27-11-2011 20:24, Manu Abraham escreveu:
> On Mon, Nov 28, 2011 at 3:09 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Em 27-11-2011 17:27, Manu Abraham escreveu:
>>> On Mon, Nov 28, 2011 at 12:33 AM, Mauro Carvalho Chehab
>>> <mchehab@redhat.com> wrote:
>>>> Em 26-11-2011 19:58, Manu Abraham escreveu:
>>>>> On Sat, Nov 26, 2011 at 5:19 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>>>> On Saturday, November 26, 2011 06:55:52 Oliver Endriss wrote:
>>>>>>> On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote:
>>>>>>>> On 25.11.2011 17:51, Manu Abraham wrote:
>>>>>>>>> On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
>>>>>>>>> <mchehab@redhat.com> wrote:
>>>>>>>>>> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
>>>>>>>>>>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
>>>>>>>>>>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
>>>>>>>>>>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>>>>>>>>>>>>>> If your complain is about the removal of audio.h, video.h
>>>>>>>>>>>>>
>>>>>>>>>>>>> We're back on topic, thank you!
>>>>>>>>>>>>>
>>>>>>>>>>>>>> and osd.h, then my proposal is
>>>>>>>>>>>>>> to keep it there, writing a text that they are part of a deprecated API,
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
>>>>>>>>>>>>> because it's not. Just explain - inside this text - when V4L2 should be
>>>>>>>>>>>>> preferred over DVB.
>>>>>>>>>>>>
>>>>>>>>>>>> It is deprecated, as the API is not growing to fulfill today's needs, and
>>>>>>>>>>>> no patches adding new stuff to it to it will be accepted anymore.
>>>>>>>>>>>
>>>>>>>>>>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
>>>>>>>>>>
>>>>>>>>>> No. It didn't grow because nobody cared with it for years:
>>>>>>>>>>
>>>>>>>>>> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
>>>>>>>>>>
>>>>>>>>>> Excluding Hans changes for using it on a pure V4L device, and other trivial
>>>>>>>>>> patches not related to API changes, the last API change on audio.h and video.h
>>>>>>>>>> was this patch:
>>>>>>>>>>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
>>>>>>>>>>        Author: Andreas Oberritter <obi@linuxtv.org>
>>>>>>>>>>        Date:   Mon Feb 27 00:09:00 2006 -0300
>>>>>>>>>>
>>>>>>>>>>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
>>>>>>>>>>
>>>>>>>>>>        (yet not used on any upstream driver)
>>>>>>>>>>
>>>>>>>>>> An then:
>>>>>>>>>>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>>>>>>>>>>        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
>>>>>>>>>>        Date:   Sat Apr 16 15:20:36 2005 -0700
>>>>>>>>>>
>>>>>>>>>>            Linux-2.6.12-rc2
>>>>>>>>>>
>>>>>>>>>> No changes adding support for any in-kernel driver were ever added there.
>>>>>>>>>>
>>>>>>>>>> So, it didn't grow over the last 5 or 6 years because nobody submitted
>>>>>>>>>> driver patches requiring new things or _even_ using it.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> but keeping
>>>>>>>>>>>>>> the rest of the patches
>>>>>>>>>>>>>
>>>>>>>>>>>>> Which ones?
>>>>>>>>>>>>
>>>>>>>>>>>> V4L2, ivtv and DocBook patches.
>>>>>>>>>>>
>>>>>>>>>>> Fine.
>>>>>>>>>>>
>>>>>>>>>>>>>> and not accepting anymore any submission using them
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why? First you complain about missing users and then don't want to allow
>>>>>>>>>>>>> any new ones.
>>>>>>>>>>>>
>>>>>>>>>>>> I didn't complain about missing users. What I've said is that, between a
>>>>>>>>>>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
>>>>>>>>>>>> the one-user API and mark it as deprecated.
>>>>>>>>>>>
>>>>>>>>>>> Your assumtion about only one user still isn't true.
>>>>>>>>>>>
>>>>>>>>>>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
>>>>>>>>>>>> It is easier to add what's missing there for DVB than to work the other
>>>>>>>>>>>> way around, and deprecate V4L2/ALSA/MC/subdev.
>>>>>>>>>>>
>>>>>>>>>>> Yes. Please! Add it! But leave the DVB API alone!
>>>>>>>>>>>
>>>>>>>>>>>>>> , removing
>>>>>>>>>>>>>> the ioctl's that aren't used by av7110 from them.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's just stupid. I can easily provide a list of used and valuable
>>>>>>>>>>>>> ioctls, which need to remain present in order to not break userspace
>>>>>>>>>>>>> applications.
>>>>>>>>>>>>
>>>>>>>>>>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
>>>>>>>>>>>> So, why to keep/maintain them?
>>>>>>>>>>>
>>>>>>>>>>> If you already deprecated it, why bother deleting random stuff from it
>>>>>>>>>>> that people are using?
>>>>>>>>>>>
>>>>>>>>>>> There's a difference in keeping and maintaining something. You don't
>>>>>>>>>>> need to maintain ioctls that haven't changed in years. Deleting
>>>>>>>>>>> something is more work than letting it there to be used by those who
>>>>>>>>>>> want to.
>>>>>>>>>>
>>>>>>>>>> Ok. Let's just keep the headers as is, just adding a comment that it is now
>>>>>>>>>> considered superseded.
>>>>>>>>
>>>>>>>> Thank you! This is a step into the right direction.
>>>>>>>>
>>>>>>>>> http://dictionary.reference.com/browse/superseded
>>>>>>>>>
>>>>>>>>> to set aside or cause to be set aside as void, useless, or obsolete, usually
>>>>>>>>> in favor of something mentioned; make obsolete: They superseded the
>>>>>>>>> old statute with a new one.
>>>>>>>>>
>>>>>>>>> No, that's not acceptable. New DVB devices as they come will make use
>>>>>>>>> of the API and API changes might be applied.
>>>>>>>>
>>>>>>>> Honestly, I think we all should accept this proposal and just hope that
>>>>>>>> the comment is going to be written objectively.
>>>>>>>
>>>>>>> 'Hoping' is not enough for me anymore. I am deeply disappointed.
>>>>>>> Mauro and Hans have severely damaged my trust, that v4ldvb APIs are
>>>>>>> stable in Linux, and how things are handled in this project.
>>>>>>>
>>>>>>> So I request a public statement from the subsystem maintainer that
>>>>>>> 1. The DVB Decoder API will not be removed.
>>>>>>> 2. It can be updated if required (e.g. adding a missing function).
>>>>>>> 3. New drivers are allowed to use this architecture.
>>>>>>> 4. These driver will be accepted, if they follow the kernel standards.
>>>>>>>
>>>>>>> The reason is simple: I need to know, whether this project is still
>>>>>>> worth investing some time, or it is better to do something else.
>>>>>>
>>>>>> 1) There are two APIs that do the same thing: the DVB decoder API and the
>>>>>>   V4L2 API.
>>>>>> 2) That's bad because it confuses driver developers and application developers
>>>>>>   who have to support *two* APIs to do the same thing.
>>>>>> 3) The DVB decoder API is used in only one DVB driver (av7110), and in one
>>>>>>   V4L2 driver (ivtv). The latter is easily converted to V4L2 which leaves only
>>>>>>   one driver, av7110.
>>>>>> 4) A decoder API has nothing to do with DVB as a standard, it simply takes
>>>>>>   the output of the DVB part of the hardware and decodes it to the output.
>>>>>>   That's basic V4L2 functionality.
>>>>>
>>>>>
>>>>> It does, with newer scrambling systems, the decoder is tightly tied to the
>>>>> CA system(s) associated.
>>>>>
>>>>> According to the CI+ specification:
>>>>>
>>>>> "It is mandatory for the Application MMI to provide limited control
>>>>> over the MPEG
>>>>> decoders which enable the broadcast video and audio of the current service to
>>>>> be presented, additionally a full frame I-frame may be used to provide rich
>>>>> graphics backgrounds. The MMI Application may deny the application MMI
>>>>> control of the MPEG decoder if a resource conflict results."
>>>>>
>>>>> What you are talking about is FTA decoders which don't have any scrambling
>>>>> control, but almost all newer DVB decoders supporting CI+ work that way.
>>>>> If you look at any new digital TV/service, it comes with CI+ and many providers
>>>>> switching over.
>>>>>
>>>>> Because of a wrong decision, users cannot be denied using the same.
>>>>
>>>> What is saying there doesn't tell how the implementation should happen, but only
>>>> what features should be there. The control over the MPEG decoders is directly
>>>> available either using the audio/video DVB API or the V4L API.
>>>>
>>>> Also, as defined into item 3.3 - Abbreviations [1], MMI is the Man Machine Interface.
>>>> This is how ITU-T and ITU-R calls the GUI interface. Other standardization bureaus
>>>> share the same definition.
>>>>
>>>> [1] http://www.ci-plus.com/data/ci_plus_specification_v1.2.pdf
>>>>
>>>> As stated on item 12.1:
>>>>
>>>>        The CI Plus Application MMI shall take precedence over any existing
>>>>        application environment and may optionally be presented on the host
>>>>        native graphics plane, application plane or another display plane
>>>>        that may exist between the host display and application, this is shown
>>>>        as a number of conceptual planes in Figure 12.3
>>>>
>>>> Figure 12.3 is interesting, as it shows that the Application MMI is one of the
>>>> planes that the user will view on his screen.
>>>>
>>>> A proper implementation of something like figure 12.3 is one of the things that
>>>> it is easily done via V4L2 and its integration with framebuffer and the
>>>> upcoming integration with the GPU using the shared framebuffers patches that
>>>> are under discussions between mm, media and gpu subsystems.
>>>>
>>>> I can't see any way of implementing the composing of the video planes shown at
>>>> figure 12.3 (background, video planes, optional application planes, CI Plus
>>>> Application MMI plane, Native Graphics planes) with just the DVB API.
>>>>
>>>> As said there:
>>>>
>>>>        The Application MMI shall support full video transparency enabling text
>>>>        and graphics to be overlaid over the video (and possibly any native
>>>>         application). The Application MMI has a native SD resolution of
>>>>        720x576 pixels and shall be scaled to full screen to match the current
>>>>        video aspect ratio in both SD and HD environments.
>>>>
>>>> The pipeline setup via the MC allows setting such planes, and the GPU/V4L2
>>>> shared buffer allows passing the CI+ Application MMI to the GPU. V4L2 subdev
>>>> API can be used to control the scaler required to convert from 720x576 pixels
>>>> to the displayed resolution, and to adjust the DV timings of the output.
>>>
>>>
>>> You don't have any planes that you can control in software. There is *no*
>>> GPU involved, the output of the decoder goes through HDMI/HDCP to the
>>> display.
>>
>> The GPU how it is called the piece of the hardware that outputs displays data.
>> Ok, if the device is too simple, it may use just one framebuffer for output, but,
>> in general, SoC chips contain several image processing blocks there, in order
>> to do scaling, composition, etc.
> 
> 
> As with a framebuffer, you get decompressed data at the host CPU. In the
> case mentioned, the decompressed data is not available to the user. So you
> don't have any scaling, processing etc to be done in user software. The secured
> host alone has control to it, nothing else. The output of which is
> directly hardware
> output via HDMI/HDCP.

That's what I said: no data flows to userspace. All scaling, processing, etc
is made by the hardware, and it is controlled via V4L2/MC/subdev API's. The
API tells the hardware what should be the parameters for scaling, processing, etc.


>>> The whole concept is to avoid the user to touch/copy the video
>>> stream/components. The host is decoder on which the MMI application
>>> runs in secure mode. You can't take any control over those with V4L2 or
>>> anything as you state.
>>
>> Media drivers support three ways for output:
>>
>> 1) V4L2 output;
>> 2) framebuffer output;
>> 3) shared buffer between a decoder driver and the GPU.
>>
>> Patches for (3) are currently under development, and several patches were already
>> proposed, and should reach upstream soon.
> 
> 
> As I explained above, you cannot access the secure host which does rendering
> of the stream. If you had access to it, then the whole concept of
> secure system would
> not even exist. That's what you mean by a certified system.
> 
> Don't even dream that any vendor will allow you to have access to the secured
> host pipelines, so that you can play around with those pipelines with
> V4L2 or whatever
> you are trying to invent.

The pipelines that are exposed are the ones that the hardware offers and the driver
supports. The scenario you're mentioning could easily be implemented with the
MC API.

> 
> something as simple as this: If you have a shared buffer, then what is
> the security
> with it ?

Shared in the sense that two IP blocks at the chip is using the same buffer.

>> On all 3 cases, the data doesn't go to userspace. The controls are there to allow
>> specifying the size of the image, and its position/resolution at the screen. There
>> are controls for adjusting HDMI timings (e. g. resolution, frames per second, etc),
>> in the case of (1).
> 
> 
> With entitlement management, you cannot directly control the stream parameters
> with user controls. If you have sufficient entitlements, the secured
> host will allow
> you to watch the stream in HD, if not in SD in some cases. Your V4L
> controls aren't
> valid with regards to Copy protected data to put short. The
> entitlement management
> happens over the air as with EMM's/ECM's as with DVB-CI

If there's nothing to control, no API is needed.

>> Please, don't mix V4L2 output with V4L2 input. V4L2 input is used when a decoded
>> video should be sent to userspace. Most V4L2 drivers are input devices (webcams,
>> analog TV cards, grabber cards). The ivtv card is one example of PC device that
>> implements both V4L2 input and output. Most SoC V4L drivers support both input
>> and output, and the actual setup is made by setting the pipelines, among the ones
>> that are supported by the hardware.
>>
>> In the case of a DVB device watching to an encrypted channel using the CI+ module,
>> only the V4L2 output would be used.
> 
> 
> These aren't simple SoC's as found on mobile phones etc. Is HDCP
> working with V4L ?
> Well, HDCP is only the last stage, there are other things such as CI+
> in that pipeline,
> so things aren't pretty simple as you think.

Where do you control HDCP or even HDMI on audio.h/video.h/osd.h? 

Regards,
Mauro