From patchwork Mon Apr 5 18:55:38 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Petri Helin X-Patchwork-Id: 12803 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.69) (envelope-from ) id 1NyrSX-0007FI-JS for vdr@linuxtv.org; Mon, 05 Apr 2010 20:55:42 +0200 X-tubIT-Incoming-IP: 209.85.220.211 Received: from mail-fx0-f211.google.com ([209.85.220.211]) by mail.tu-berlin.de (exim-4.69/mailfrontend-a) with esmtp for id 1NyrSW-00062W-CX; Mon, 05 Apr 2010 20:55:41 +0200 Received: by fxm3 with SMTP id 3so2890748fxm.11 for ; Mon, 05 Apr 2010 11:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=HuS76VtRpo8hEYY9KYKDjLTQha+5XW689th2c623pTg=; b=pescBlac9t+f7pR47vXJcGZ22QS0MuthD4K2hw9H073hOBU4I+S+mbQKjuzGTMwoHe pLx0Bdb3jOD5fPqJc0gQBBGTL1qub0ozmTCk6qH4XNlsMgawd/PSGVKemej51vOstOLV WfEV/NGgu72qN0/kFmReY3BqDCYKK4tdNEIbU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=AIgj1QaDFmyYCuPHVwAI3vghIbOj8WCI3FP95+7qDc/qrsyl73IFsd00Zgf0tlbMS9 n/Dwce4Zpv8De1LWMkUE7qYxb5h77XCP9z4Bhb/iqT1WZ/331IPqY1/mSzm8Jmm5YGpv kid3FyMGPNxbqK9GFxRR9EmRLg+YPjqZqXWVI= Received: by 10.223.21.23 with SMTP id h23mr6185537fab.21.1270493739721; Mon, 05 Apr 2010 11:55:39 -0700 (PDT) Received: from [192.168.1.149] (cs181234207.pp.htv.fi [82.181.234.207]) by mx.google.com with ESMTPS id 1sm11054357fkt.11.2010.04.05.11.55.38 (version=SSLv3 cipher=RC4-MD5); Mon, 05 Apr 2010 11:55:39 -0700 (PDT) Message-ID: <4BBA322A.7020708@googlemail.com> Date: Mon, 05 Apr 2010 21:55:38 +0300 From: Petri Helin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100322 Thunderbird/3.0.3 MIME-Version: 1.0 To: VDR Mailing List References: <4AE8C294.6000409@googlemail.com> <4BB9B41C.3010702@tvdr.de> In-Reply-To: <4BB9B41C.3010702@tvdr.de> X-tubIT-Score: 0.0 () X-PMX-Version: 5.5.4.371499, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2010.4.5.184818 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, ECARD_WORD 0, WEBMAIL_SOURCE 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __DATE_TZ_RU 0, __FRAUD_WEBMAIL 0, __FRAUD_WEBMAIL_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_GMAIL 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __URI_NO_MAILTO 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __USER_AGENT 0' X-LSpam-Score: -3.0 (---) X-LSpam-Report: No, score=-3.0 required=5.0 tests=AWL=0.608, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1 autolearn=ham Subject: Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.11 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: Mon, 05 Apr 2010 18:55:42 -0000 Status: O X-Status: X-Keywords: X-UID: 22780 On 04/05/2010 12:57 PM, Klaus Schmidinger wrote: > On 05.04.2010 00:55, Teemu Rantanen wrote: > >> Hi, >> >> There's a new version of the patch implemented as a plugin. It seems to >> work, but there are few things to notice: >> >> - Plugin does not cache which devices are Reddo devices, instead it >> probes sysfs every time QAM256 channel is being tuned into (on any >> device). It would be nice if cDeviceHook added a mechanism for a hook to >> store context for each device. Hooking into device probe (like full >> feature card plugin does) would be much nicer way, but it would >> interfere with other plugins which need the same mechanism. >> > The proper way of doing this is to check the modulation types > in cDvbDevice::ProvidesTransponder(), as in the attached patch (which will > be part of VDR 1.7.15). If the "reddo" driver doesn't set the FE_CAN_QAM_256 > flag correctly, it needs to be fixed there. > > I used your patch as an example and created a simple test patch for dvb-c (I think yours is for dvb-s(2) only) in order to test the approach. I also disabled FE_CAN_QAM256 from the driver. After that VDR no longer used Reddo for QAM256 channels as expected. The approach is very limited: It disables QAM256 for the every TDA10023 frontend, not just for Reddo's, and it doesn't make VDR to prefer Reddo for non QAM256 channels, which would make sense in order to keep QAM256 channels available as much as possible. The patches are inline below: if (frontendType == SYS_DVBS && dtp.System() == SYS_DVBS2) return false; // requires modulation system which frontend doesn't provide --- v4l-dvb/linux/drivers/media/dvb/frontends/tda10023.c.orig 2010-04-05 15:28:22.605844128 +0300 +++ v4l-dvb/linux/drivers/media/dvb/frontends/tda10023.c 2010-04-05 15:27:54.934343796 +0300 @@ -553,7 +553,7 @@ #endif .caps = 0x400 | //FE_CAN_QAM_4 FE_CAN_QAM_16 | FE_CAN_QAM_32 | FE_CAN_QAM_64 | - FE_CAN_QAM_128 | FE_CAN_QAM_256 | + FE_CAN_QAM_128 | //FE_CAN_QAM_256 | FE_CAN_FEC_AUTO }, -Petri --- dvbdevice.c.orig 2010-02-21 19:10:35.000000000 +0200 +++ dvbdevice.c 2010-04-05 17:20:06.080525344 +0300 @@ -872,8 +872,12 @@ { if (!ProvidesSource(Channel->Source())) return false; // doesn't provide source - if (!cSource::IsSat(Channel->Source())) + if (!cSource::IsSat(Channel->Source())) { + cDvbTransponderParameters dtp(Channel->Parameters()); + if (dtp.Modulation() == QAM_256 && !(frontendInfo.caps & FE_CAN_QAM_256)) + return false; return DeviceHooksProvidesTransponder(Channel); // source is sufficient for non sat + } cDvbTransponderParameters dtp(Channel->Parameters());