From patchwork Sat Jan 12 23:26:53 2008 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Reinhard Nissl X-Patchwork-Id: 12577 Received: from mail.gmx.net ([213.165.64.20]) by www.linuxtv.org with smtp (Exim 4.63) (envelope-from ) id 1JDpl7-00050H-Dx for vdr@linuxtv.org; Sun, 13 Jan 2008 00:27:25 +0100 Received: (qmail invoked by alias); 12 Jan 2008 23:26:54 -0000 Received: from p54930AAF.dip0.t-ipconnect.de (EHLO [192.168.101.15]) [84.147.10.175] by mail.gmx.net (mp045) with SMTP; 13 Jan 2008 00:26:54 +0100 X-Authenticated: #527675 X-Provags-ID: V01U2FsdGVkX184SL48NfI4iAUYqHQQiM62TCGDTXH3twFm4z8NkE GH9Y+HSBsgbd70 Message-ID: <47894CBD.4090800@gmx.de> Date: Sun, 13 Jan 2008 00:26:53 +0100 From: Reinhard Nissl User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.9) Gecko/20070801 SUSE/2.0.0.9-0.1 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: VDR Mailing List References: <200801121637.32921.stefan@lucke.in-berlin.de> <200801122247.54574.stefan@lucke.in-berlin.de> In-Reply-To: <200801122247.54574.stefan@lucke.in-berlin.de> X-Y-GMX-Trusted: 0 Subject: Re: [vdr] BUG: DVB-T and DVB-S[2] do not work with VDR & multiproto X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: VDR Mailing List List-Id: VDR Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2008 23:27:25 -0000 Status: O X-Status: X-Keywords: X-UID: 15064 Hi, Stefan Lucke schrieb: >>> Same here. >>> Which DVB-T device do you use ? I'm using a cinergyT2. >>> >>> Ioctl's for this device are not passed >>> via the common frontend interface. The new "API" has to get >>> integrated into the cinergyT2 driver or client programs like vdr etc. >>> have to recognize the driver supported API ;-) . >> >> I am using two Hauppauge Nova-T (tda1004x and cx2388x). >> >> Manu said in an earlier thread that there should be compatibility with >> the old API so he doesn't think that should be a problem. The driver >> in the multiproto tree for my devices have not been changed so should >> work through the compatibility layer. >> >> The odd thing is that when I use an older pre-compiled VDR 1.4.x with >> the new multiproto drivers everything works fine but when I compile >> 1.5.12 with multiproto includes it doesn't work. I spent the whole evening with Manu looking through the emulation layer and cannot see any obvious errors in the DVB-T case. It looks like there is still an error in the translation from the multiproto SET_PARAMS ioctl to the old SET_FRONTEND. Manu was so kind and created the attached patch, which prints the original values given to SET_PARAMS in the DVB-T case and the translated values which tda1004x' set_frontend() implementation receives. Morfsta: as you have such a card and reported that VDR-1.4.x tunes to DVB-T using the multiproto drivers (but old API) I ask you to test this patch. Make sure that VDR only uses the device with the tda1004x on it by adding a suitable -Dx argument to VDR's command line. To activate the logging messages, load the module dvb_core with parameter dvb_frontend_debug=1 and the module tda1004x with parameter debug=1. Then use VDR-1.4.x (limited to only one device) and tune to a certain DVB-T channel. Have a look what the driver reports (see dmesg or /var/log/messages or anything else which suits your system) at least for the set_frontend() function. Next use VDR-1.5.12-dvbs2-... (limited to only one device) and tune to the same DVB-T channel. Check what the driver reports this time. Additionally to the set_frontend() output there must a similar output before it which shows the parameters which VDR passed to the emulation layer. Please report the debug output here for further investigation. > So I guess in your case, there is still an issue with the compatibility > layer of http://jusst.de/hg/multiproto/ . > > In my case I managed to get my cinergyT2 work with Reinhard's > modified vdr, with attached diff. Hmm, looks like you provide your own emulation layer :-( Anyway, Manu agrees with me that it is not a good idea to have multiple implementations of an emulation layer with the expense of fixing the same bugs in every single driver. Only when a device requires to use the new API (e. g. to report DELSYS_DVBS2), the driver should be ported to the new API and typically it should drop support for the old API at the same time, too. So, please revert your change and apply the attached patch. Copy the debug output code from the tda1004x to your driver's file and take part in the test. Thanks in advance. Bye. diff -r 4df151d5b3fe linux/drivers/media/dvb/dvb-core/dvb_frontend.c --- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Sat Dec 01 01:50:24 2007 +0400 +++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Sun Jan 13 02:11:39 2008 +0400 @@ -371,6 +371,15 @@ int newapi_to_olddrv(struct dvbfe_params p->frequency = params->frequency; p->inversion = params->inversion; + dprintk("%s (Debug): __func__\n,\ + Frequency=0x%04x\n,\ + Inversion=0x%04x\n,\ + Delivery System=0x%04x\n",\ + __func__,\ + p->frequency,\ + p->inversion,\ + delsys); + switch (delsys) { case DVBFE_DELSYS_DVBS: qpsk->symbol_rate = dvbs->symbol_rate; @@ -382,6 +391,25 @@ int newapi_to_olddrv(struct dvbfe_params newfec_to_oldfec(dvbc->fec, &qam->fec_inner); break; case DVBFE_DELSYS_DVBT: + dprintk("%s (Debug): Delivery System=DVB-T\n,\ + Bandwidth=0x%04x\n,\ + Code Rate HP=0x%04x\n,\ + Code Rate LP=0x%04x\n,\ + Constellation=0x%04x\n,\ + Transmission mode=0x%04x\n,\ + Guard Interval=0x%04x\n,\ + Hierarchy=0x%04x\n,\ + Alpha=0x%04x\n",\ + __func__,\ + dvbt->bandwidth,\ + dvbt->code_rate_HP,\ + dvbt->code_rate_LP,\ + dvbt->constellation,\ + dvbt->transmission_mode,\ + dvbt->guard_interval,\ + dvbt->hierarchy,\ + dvbt->alpha); + switch (dvbt->bandwidth) { case DVBFE_BANDWIDTH_8_MHZ: ofdm->bandwidth = BANDWIDTH_8_MHZ; diff -r 4df151d5b3fe linux/drivers/media/dvb/frontends/tda1004x.c --- a/linux/drivers/media/dvb/frontends/tda1004x.c Sat Dec 01 01:50:24 2007 +0400 +++ b/linux/drivers/media/dvb/frontends/tda1004x.c Sun Jan 13 02:19:05 2008 +0400 @@ -688,6 +688,26 @@ static int tda1004x_set_fe(struct dvb_fr int inversion; dprintk("%s\n", __FUNCTION__); + dprintk("%s (Debug):\n,\ + Frequency=0x%04x\n,\ + Inversion=0x%04x\n,\ + Bandwidth=0x%04x\n,\ + Code Rate HP=0x%04x\n,\ + Code Rate LP=0x%04x\n,\ + Constellation=0x%04x\n,\ + Transmission mode=0x%04x\n,\ + Guard Interval=0x%04x\n,\ + Hierarchy info=0x%04x\n",\ + __func__,\ + fe_params->frequency,\ + fe_params->inversion,\ + fe_params->u.ofdm.bandwidth,\ + fe_params->u.ofdm.code_rate_HP,\ + fe_params->u.ofdm.code_rate_LP,\ + fe_params->u.ofdm.constellation,\ + fe_params->u.ofdm.transmission_mode,\ + fe_params->u.ofdm.guard_interval,\ + fe_params->u.ofdm.hierarchy_information); if (state->demod_type == TDA1004X_DEMOD_TDA10046) { // setup auto offset