Message ID | 493A9500.1060508@cadsoft.de |
---|---|
State | New |
Headers |
Received: from crow.cadsoft.de ([217.86.189.86] helo=raven.cadsoft.de) by www.linuxtv.org with esmtp (Exim 4.63) (envelope-from <Klaus.Schmidinger@cadsoft.de>) id 1L8yk3-0005f0-1I for vdr@linuxtv.org; Sat, 06 Dec 2008 16:06:49 +0100 Received: from [192.168.100.10] (hawk.cadsoft.de [192.168.100.10]) by raven.cadsoft.de (8.14.3/8.14.3) with ESMTP id mB6F6etT016054 for <vdr@linuxtv.org>; Sat, 6 Dec 2008 16:06:40 +0100 Message-ID: <493A9500.1060508@cadsoft.de> Date: Sat, 06 Dec 2008 16:06:40 +0100 From: Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> Organization: CadSoft Computer GmbH User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: vdr@linuxtv.org Content-Type: multipart/mixed; boundary="------------040003060708030005080109" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (raven.cadsoft.de [192.168.1.1]); Sat, 06 Dec 2008 16:06:43 +0100 (CET) X-LSpam-Score: -2.6 (--) X-LSpam-Report: No, score=-2.6 required=5.0 tests=AWL=0.008, BAYES_00=-2.599 autolearn=ham Subject: [vdr] VDR with S2API X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: VDR Mailing List <vdr@linuxtv.org> List-Id: VDR Mailing List <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Sat, 06 Dec 2008 15:06:49 -0000 Status: O X-Status: X-Keywords: X-UID: 18622 |
Commit Message
Klaus Schmidinger
Dec. 6, 2008, 3:06 p.m. UTC
The attached patch is what I've gathered from various postings regarding adapting VDR to the S2API driver API (thanks to Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?). Since the S2SAPI doesn't provide a way of determining whether a DVB-S device supports DVB-S2 (at least I didn't find any), you need to apply the second attached patch to the driver in order to impelement a new capability flag that reports the availability of DVB-S2 support. If you don't want to patch the driver, you can change the line case FE_QPSK: frontendType = (frontendInfo.caps & FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break; in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType permanently to SYS_DVBS or SYS_DVBS2, depending on what you have. So far DVB-S and DVB-S2 appears to tune fine. DVB-C is completely untested. With DVB-T tuning doesn't work, even though my TDA10046H based DVB-T card does work with the S2API driver under VDR 1.6.0. So for the moment I would appreciate if people could test DVB-T tuning and check whether maybe I made some silly mistake in the DVB-T tuning code. Klaus
Comments
El Sábado, 6 de Diciembre de 2008, Klaus Schmidinger escribió: > The attached patch is what I've gathered from various postings > regarding adapting VDR to the S2API driver API (thanks to > Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?). > > Since the S2SAPI doesn't provide a way of determining whether > a DVB-S device supports DVB-S2 (at least I didn't find any), > you need to apply the second attached patch to the driver > in order to impelement a new capability flag that reports > the availability of DVB-S2 support. > > If you don't want to patch the driver, you can change the line > > case FE_QPSK: frontendType = (frontendInfo.caps & > FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break; > > in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType > permanently to SYS_DVBS or SYS_DVBS2, depending on what you have. > > > So far DVB-S and DVB-S2 appears to tune fine. > DVB-C is completely untested. > With DVB-T tuning doesn't work, even though my TDA10046H based DVB-T card > does work with the S2API driver under VDR 1.6.0. > > So for the moment I would appreciate if people could test DVB-T > tuning and check whether maybe I made some silly mistake in the > DVB-T tuning code. > > Klaus For DVB-T in S2API the bandwidth must be in HZ. http://www.linuxtv.org/pipermail/linux-dvb/2008-October/029556.html Jose Alberto
On 06.12.2008 16:29, Jose Alberto Reguero wrote: > El Sábado, 6 de Diciembre de 2008, Klaus Schmidinger escribió: >> The attached patch is what I've gathered from various postings >> regarding adapting VDR to the S2API driver API (thanks to >> Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?). >> >> Since the S2SAPI doesn't provide a way of determining whether >> a DVB-S device supports DVB-S2 (at least I didn't find any), >> you need to apply the second attached patch to the driver >> in order to impelement a new capability flag that reports >> the availability of DVB-S2 support. >> >> If you don't want to patch the driver, you can change the line >> >> case FE_QPSK: frontendType = (frontendInfo.caps & >> FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break; >> >> in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType >> permanently to SYS_DVBS or SYS_DVBS2, depending on what you have. >> >> >> So far DVB-S and DVB-S2 appears to tune fine. >> DVB-C is completely untested. >> With DVB-T tuning doesn't work, even though my TDA10046H based DVB-T card >> does work with the S2API driver under VDR 1.6.0. >> >> So for the moment I would appreciate if people could test DVB-T >> tuning and check whether maybe I made some silly mistake in the >> DVB-T tuning code. >> >> Klaus > > For DVB-T in S2API the bandwidth must be in HZ. > > http://www.linuxtv.org/pipermail/linux-dvb/2008-October/029556.html > > > Jose Alberto So you mean we should not use the driver's constants like BANDWIDTH_8_MHZ etc., but use numerical values instead? Ok, if that's what it takes... With the value in Hz (e.g. 8000000) I can now tune DVB-T channels - thanks a lot! Klaus
? ????????? ?? 6 December 2008 17:06:40 Klaus Schmidinger ???????(?): > The attached patch is what I've gathered from various postings > regarding adapting VDR to the S2API driver API (thanks to > Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?). > > Since the S2SAPI doesn't provide a way of determining whether > a DVB-S device supports DVB-S2 (at least I didn't find any), > you need to apply the second attached patch to the driver > in order to impelement a new capability flag that reports > the availability of DVB-S2 support. > > If you don't want to patch the driver, you can change the line > > case FE_QPSK: frontendType = (frontendInfo.caps & > FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break; > > in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType > permanently to SYS_DVBS or SYS_DVBS2, depending on what you have. > > > So far DVB-S and DVB-S2 appears to tune fine. > DVB-C is completely untested. > With DVB-T tuning doesn't work, even though my TDA10046H based DVB-T card > does work with the S2API driver under VDR 1.6.0. > > So for the moment I would appreciate if people could test DVB-T > tuning and check whether maybe I made some silly mistake in the > DVB-T tuning code. > > Klaus Thank You for VDR. I really enjoy it.
???????????, Klaus does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ? > The attached patch is what I've gathered from various postings > regarding adapting VDR to the S2API driver API (thanks to > Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?). > > Since the S2SAPI doesn't provide a way of determining whether > a DVB-S device supports DVB-S2 (at least I didn't find any), > you need to apply the second attached patch to the driver > in order to impelement a new capability flag that reports > the availability of DVB-S2 support. > > If you don't want to patch the driver, you can change the line > > case FE_QPSK: frontendType = (frontendInfo.caps & FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break; > > in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType permanently > to SYS_DVBS or SYS_DVBS2, depending on what you have. > > > So far DVB-S and DVB-S2 appears to tune fine. > DVB-C is completely untested. > With DVB-T tuning doesn't work, even though my TDA10046H based DVB-T card > does work with the S2API driver under VDR 1.6.0. > > So for the moment I would appreciate if people could test DVB-T > tuning and check whether maybe I made some silly mistake in the > DVB-T tuning code.
On 06.12.2008 17:55, Goga777 wrote: > ðÒÉ×ÅÔÓÔ×ÕÀ, Klaus > > does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ? kls@hawk:/home/kls/vdr/vdr-1.7.0 > patch --dry-run < ../VDR/vdr-1.7.1-s2api.diff patching file channels.c Hunk #6 succeeded at 636 (offset -1 lines). Hunk #7 succeeded at 643 (offset -1 lines). Hunk #8 succeeded at 665 (offset -1 lines). Hunk #9 succeeded at 685 (offset -1 lines). patching file channels.h Hunk #2 succeeded at 146 (offset -1 lines). Hunk #3 succeeded at 203 (offset -2 lines). Hunk #4 succeeded at 215 (offset -2 lines). patching file dvbdevice.c Hunk #7 FAILED at 265. Hunk #8 FAILED at 323. Hunk #9 succeeded at 407 (offset 11 lines). Hunk #10 succeeded at 430 (offset 11 lines). Hunk #11 succeeded at 493 (offset 11 lines). Hunk #12 succeeded at 831 (offset 11 lines). 2 out of 12 hunks FAILED -- saving rejects to file dvbdevice.c.rej patching file dvbdevice.h patching file menu.c patching file nit.c Doesn't look too bad. You'll have to manually apply the failed hunks, though. Whether it will actually work, I have no idea... Klaus
???????????, Goga777 > ???????????, Klaus > > does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ? > ah, no /vdr170# patch -p1 < vdr-1.7.1-s2api_from_Klaus.diff patching file channels.c Hunk #6 succeeded at 636 (offset -1 lines). Hunk #7 succeeded at 643 (offset -1 lines). Hunk #8 succeeded at 665 (offset -1 lines). Hunk #9 succeeded at 685 (offset -1 lines). patching file channels.h Hunk #2 succeeded at 146 (offset -1 lines). Hunk #3 succeeded at 203 (offset -2 lines). Hunk #4 succeeded at 215 (offset -2 lines). patching file dvbdevice.c Hunk #7 FAILED at 265. Hunk #8 FAILED at 323. Hunk #9 succeeded at 407 (offset 11 lines). Hunk #10 succeeded at 430 (offset 11 lines). Hunk #11 succeeded at 493 (offset 11 lines). Hunk #12 succeeded at 831 (offset 11 lines). 2 out of 12 hunks FAILED -- saving rejects to file dvbdevice.c.rej patching file dvbdevice.h patching file menu.c patching file nit.c
> > does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ? > > kls@hawk:/home/kls/vdr/vdr-1.7.0 > patch --dry-run < ../VDR/vdr-1.7.1-s2api.diff > patching file channels.c > Hunk #6 succeeded at 636 (offset -1 lines). > Hunk #7 succeeded at 643 (offset -1 lines). > Hunk #8 succeeded at 665 (offset -1 lines). > Hunk #9 succeeded at 685 (offset -1 lines). > patching file channels.h > Hunk #2 succeeded at 146 (offset -1 lines). > Hunk #3 succeeded at 203 (offset -2 lines). > Hunk #4 succeeded at 215 (offset -2 lines). > patching file dvbdevice.c > Hunk #7 FAILED at 265. > Hunk #8 FAILED at 323. > Hunk #9 succeeded at 407 (offset 11 lines). > Hunk #10 succeeded at 430 (offset 11 lines). > Hunk #11 succeeded at 493 (offset 11 lines). > Hunk #12 succeeded at 831 (offset 11 lines). > 2 out of 12 hunks FAILED -- saving rejects to file dvbdevice.c.rej > patching file dvbdevice.h > patching file menu.c > patching file nit.c > > > Doesn't look too bad. You'll have to manually apply the failed hunks, though. > Whether it will actually work, I have no idea... btw - which patch are you using for h264 channels on your vdr 171 ? Goga
On 06.12.2008 18:16, Goga777 wrote: >>> does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ? >> kls@hawk:/home/kls/vdr/vdr-1.7.0 > patch --dry-run < ../VDR/vdr-1.7.1-s2api.diff >> patching file channels.c >> Hunk #6 succeeded at 636 (offset -1 lines). >> Hunk #7 succeeded at 643 (offset -1 lines). >> Hunk #8 succeeded at 665 (offset -1 lines). >> Hunk #9 succeeded at 685 (offset -1 lines). >> patching file channels.h >> Hunk #2 succeeded at 146 (offset -1 lines). >> Hunk #3 succeeded at 203 (offset -2 lines). >> Hunk #4 succeeded at 215 (offset -2 lines). >> patching file dvbdevice.c >> Hunk #7 FAILED at 265. >> Hunk #8 FAILED at 323. >> Hunk #9 succeeded at 407 (offset 11 lines). >> Hunk #10 succeeded at 430 (offset 11 lines). >> Hunk #11 succeeded at 493 (offset 11 lines). >> Hunk #12 succeeded at 831 (offset 11 lines). >> 2 out of 12 hunks FAILED -- saving rejects to file dvbdevice.c.rej >> patching file dvbdevice.h >> patching file menu.c >> patching file nit.c >> >> >> Doesn't look too bad. You'll have to manually apply the failed hunks, though. >> Whether it will actually work, I have no idea... > > btw - which patch are you using for h264 channels on your vdr 171 ? I haven't gotten that far, yet. So far I only watch "normal" MPEG channels. Klaus
On Sat, 6 Dec 2008, Klaus Schmidinger wrote: > If you don't want to patch the driver, you can change the line > case FE_QPSK: frontendType = (frontendInfo.caps & FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break; > in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType permanently > to SYS_DVBS or SYS_DVBS2, depending on what you have. Howabout just adding a FE_CAN_2ND_GEN_MODULATION define as a temporary workaroung into dvbdevice.c? It shouldn't interfere with the frontend capability enumeration and you'd have to patch only if you happen to have DVB-S2 hardware. I'm just guessing, but only a small minority of VDR users are having S2 capable hardware nowadays... + #define FE_CAN_2ND_GEN_MODULATION 0x10000000 BR, -- rofa
On 07.12.2008 00:34, Rolf Ahrenberg wrote: > On Sat, 6 Dec 2008, Klaus Schmidinger wrote: > >> If you don't want to patch the driver, you can change the line >> case FE_QPSK: frontendType = (frontendInfo.caps & FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break; >> in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType permanently >> to SYS_DVBS or SYS_DVBS2, depending on what you have. > > Howabout just adding a FE_CAN_2ND_GEN_MODULATION define as a temporary > workaroung into dvbdevice.c? It shouldn't interfere with the frontend > capability enumeration and you'd have to patch only if you happen to > have DVB-S2 hardware. I'm just guessing, but only a small minority of > VDR users are having S2 capable hardware nowadays... > > + #define FE_CAN_2ND_GEN_MODULATION 0x10000000 Sure, no problem. Klaus
Just found a small flaw: the cDvbDevice::ProvidesTransponder() function needs to be adapted to the fact that the delivery system is now an enum and no longer a flag word: bool cDvbDevice::ProvidesTransponder(const cChannel *Channel) const { if (!ProvidesSource(Channel->Source())) return false; // doesn't provide source if (!cSource::IsSat(Channel->Source())) return true; // source is sufficient for non sat if (frontendType == SYS_DVBS && Channel->System() == SYS_DVBS2) return false; // requires modulation system which frontend doesn't provide return !Setup.DiSEqC || Diseqcs.Get(Channel->Source(), Channel->Frequency(), Channel->Polarization()); } Maybe I'll map the SYS_DVB* stuff to a set of flags, so that these things can be handled as comfortably as in the multiproto API... Klaus
diff -ru v4l-dvb-17754ef554b0/linux/drivers/media/dvb/frontends/cx24116.c v4l-dvb-2008-11-22-17754ef554b0/linux/drivers/media/dvb/frontends/cx24116.c --- v4l-dvb-17754ef554b0/linux/drivers/media/dvb/frontends/cx24116.c 2008-11-21 23:00:55.000000000 +0100 +++ v4l-dvb-2008-11-22-17754ef554b0/linux/drivers/media/dvb/frontends/cx24116.c 2008-11-23 11:36:31.000000000 +0100 @@ -1459,6 +1459,7 @@ FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 | FE_CAN_FEC_3_4 | FE_CAN_FEC_4_5 | FE_CAN_FEC_5_6 | FE_CAN_FEC_6_7 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO | + FE_CAN_2ND_GEN_MODULATION | FE_CAN_QPSK | FE_CAN_RECOVER }, diff -ru v4l-dvb-17754ef554b0/linux/drivers/media/dvb/frontends/stb0899_drv.c v4l-dvb-2008-11-22-17754ef554b0/linux/drivers/media/dvb/frontends/stb0899_drv.c --- v4l-dvb-17754ef554b0/linux/drivers/media/dvb/frontends/stb0899_drv.c 2008-11-21 23:00:55.000000000 +0100 +++ v4l-dvb-2008-11-22-17754ef554b0/linux/drivers/media/dvb/frontends/stb0899_drv.c 2008-11-23 11:37:01.000000000 +0100 @@ -1913,6 +1913,7 @@ .caps = FE_CAN_INVERSION_AUTO | FE_CAN_FEC_AUTO | + FE_CAN_2ND_GEN_MODULATION | FE_CAN_QPSK }, diff -ru v4l-dvb-17754ef554b0/linux/include/linux/dvb/frontend.h v4l-dvb-2008-11-22-17754ef554b0/linux/include/linux/dvb/frontend.h --- v4l-dvb-17754ef554b0/linux/include/linux/dvb/frontend.h 2008-11-21 23:00:55.000000000 +0100 +++ v4l-dvb-2008-11-22-17754ef554b0/linux/include/linux/dvb/frontend.h 2008-11-23 11:27:21.000000000 +0100 @@ -63,6 +63,7 @@ FE_CAN_8VSB = 0x200000, FE_CAN_16VSB = 0x400000, FE_HAS_EXTENDED_CAPS = 0x800000, // We need more bitspace for newer APIs, indicate this. + FE_CAN_2ND_GEN_MODULATION = 0x10000000, // frontend supports "2nd generation modulation" (DVB-S2) FE_NEEDS_BENDING = 0x20000000, // not supported anymore, don't use (frontend requires frequency bending) FE_CAN_RECOVER = 0x40000000, // frontend can recover from a cable unplug automatically FE_CAN_MUTE_TS = 0x80000000 // frontend can stop spurious TS data output