Re: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21
Hi, Am 08.01.2012 02:09, schrieb Hawes, Mark: Hi Lars, I have got the sc plugin working with your hybrid patch v2 and introduced the premium card and all is working well. Are you planning any more revisions to the patch? Or at least a 1.7.22 version? Not really, because the driver changes introduced by Manu are on its way into linux-media. After that only one frontend will be left and new ioctls are there to switch between delivery systems. Rumours say Klaus is working on it for vdr 1.7.23... :-) But if you like, you can send me your changes. I'm curious about them. Lars. Thanks, Mark. -Original Message- From: Hawes, Mark Sent: Thursday, 1 December 2011 10:08 PM To: 'VDR Mailing List' Subject: RE: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21 Hi Lars, First reports on v2 of your multi-frontend patch with HVR 4000 card: - can switch between both frontends successfully and very stable with repetitive tests - timer behaviour as expected - switching response seems quicker than before - Streamdev and xineliboutput plugins compile OK. Xlo tested OK, will look at Sd later - Have modified Rotor plugin to fit (maintaining personal version) and all seems OK - Working through sc plugin changes to fit. If I can get the sc plugin working I'll move across a sd premium card into the mix and see how it behaves, watch this space ... While this is all good obviously things will no doubt change when Klaus releases 2.x with the new multi-frontend adapter handling. However, reading between the lines this may not be in the immediate future so an interim workaround for these cards is appreciated by me and I expect others ... Thanks and keep up the good work. Mark. -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of L. Hanisch Sent: Thursday, 1 December 2011 10:50 AM To: VDR Mailing List Subject: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21 Hi, Here's version 2 of my multi-frontend-patch. It's still dirty, since it changes the constructor of cDvbDevice which will break compilation of some plugins. But I think it might be necessary to look at the relevant plugins since they might need to react on frontend changes. I haven't tested any of those plugins but will have a look at some that I'm using. Maybe there have to be some virtual functions like BeforeFrontendSwitch and AfterFrontendSwitch so the plugins are even able to know about it. Assumption for this patch: All frontends within one adapter have to be used mutually exclusive. All cards I know behave in this way. If there are cards with multiple frontends which can be used simultaneously I'd like to hear about it. Whenever the dvb-api-changes are upstream (the ENUM_DELSYS thingy) I think my patch can easily be converted to use that. I'm still working on this patch, it's not finished yet... :-) Have fun, Lars. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21
On 08.01.2012 20:45, Lars Hanisch wrote: Hi, Am 08.01.2012 02:09, schrieb Hawes, Mark: Hi Lars, I have got the sc plugin working with your hybrid patch v2 and introduced the premium card and all is working well. Are you planning any more revisions to the patch? Or at least a 1.7.22 version? Not really, because the driver changes introduced by Manu are on its way into linux-media. After that only one frontend will be left and new ioctls are there to switch between delivery systems. Rumours say Klaus is working on it for vdr 1.7.23... :-) Version 1.7.23 will contain multi frontend support with the new API. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21
Am 08.01.2012 21:10, schrieb Klaus Schmidinger: On 08.01.2012 20:45, Lars Hanisch wrote: Not really, because the driver changes introduced by Manu are on its way into linux-media. After that only one frontend will be left and new ioctls are there to switch between delivery systems. Rumours say Klaus is working on it for vdr 1.7.23... :-) Version 1.7.23 will contain multi frontend support with the new API. Will 1.7.23 require a kernel with the new API or will it be backwards compatible? Otherwise, s2apiwrapper ftw! ;) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21
On 09.01.2012, at 00:19, Udo Richter udo_rich...@gmx.de wrote: Am 08.01.2012 21:10, schrieb Klaus Schmidinger: On 08.01.2012 20:45, Lars Hanisch wrote: Not really, because the driver changes introduced by Manu are on its way into linux-media. After that only one frontend will be left and new ioctls are there to switch between delivery systems. Rumours say Klaus is working on it for vdr 1.7.23... :-) Version 1.7.23 will contain multi frontend support with the new API. Will 1.7.23 require a kernel with the new API or will it be backwards compatible? It will be backwards compatible. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21
Hi Lars, I have got the sc plugin working with your hybrid patch v2 and introduced the premium card and all is working well. Are you planning any more revisions to the patch? Or at least a 1.7.22 version? Thanks, Mark. -Original Message- From: Hawes, Mark Sent: Thursday, 1 December 2011 10:08 PM To: 'VDR Mailing List' Subject: RE: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21 Hi Lars, First reports on v2 of your multi-frontend patch with HVR 4000 card: - can switch between both frontends successfully and very stable with repetitive tests - timer behaviour as expected - switching response seems quicker than before - Streamdev and xineliboutput plugins compile OK. Xlo tested OK, will look at Sd later - Have modified Rotor plugin to fit (maintaining personal version) and all seems OK - Working through sc plugin changes to fit. If I can get the sc plugin working I'll move across a sd premium card into the mix and see how it behaves, watch this space ... While this is all good obviously things will no doubt change when Klaus releases 2.x with the new multi-frontend adapter handling. However, reading between the lines this may not be in the immediate future so an interim workaround for these cards is appreciated by me and I expect others ... Thanks and keep up the good work. Mark. -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of L. Hanisch Sent: Thursday, 1 December 2011 10:50 AM To: VDR Mailing List Subject: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21 Hi, Here's version 2 of my multi-frontend-patch. It's still dirty, since it changes the constructor of cDvbDevice which will break compilation of some plugins. But I think it might be necessary to look at the relevant plugins since they might need to react on frontend changes. I haven't tested any of those plugins but will have a look at some that I'm using. Maybe there have to be some virtual functions like BeforeFrontendSwitch and AfterFrontendSwitch so the plugins are even able to know about it. Assumption for this patch: All frontends within one adapter have to be used mutually exclusive. All cards I know behave in this way. If there are cards with multiple frontends which can be used simultaneously I'd like to hear about it. Whenever the dvb-api-changes are upstream (the ENUM_DELSYS thingy) I think my patch can easily be converted to use that. I'm still working on this patch, it's not finished yet... :-) Have fun, Lars. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21
Hi Lars, First reports on v2 of your multi-frontend patch with HVR 4000 card: - can switch between both frontends successfully and very stable with repetitive tests - timer behaviour as expected - switching response seems quicker than before - Streamdev and xineliboutput plugins compile OK. Xlo tested OK, will look at Sd later - Have modified Rotor plugin to fit (maintaining personal version) and all seems OK - Working through sc plugin changes to fit. If I can get the sc plugin working I'll move across a sd premium card into the mix and see how it behaves, watch this space ... While this is all good obviously things will no doubt change when Klaus releases 2.x with the new multi-frontend adapter handling. However, reading between the lines this may not be in the immediate future so an interim workaround for these cards is appreciated by me and I expect others ... Thanks and keep up the good work. Mark. -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of L. Hanisch Sent: Thursday, 1 December 2011 10:50 AM To: VDR Mailing List Subject: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21 Hi, Here's version 2 of my multi-frontend-patch. It's still dirty, since it changes the constructor of cDvbDevice which will break compilation of some plugins. But I think it might be necessary to look at the relevant plugins since they might need to react on frontend changes. I haven't tested any of those plugins but will have a look at some that I'm using. Maybe there have to be some virtual functions like BeforeFrontendSwitch and AfterFrontendSwitch so the plugins are even able to know about it. Assumption for this patch: All frontends within one adapter have to be used mutually exclusive. All cards I know behave in this way. If there are cards with multiple frontends which can be used simultaneously I'd like to hear about it. Whenever the dvb-api-changes are upstream (the ENUM_DELSYS thingy) I think my patch can easily be converted to use that. I'm still working on this patch, it's not finished yet... :-) Have fun, Lars. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21
L. Hanisch wrote: Assumption for this patch: All frontends within one adapter have to be used mutually exclusive. All cards I know behave in this way. If there are cards with multiple frontends which can be used simultaneously I'd like to hear about it. I believe the TT S2-6400 DVB-S/DVB-S2 card has two frontends that can be used simultaneously. Regards, Richard ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21
Am Freitag, 2. Dezember 2011, 07:48:20 schrieb Richard Scobie: I believe the TT S2-6400 DVB-S/DVB-S2 card has two frontends that can be used simultaneously. but is has only one frontend per adapter, so it has no multi-frontend ./adapter0: insgesamt 0 crw-rw+ 1 root video 212, 0 29. Nov 20:02 demux0 crw-rw+ 1 root video 212, 1 29. Nov 20:02 dvr0 crw-rw+ 1 root video 212, 3 29. Nov 20:02 frontend0 crw-rw+ 1 root video 212, 2 29. Nov 20:02 net0 ./adapter1: insgesamt 0 crw-rw+ 1 root video 212, 13 29. Nov 20:03 audio0 crw-rw+ 1 root video 212, 4 29. Nov 20:03 demux0 crw-rw+ 1 root video 212, 5 29. Nov 20:03 dvr0 crw-rw+ 1 root video 212, 7 29. Nov 20:03 frontend0 crw-rw+ 1 root video 212, 6 29. Nov 20:03 net0 crw-rw+ 1 root video 212, 14 29. Nov 20:03 osd0 crw-rw+ 1 root video 212, 12 29. Nov 20:03 video0 -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21
Hi,
Here's version 2 of my multi-frontend-patch. It's still dirty, since it changes the constructor of cDvbDevice which
will break compilation of some plugins. But I think it might be necessary to look at the relevant plugins since they
might need to react on frontend changes. I haven't tested any of those plugins but will have a look at some that I'm
using. Maybe there have to be some virtual functions like BeforeFrontendSwitch and AfterFrontendSwitch so the
plugins are even able to know about it.
Assumption for this patch:
All frontends within one adapter have to be used mutually exclusive. All cards I know behave in this way. If there are
cards with multiple frontends which can be used simultaneously I'd like to hear about it.
Whenever the dvb-api-changes are upstream (the ENUM_DELSYS thingy) I think my
patch can easily be converted to use that.
I'm still working on this patch, it's not finished yet... :-)
Have fun,
Lars.
diff --git a/PLUGINS/src/dvbhddevice/dvbhdffdevice.c b/PLUGINS/src/dvbhddevice/dvbhdffdevice.c
index ff3f953..e7fb935 100644
--- a/PLUGINS/src/dvbhddevice/dvbhdffdevice.c
+++ b/PLUGINS/src/dvbhddevice/dvbhdffdevice.c
@@ -26,7 +26,8 @@
int cDvbHdFfDevice::devHdffOffset = -1;
cDvbHdFfDevice::cDvbHdFfDevice(int Adapter, int Frontend)
-:cDvbDevice(Adapter, Frontend)
+:cDvbDevice(Adapter)
+,frontend(Frontend)
{
spuDecoder = NULL;
audioChannel = 0;
diff --git a/PLUGINS/src/dvbhddevice/dvbhdffdevice.h b/PLUGINS/src/dvbhddevice/dvbhdffdevice.h
index 4dcfb6a..62540da 100644
--- a/PLUGINS/src/dvbhddevice/dvbhdffdevice.h
+++ b/PLUGINS/src/dvbhddevice/dvbhdffdevice.h
@@ -17,12 +17,13 @@
class cDvbHdFfDevice : public cDvbDevice {
private:
+ int frontend;
int fd_osd, fd_audio, fd_video;
protected:
virtual void MakePrimaryDevice(bool On);
public:
static bool Probe(int Adapter, int Frontend);
- cDvbHdFfDevice(int Adapter, int Frontend);
+ cDvbHdFfDevice(int Adapter, int Frontend = 0);
virtual ~cDvbHdFfDevice();
virtual bool HasDecoder(void) const;
diff --git a/PLUGINS/src/dvbsddevice/dvbsdffdevice.c b/PLUGINS/src/dvbsddevice/dvbsdffdevice.c
index 17f842b..68031b5 100644
--- a/PLUGINS/src/dvbsddevice/dvbsdffdevice.c
+++ b/PLUGINS/src/dvbsddevice/dvbsdffdevice.c
@@ -24,7 +24,8 @@
int cDvbSdFfDevice::devVideoOffset = -1;
cDvbSdFfDevice::cDvbSdFfDevice(int Adapter, int Frontend, bool OutputOnly)
-:cDvbDevice(Adapter, Frontend)
+:cDvbDevice(Adapter)
+,frontend(Frontend)
{
spuDecoder = NULL;
digitalAudio = false;
diff --git a/PLUGINS/src/dvbsddevice/dvbsdffdevice.h b/PLUGINS/src/dvbsddevice/dvbsdffdevice.h
index bd74cde..c060859 100644
--- a/PLUGINS/src/dvbsddevice/dvbsdffdevice.h
+++ b/PLUGINS/src/dvbsddevice/dvbsdffdevice.h
@@ -16,6 +16,7 @@
class cDvbSdFfDevice : public cDvbDevice {
private:
+ int frontend;
int fd_osd, fd_audio, fd_video, fd_stc;
bool outputOnly;
protected:
diff --git a/dvbci.c b/dvbci.c
index 5289bbd..5db673e 100644
--- a/dvbci.c
+++ b/dvbci.c
@@ -10,15 +10,32 @@
#include dvbci.h
#include linux/dvb/ca.h
#include sys/ioctl.h
-#include device.h
+#include dvbdevice.h
// --- cDvbCiAdapter -
-cDvbCiAdapter::cDvbCiAdapter(cDevice *Device, int Fd)
+cDvbCiAdapter::cDvbCiAdapter(cDevice *Device, int Fd, int Adapter, int Ca)
{
device = Device;
SetDescription(CI adapter on device %d, device-DeviceNumber());
fd = Fd;
+ adapter = Adapter;
+ ca = Ca;
+ gotCaps = false;
+ GetCaps();
+}
+
+cDvbCiAdapter::~cDvbCiAdapter()
+{
+ Cancel(3);
+ CloseCa();
+}
+
+void cDvbCiAdapter::GetCaps(void)
+{
+ if (gotCaps || (fd 0))
+ return;
+ gotCaps = true;
ca_caps_t Caps;
if (ioctl(fd, CA_GET_CAP, Caps) == 0) {
if ((Caps.slot_type CA_CI_LINK) != 0) {
@@ -38,13 +55,31 @@ cDvbCiAdapter::cDvbCiAdapter(cDevice *Device, int Fd)
esyslog(ERROR: can't get CA capabilities on device %d, device-DeviceNumber());
}
-cDvbCiAdapter::~cDvbCiAdapter()
+bool cDvbCiAdapter::OpenCa(void)
{
- Cancel(3);
+ if (fd = 0)
+ return true;
+ fd = cDvbDevice::DvbOpen(DEV_DVB_CA, adapter, ca, O_RDWR);
+ if (fd 0) {
+ esyslog(ERROR: can't open ca %d/%d, adapter, ca);
+ return false;
+ }
+ GetCaps();
+ return true;
+}
+
+void cDvbCiAdapter::CloseCa(void)
+{
+ if (fd 0)
+ return;
+ close(fd);
+ fd = -1;
}
int cDvbCiAdapter::Read(uint8_t *Buffer, int MaxLength)
{
+ if (fd 0)
+ return 0;
if (Buffer MaxLength 0) {
struct pollfd pfd[1];
pfd[0].fd = fd;
@@ -61,6 +96,8 @@ int cDvbCiAdapter::Read(uint8_t *Buffer, int MaxLength)
void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length)
{
+ if (fd 0)
+ return;
if (Buffer Length 0) {
if (safe_write(fd, Buffer, Length) != Length)
esyslog(ERROR: can't write to CI adapter on device %d: %m, device-DeviceNumber());
@@ -69,6 +106,8 @@ void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length)
bool cDvbCiAdapter::Reset(int Slot)
{
