public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: "Hans Werner" <HWerner4@gmx.de>
To: Steven Toth <stoth@linuxtv.org>,
	skerit@kipdola.com, linux-dvb@linuxtv.org
Subject: Re: [linux-dvb] [PATCH] Future of DVB-S2
Date: Fri, 29 Aug 2008 17:43:42 +0200	[thread overview]
Message-ID: <20080829154342.74800@gmx.net> (raw)
In-Reply-To: <48B802D8.7010806@linuxtv.org>

> ... and yes, many people understand you.

:) Thanks to everyone who replied so far. I am glad people care about this.

> > We know all about the "coding in your free time" and we can only have 
> > the highest respect for that, but the drivers are completely abandonded,
> > and that's how we feel, too.
> 
> No, and that's my HVR4000 code you're talking about (and the good work 
> of Darron Broad, which was then picked up by Igor). The driver is 
> marginalized, it's not abandoned.

I hope your and Darron's drivers (http://dev.kewl.org/hauppauge) are not seen as
marginalized. The multifrontend (MFE) patch by you and Darron is the driver that I
actually *use* for watching TV. It works nicely with Kaffeine without modification. And I,
for one, appreciate your sane approach and the simplicity of the techniques you used to
add DVB-S2 support (using sysctls for the SFE driver, and wrapping two ioctls to pull in
extra parameters for the MFE driver). If the kernel API is changed sensibly it should be
easy and quick to adapt your drivers to fit in.
 
> The HVR4000 situation is under review, the wheels are slowly turning.... 
If you are able to say anything about that I would be very interested.

Now, to show how simple I think all this could be, here is a PATCH implementing what
I think is the *minimal* API required to support DVB-S2.

Notes:

* same API structure, I just added some new enums and variables, nothing removed
* no changes required to any existing drivers (v4l-dvb still compiles)
* no changes required to existing applications (just need to be recompiled)
* no drivers, but I think the HVR4000 MFE patch could be easily adapted

I added the fe_caps2 enum because we're running out of bits in the capabilities bitfield.
More elegant would be to have separate bitfields for FEC capabilities and modulation
capabilities but that would require (easy) changes to (a lot of) drivers and applications.

Why should we not merge something simple like this immediately? This could have been done
years ago. If it takes several rounds of API upgrades to reach all the feature people want then
so be it, but a long journey begins with one step.

Regards.
Hans

diff -r a4843e1304e6 linux/include/linux/dvb/frontend.h
--- a/linux/include/linux/dvb/frontend.h	Sun Aug 24 12:28:11 2008 -0300
+++ b/linux/include/linux/dvb/frontend.h	Fri Aug 29 16:22:47 2008 +0100
@@ -36,6 +36,15 @@
 	FE_ATSC
 } fe_type_t;
 
+typedef enum fe_standard {
+	DVBS,
+	DVBS2,
+	DVBT,
+	DVBH,
+	DVBC,
+	DSS,
+	ATSC
+} fe_standard_t;
 
 typedef enum fe_caps {
 	FE_IS_STUPID			= 0,
@@ -67,6 +76,16 @@
 	FE_CAN_MUTE_TS			= 0x80000000  // frontend can stop spurious TS data output
 } fe_caps_t;
 
+typedef enum fe_caps2 {
+	FE_CAN_FEC_1_3			= 0x0,
+	FE_CAN_FEC_1_4			= 0x1,
+	FE_CAN_FEC_2_5			= 0x2,
+	FE_CAN_FEC_3_5			= 0x4,
+	FE_CAN_FEC_9_10			= 0x8,
+	FE_CAN_8PSK			= 0x10,
+	FE_CAN_16APSK			= 0x20,
+	FE_CAN_32APSK			= 0x40
+} fe_caps2_t;
 
 struct dvb_frontend_info {
 	char       name[128];
@@ -80,6 +99,7 @@
 	__u32      symbol_rate_tolerance;	/* ppm */
 	__u32      notifier_delay;		/* DEPRECATED */
 	fe_caps_t  caps;
+	fe_caps2_t caps2;
 };
 
 
@@ -140,19 +160,27 @@
 typedef enum fe_code_rate {
 	FEC_NONE = 0,
 	FEC_1_2,
+	FEC_1_3,
+	FEC_1_4,
 	FEC_2_3,
+	FEC_2_5,
 	FEC_3_4,
+	FEC_3_5,
 	FEC_4_5,
 	FEC_5_6,
 	FEC_6_7,
 	FEC_7_8,
 	FEC_8_9,
+	FEC_9_10,
 	FEC_AUTO
 } fe_code_rate_t;
 
 
 typedef enum fe_modulation {
 	QPSK,
+	PSK_8,
+	APSK_16,
+	APSK_32,
 	QAM_16,
 	QAM_32,
 	QAM_64,
@@ -194,10 +222,25 @@
 	HIERARCHY_AUTO
 } fe_hierarchy_t;
 
+typedef enum fe_rolloff {
+	ROLLOFF_035,
+	ROLLOFF_025,
+	ROLLOFF_020,
+	ROLLOFF_UNKNOWN
+} fe_rolloff_t;
+
+typedef enum fe_pilot {
+	PILOT_OFF,
+	PILOT_ON,
+	PILOT_AUTO
+} fe_pilot_t;
 
 struct dvb_qpsk_parameters {
 	__u32		symbol_rate;  /* symbol rate in Symbols per second */
 	fe_code_rate_t	fec_inner;    /* forward error correction (see above) */
+	fe_modulation_t	modulation;   /* DVB-S2 allows modulations QPSK plus 8PSK,16APSK,32APSK */
+	fe_rolloff_t 	rolloff;      /* for DVB-S2*/
+	fe_pilot_t	pilot;        /* for DVB-S2*/
 };
 
 struct dvb_qam_parameters {
@@ -225,6 +268,7 @@
 	__u32 frequency;     /* (absolute) frequency in Hz for QAM/OFDM/ATSC */
 			     /* intermediate frequency in kHz for QPSK */
 	fe_spectral_inversion_t inversion;
+	fe_standard_t           standard;   /* use to set DVBS/DVBS2/DVBT etc */
 	union {
 		struct dvb_qpsk_parameters qpsk;
 		struct dvb_qam_parameters  qam;


-- 
Release early, release often. Really, you should.

GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

  reply	other threads:[~2008-08-29 15:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080821173909.114260@gmx.net>
     [not found] ` <20080823200531.246370@gmx.net>
2008-08-28 21:22   ` [linux-dvb] Future of DVB-S2 Jelle De Loecker
2008-08-29  5:36   ` P. van Gaans
2008-08-29  7:32     ` Jelle De Loecker
2008-08-29 14:08       ` Steven Toth
2008-08-29 15:43         ` Hans Werner [this message]
2008-08-29 15:52           ` [linux-dvb] [PATCH] " Michael Krufky
2008-08-29 16:03             ` Steven Toth
2008-08-29 18:26               ` Hans Werner
2008-08-29 18:34                 ` Steven Toth
2008-08-29 16:43             ` Hans Werner
2008-08-29 16:50               ` Jelle De Loecker
2008-08-29 17:11                 ` Hans Werner
2008-08-29 17:52                 ` Steven Toth
2008-08-29 18:52               ` Oliver Endriss
2008-08-29 19:15                 ` Manu Abraham
2008-08-29 23:46                   ` Jelle De Loecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080829154342.74800@gmx.net \
    --to=hwerner4@gmx.de \
    --cc=linux-dvb@linuxtv.org \
    --cc=skerit@kipdola.com \
    --cc=stoth@linuxtv.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox