DVB-S2 / Multiproto and future modulation support

Datum: Fri, 29 Aug 2008 14:29:30 -0400
Von: Steven Toth <[email protected]>
An: linux-dvb <[email protected]>
Betreff: [linux-dvb] DVB-S2 / Multiproto and future modulation support

Regarding the multiproto situation:

A number of developers, maintainers and users are unhappy with the multiproto situation, actually they've been unhappy for a considerable amount of time. The linuxtv developer community (to some degree) is seen as a joke and a bunch in-fighting people. Multiproto is a great demonstration of this. [1] The multiproto project has gone too far, for too long and no longer has any credibility in the eyes of many people.

In response, a number developers have agreed that "enough is enough" and "it's time to take a new direction", for these developers the technical, political and personal cost of multiproto is too high. These developers have decided to make an announcement.

Mauro Chehab, Michael Krufky, Patrick Boettcher and myself are hereby announcing that we no longer support multiproto and are forming a smaller dedicated project group which is focusing on adding next generation S2/ISDB-T/DVB-H/DVB-T2/DVB-SH support to the kernel through a different and simpler API.

Basic patches and demo code for this API is currently available here.

http://www.steventoth.net/linux/s2

Does it even work? Yes
Is this new API complete? No
Is it perfect? No, we've already had feedback on structural and namingspace changes that people would like to see.
Does it have bugs? Of course, we have a list of things we already know we want to fix.

but ...

Is the new approach flexible? Yes, we're moving away from passing fixed modulation structures into the kernel.
Can we add to it without breaking the future ABI when unforseen modulations types occur? Yes
Does it preserve backwards compatibility? Yes
Importantly, is the overall direction correct? Yes
Does it impact existing frontend drivers? No.
What's the impact to dvb-core? Small.
What's the impact to application developers? None, unless an application developer wants to support the new standards - binary compatibility!

We want feedback and we want progress, we aim to achieve it.

Importantly, this project group seeks your support.

If you also feel frustrated by the multiproto situation and agree in principle with this new approach, and the overall direction of the API changes, then we welcome you and ask you to help us.

Growing the list of supporting names by 100%, and allowing us to publish your name on the public mailing list, would show the non-maintainer development community that we recognize the problem and we're taking steps to correct the problem. We want to make LinuxTV a perfect platform for S2, ISDB-T and other advanced modulation types, without using the multiproto patches.

We're not asking you for technical help, although we'd like that :) , we're just asking for your encouragement to move away from multiproto.

If you feel that you want to support our movement then please help us by acking this email.

Regards - Steve, Mike, Patrick and Mauro.

Acked-by Patrick Boettcher <[email protected]>

Acked-by Michael Krufky <[email protected]>

Acked-by Steven Toth <[email protected]>

Acked-by Mauro Carvalho Chehab <[email protected]>

* [1]. Rather than point out the issues with multiproto here, take a look at the patches and/or read the comments on the mailing lists.

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Regarding the multiproto situation:

A number of developers, maintainers and users are unhappy with the multiproto situation, actually they've been unhappy for a considerable amount of time. The linuxtv developer community (to some degree) is seen as a joke and a bunch in-fighting people. Multiproto is a great demonstration of this. [1] The multiproto project has gone too far, for too long and no longer has any credibility in the eyes of many people.

In response, a number developers have agreed that "enough is enough" and "it's time to take a new direction", for these developers the technical, political and personal cost of multiproto is too high. These developers have decided to make an announcement.

Mauro Chehab, Michael Krufky, Patrick Boettcher and myself are hereby announcing that we no longer support multiproto and are forming a smaller dedicated project group which is focusing on adding next generation S2/ISDB-T/DVB-H/DVB-T2/DVB-SH support to the kernel through a different and simpler API.

Basic patches and demo code for this API is currently available here.

http://www.steventoth.net/linux/s2

Does it even work? Yes
Is this new API complete? No
Is it perfect? No, we've already had feedback on structural and namingspace changes that people would like to see.
Does it have bugs? Of course, we have a list of things we already know we want to fix.

but ...

Is the new approach flexible? Yes, we're moving away from passing fixed modulation structures into the kernel.
Can we add to it without breaking the future ABI when unforseen modulations types occur? Yes
Does it preserve backwards compatibility? Yes
Importantly, is the overall direction correct? Yes
Does it impact existing frontend drivers? No.
What's the impact to dvb-core? Small.
What's the impact to application developers? None, unless an application developer wants to support the new standards - binary compatibility!

We want feedback and we want progress, we aim to achieve it.

Importantly, this project group seeks your support.

If you also feel frustrated by the multiproto situation and agree in principle with this new approach, and the overall direction of the API changes, then we welcome you and ask you to help us.

Growing the list of supporting names by 100%, and allowing us to publish your name on the public mailing list, would show the non-maintainer development community that we recognize the problem and we're taking steps to correct the problem. We want to make LinuxTV a perfect platform for S2, ISDB-T and other advanced modulation types, without using the multiproto patches.

We're not asking you for technical help, although we'd like that :) , we're just asking for your encouragement to move away from multiproto.

If you feel that you want to support our movement then please help us by acking this email.

Regards - Steve, Mike, Patrick and Mauro.

Acked-by Patrick Boettcher <[email protected]>

Acked-by Michael Krufky <[email protected]>

Acked-by Steven Toth <[email protected]>

Acked-by Mauro Carvalho Chehab <[email protected]>

* [1]. Rather than point out the issues with multiproto here, take a look at the patches and/or read the comments on the mailing lists.

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Is there a patch for VDR to use this (vdr works really well with multiproto right now, which don't mean I wouldn't choose this one, but I should try it before).

Regarding the multiproto situation:

A number of developers, maintainers and users are unhappy with the multiproto situation, actually they've been unhappy for a considerable amount of time. The linuxtv developer community (to some degree) is seen as a joke and a bunch in-fighting people. Multiproto is a great demonstration of this. [1] The multiproto project has gone too far, for too long and no longer has any credibility in the eyes of many people.

In response, a number developers have agreed that "enough is enough" and "it's time to take a new direction", for these developers the technical, political and personal cost of multiproto is too high. These developers have decided to make an announcement.

Mauro Chehab, Michael Krufky, Patrick Boettcher and myself are hereby announcing that we no longer support multiproto and are forming a smaller dedicated project group which is focusing on adding next generation S2/ISDB-T/DVB-H/DVB-T2/DVB-SH support to the kernel through a different and simpler API.

Basic patches and demo code for this API is currently available here.

http://www.steventoth.net/linux/s2

Does it even work? Yes
Is this new API complete? No
Is it perfect? No, we've already had feedback on structural and namingspace changes that people would like to see.
Does it have bugs? Of course, we have a list of things we already know we want to fix.

but ...

Is the new approach flexible? Yes, we're moving away from passing fixed modulation structures into the kernel.
Can we add to it without breaking the future ABI when unforseen modulations types occur? Yes
Does it preserve backwards compatibility? Yes
Importantly, is the overall direction correct? Yes
Does it impact existing frontend drivers? No.
What's the impact to dvb-core? Small.
What's the impact to application developers? None, unless an application developer wants to support the new standards - binary compatibility!

We want feedback and we want progress, we aim to achieve it.

Importantly, this project group seeks your support.

If you also feel frustrated by the multiproto situation and agree in principle with this new approach, and the overall direction of the API changes, then we welcome you and ask you to help us.

Growing the list of supporting names by 100%, and allowing us to publish your name on the public mailing list, would show the non-maintainer development community that we recognize the problem and we're taking steps to correct the problem. We want to make LinuxTV a perfect platform for S2, ISDB-T and other advanced modulation types, without using the multiproto patches.

We're not asking you for technical help, although we'd like that :) , we're just asking for your encouragement to move away from multiproto.

If you feel that you want to support our movement then please help us by acking this email.

Regards - Steve, Mike, Patrick and Mauro.

Acked-by Patrick Boettcher <[email protected]>

Acked-by Michael Krufky <[email protected]>

Acked-by Steven Toth <[email protected]>

Acked-by Mauro Carvalho Chehab <[email protected]>

* [1]. Rather than point out the issues with multiproto here, take a look at the patches and/or read the comments on the mailing lists.

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Quoted 2 lines

If you feel that you want to support our movement then please help us by acking this email.

Good.
We are all waiting for a new API.
As Johannes said some months ago, the first one (individual or group) that will come with something good enougth will win.
Sadly, Manu's work could be lost, but he's the only one that knows why. Kaffeine will support the winner.

Acked-by Christophe Thommeret <[email protected]>

P.S.
1) imho, DTV_ prefix would make more sense.

2) if someone want to donate a S2 card ...

Regarding the multiproto situation:

A number of developers, maintainers and users are unhappy with the multiproto situation, actually they've been unhappy for a considerable amount of time. The linuxtv developer community (to some degree) is seen as a joke and a bunch in-fighting people. Multiproto is a great demonstration of this. [1] The multiproto project has gone too far, for too long and no longer has any credibility in the eyes of many people.

In response, a number developers have agreed that "enough is enough" and "it's time to take a new direction", for these developers the technical, political and personal cost of multiproto is too high. These developers have decided to make an announcement.

Mauro Chehab, Michael Krufky, Patrick Boettcher and myself are hereby announcing that we no longer support multiproto and are forming a smaller dedicated project group which is focusing on adding next generation S2/ISDB-T/DVB-H/DVB-T2/DVB-SH support to the kernel through a different and simpler API.

Basic patches and demo code for this API is currently available here.

http://www.steventoth.net/linux/s2

Does it even work? Yes
Is this new API complete? No
Is it perfect? No, we've already had feedback on structural and namingspace changes that people would like to see.
Does it have bugs? Of course, we have a list of things we already know we want to fix.

but ...

Is the new approach flexible? Yes, we're moving away from passing fixed modulation structures into the kernel.
Can we add to it without breaking the future ABI when unforseen modulations types occur? Yes
Does it preserve backwards compatibility? Yes
Importantly, is the overall direction correct? Yes
Does it impact existing frontend drivers? No.
What's the impact to dvb-core? Small.
What's the impact to application developers? None, unless an application developer wants to support the new standards - binary compatibility!

We want feedback and we want progress, we aim to achieve it.

Importantly, this project group seeks your support.

If you also feel frustrated by the multiproto situation and agree in principle with this new approach, and the overall direction of the API changes, then we welcome you and ask you to help us.

Growing the list of supporting names by 100%, and allowing us to publish your name on the public mailing list, would show the non-maintainer development community that we recognize the problem and we're taking steps to correct the problem. We want to make LinuxTV a perfect platform for S2, ISDB-T and other advanced modulation types, without using the multiproto patches.

We're not asking you for technical help, although we'd like that :) , we're just asking for your encouragement to move away from multiproto.

If you feel that you want to support our movement then please help us by acking this email.

Regards - Steve, Mike, Patrick and Mauro.

Acked-by Patrick Boettcher <[email protected]>

Acked-by Michael Krufky <[email protected]>

Acked-by Steven Toth <[email protected]>

Acked-by Mauro Carvalho Chehab <[email protected]>

* [1]. Rather than point out the issues with multiproto here, take a look at the patches and/or read the comments on the mailing lists.

As I am not willing to spend a single minute of my time with API wars, I will ack this API only if the multiproto developer and the users agree with this approach.

Quoted 2 lines · Steven Toth

http://www.steventoth.net/linux/s2

Guys, I don't like the way you do this. ;-(

Why didn't you propose this API when we reviewed multiproto? Meanwhile there are applications (vdr, others?) which implement the multiproto API.

Quoted 9 lines

Quoted 2 lines · Steven Toth

http://www.steventoth.net/linux/s2

Guys, I don't like the way you do this. ;-(

Why didn't you propose this API when we reviewed multiproto? Meanwhile there are applications (vdr, others?) which implement the multiproto API.

The proposal isn't new, there was some discussion on the list in Nov 2007. For reasons unknown to me I cannot find Steve's original mail on the topic in the list archives, but here's my reply:

http://linuxtv.org/pipermail/linux-dvb/2007-November/021618.html
http://article.gmane.org/gmane.linux.drivers.dvb/37214

Johannes

Regarding the multiproto situation:

[...]
If you feel that you want to support our movement then please help us by acking this email.

Regards - Steve, Mike, Patrick and Mauro.
[...]

Quoted 8 lines · Steven Toth

Regarding the multiproto situation:

[...]
If you feel that you want to support our movement then please help us by acking this email.

Regards - Steve, Mike, Patrick and Mauro.
[...]

Full ACK!

While appreciating Manu's work and actually using Multiproto without major issues for some time now, I see that it will never move forward this way. We have to get S2 support into the vanilla kernel <full-stop>

My main concern is the multiproto work that has already been done for vdr (specifically 1.7.0), so while not being a programmer at all I'd like to express my support in offering resources: If any of the core programmers working on the new API needs something (test VM with DVB-S2 cards actually hooked up to multiple satellites, webspace, bandwidth, ...) please let me know!

Regarding the multiproto situation:

.....

We're not asking you for technical help, although we'd like that :) , we're just asking for your encouragement to move away from multiproto.

If you feel that you want to support our movement then please help us by acking this email.

Regards - Steve, Mike, Patrick and Mauro.

Acked-by Patrick Boettcher <[email protected]>

Acked-by Michael Krufky <[email protected]>

Acked-by Steven Toth <[email protected]>

Acked-by Mauro Carvalho Chehab <[email protected]>

* [1]. Rather than point out the issues with multiproto here, take a look at the patches and/or read the comments on the mailing lists.

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

It's not my place to judge if the problem is moving in the right direction or not but it's a good thing that something happens. I'll trust the experienced devs whom acked this proposal.

Writting a multiproto patch for kaffeine to get dvb-s2 support, got me to learn a bit about v4l-dvb api and multiproto. Again i'm no experienced coder, i followed some examples to keep v4l-dvb backward compatibility and it wasn't really a walk in the park nor was it really necessary now that i look at it, either your use multiproto or you don't and if you do, patch your app and build it again.
But well it's working and that's what was most important to me, to get it working "asap".

So as Christophe Thommeret wrote, who helped a lot dealing with kaffeine, i'll support whichever api is going to bring dvb-s2 and new dvb hardware support to the kernel.

In the meantime i'll keep using and maintaining my multiproto patch as it's curently done with most other applications, so end users don't have to wait for the whole kernel thing to get completed.

And of course if or when the new api has to be tested and modifications to be done on the application side, i'll join the effort.

Marc.

Acked-by Marc Delcambre <[email protected]>

If you feel that you want to support our movement then please help us by acking this email.

Quoted 2 lines · Steven Toth

If you feel that you want to support our movement then please help us by acking this email.

In general, I like your proposal.

Acked-by Andreas Oberritter <[email protected]>

Regarding the code:
1) What's TV_SEQ_CONTINUE good for? It seems to be unused.

2) Like Christophe I'd prefer to use DTV_ and dtv_ prefixes.

3) Did you mean p.u.qam.modulation below? Also, p.u.qam.fec_inner is missing.

(quoted diff) +6 -0

+		printk("%s() Preparing QAM req\n", __FUNCTION__);
+		/* TODO: Insert sanity code to validate a little. */
+		p.frequency = c->frequency;
+		p.inversion = c->inversion;
+		p.u.qam.symbol_rate = c->symbol_rate;		
+		p.u.vsb.modulation = c->modulation;

4) About enum tv_cmd_types:

SYMBOLRATE -> SYMBOL_RATE?
INNERFEC -> INNER_FEC (or FEC)?

The Tone Burst command got lost (FE_DISEQC_SEND_BURST). How about TV_SET_TONE_BURST?

FE_ENABLE_HIGH_LNB_VOLTAGE got lost, too.

Which old ioctls should be considered as obsolete? Do you plan to add a tv_cmd for every old ioctl?

Regarding the multiproto situation:

A number of developers, maintainers and users are unhappy with the multiproto situation, actually they've been unhappy for a considerable amount of time. The linuxtv developer community (to some degree) is seen as a joke and a bunch in-fighting people. Multiproto is a great demonstration of this. [1] The multiproto project has gone too far, for too long and no longer has any credibility in the eyes of many people.

Hi,

Quoted 2 lines · Steven Toth

Regarding the multiproto situation:

Quoted 6 lines

A number of developers, maintainers and users are unhappy with the multiproto situation, actually they've been unhappy for a considerable amount of time. The linuxtv developer community (to some degree) is seen as a joke and a bunch in-fighting people. Multiproto is a great demonstration of this. [1] The multiproto project has gone too far, for too long and no longer has any credibility in the eyes of many people.

Can you please explain me what you do not like in multiproto?

Hi, Steven

- if new api will be approve, who will update the drivers for stb0899 based cards ?

- if new api will be approve, how long time need for first release of updated dvb-s2 drivers for cx24116/stb0899 cards ?

Quoted 7 lines · Artem Makhutov

Hi,

Quoted 2 lines · Steven Toth

Regarding the multiproto situation:

Quoted 1 line

Can you please explain me what you do not like in multiproto?

1. Where is the support for ISDB-T/ATSC-MH/CMMB/DVB-H/DBM-T/H and other modulation types. If we're going to make a massive kernel change then why aren't we accommodating these new modulation types?

If we don't
added now then we'll have the rev the kernel ABI again in 2 months....

that isn't a forward looking future proof API.

2. It's too big, too risky, too late. It doesn't add enough new fatures to the kernel to justify the massive code change.

Hi,

Quoted 8 lines · Steven Toth

Regarding the multiproto situation:

A number of developers, maintainers and users are unhappy with the multiproto situation, actually they've been unhappy for a considerable amount of time. The linuxtv developer community (to some degree) is seen as a joke and a bunch in-fighting people. Multiproto is a great demonstration of this. [1] The multiproto project has gone too far, for too long and no longer has any credibility in the eyes of many people.

Can you please explain me what you do not like in multiproto?

I can only see the two issues right now:

1. Binary incompatibility

As the DVB-API was not developed to work with advanced modulations like DVB-S2 an API change is a must. As soon multiproto is in kernel the distros and application maintainer will patch their applications to work with multiproto.

Mauro Chehab, Michael Krufky, Patrick Boettcher and myself are hereby announcing that we no longer support multiproto and are forming a smaller dedicated project group which is focusing on adding next generation S2/ISDB-T/DVB-H/DVB-T2/DVB-SH support to the kernel through a different and simpler API.

Basic patches and demo code for this API is currently available here.

http://www.steventoth.net/linux/s2

Importantly, this project group seeks your support.

If you also feel frustrated by the multiproto situation and agree in principle with this new approach, and the overall direction of the API changes, then we welcome you and ask you to help us.

Growing the list of supporting names by 100%, and allowing us to publish your name on the public mailing list, would show the non-maintainer development community that we recognize the problem and we're taking steps to correct the problem. We want to make LinuxTV a perfect platform for S2, ISDB-T and other advanced modulation types, without using the multiproto patches.

We're not asking you for technical help, although we'd like that :) , we're just asking for your encouragement to move away from multiproto.

If you feel that you want to support our movement then please help us by acking this email.

Quoted 6 lines · On Friday 29 August 2008 20:29:30 Steven Toth wrote:

Mauro Chehab, Michael Krufky, Patrick Boettcher and myself are hereby announcing that we no longer support multiproto and are forming a smaller dedicated project group which is focusing on adding next generation S2/ISDB-T/DVB-H/DVB-T2/DVB-SH support to the kernel through a different and simpler API.

Quoted 3 lines

Basic patches and demo code for this API is currently available here.

http://www.steventoth.net/linux/s2

Overall API looks good.

I have also a slightly preference for DTV/dtv as prefix but it's not really important.

16 properties per ioctl are probably enough but a variable-length property array would be safe. I'm unsure if this justifies a more complicate copy from/to userspace in the ioctls.

Quoted 14 lines

Importantly, this project group seeks your support.

If you also feel frustrated by the multiproto situation and agree in principle with this new approach, and the overall direction of the API changes, then we welcome you and ask you to help us.

Growing the list of supporting names by 100%, and allowing us to publish your name on the public mailing list, would show the non-maintainer development community that we recognize the problem and we're taking steps to correct the problem. We want to make LinuxTV a perfect platform for S2, ISDB-T and other advanced modulation types, without using the multiproto patches.

Quoted 6 lines

We're not asking you for technical help, although we'd like that :) , we're just asking for your encouragement to move away from multiproto.

If you feel that you want to support our movement then please help us by acking this email.

Acked-by Janne Grunau <[email protected]>

If you feel that you want to support our movement then please help us by acking this email.

Regards - Steve, Mike, Patrick and Mauro.

Acked-by Patrick Boettcher <[email protected]>

Acked-by Michael Krufky <[email protected]>

Acked-by Steven Toth <[email protected]>

Acked-by Mauro Carvalho Chehab <[email protected]>

Hello,

Quoted 3 lines · On Fri, 29 Aug 2008 14:29:30 -0400 Steven Toth <[email protected]> wrote:

If you feel that you want to support our movement then please help us by acking this email.

Quoted 6 lines

Regards - Steve, Mike, Patrick and Mauro.

Acked-by Patrick Boettcher <[email protected]>

Acked-by Michael Krufky <[email protected]>

Acked-by Steven Toth <[email protected]>

Acked-by Mauro Carvalho Chehab <[email protected]>

Acked-by Douglas Schilling Landgraf <[email protected]>

Regarding the multiproto situation:

A number of developers, maintainers and users are unhappy with the multiproto situation, actually they've been unhappy for a considerable amount of time. The linuxtv developer community (to some degree) is seen as a joke and a bunch in-fighting people. Multiproto is a great demonstration of this. [1] The multiproto project has gone too far, for too long and no longer has any credibility in the eyes of many people.

In response, a number developers have agreed that "enough is enough" and "it's time to take a new direction", for these developers the technical, political and personal cost of multiproto is too high. These developers have decided to make an announcement.

Mauro Chehab, Michael Krufky, Patrick Boettcher and myself are hereby announcing that we no longer support multiproto and are forming a smaller dedicated project group which is focusing on adding next generation S2/ISDB-T/DVB-H/DVB-T2/DVB-SH support to the kernel through a different and simpler API.

Basic patches and demo code for this API is currently available here.

http://www.steventoth.net/linux/s2

Does it even work? Yes
Is this new API complete? No
Is it perfect? No, we've already had feedback on structural and namingspace changes that people would like to see.
Does it have bugs? Of course, we have a list of things we already know we want to fix.

but ...

Is the new approach flexible? Yes, we're moving away from passing fixed modulation structures into the kernel.
Can we add to it without breaking the future ABI when unforseen modulations types occur? Yes
Does it preserve backwards compatibility? Yes
Importantly, is the overall direction correct? Yes
Does it impact existing frontend drivers? No.
What's the impact to dvb-core? Small.
What's the impact to application developers? None, unless an application developer wants to support the new standards - binary compatibility!

We want feedback and we want progress, we aim to achieve it.

Importantly, this project group seeks your support.

If you also feel frustrated by the multiproto situation and agree in principle with this new approach, and the overall direction of the API changes, then we welcome you and ask you to help us.

Growing the list of supporting names by 100%, and allowing us to publish your name on the public mailing list, would show the non-maintainer development community that we recognize the problem and we're taking steps to correct the problem. We want to make LinuxTV a perfect platform for S2, ISDB-T and other advanced modulation types, without using the multiproto patches.

We're not asking you for technical help, although we'd like that :) , we're just asking for your encouragement to move away from multiproto.

If you feel that you want to support our movement then please help us by acking this email.

Regards - Steve, Mike, Patrick and Mauro.

Acked-by Patrick Boettcher <[email protected]>

Acked-by Michael Krufky <[email protected]>

Acked-by Steven Toth <[email protected]>

Acked-by Mauro Carvalho Chehab <[email protected]>

Quoted 67 lines · Steven Toth

Regarding the multiproto situation:

A number of developers, maintainers and users are unhappy with the multiproto situation, actually they've been unhappy for a considerable amount of time. The linuxtv developer community (to some degree) is seen as a joke and a bunch in-fighting people. Multiproto is a great demonstration of this. [1] The multiproto project has gone too far, for too long and no longer has any credibility in the eyes of many people.

In response, a number developers have agreed that "enough is enough" and "it's time to take a new direction", for these developers the technical, political and personal cost of multiproto is too high. These developers have decided to make an announcement.

Mauro Chehab, Michael Krufky, Patrick Boettcher and myself are hereby announcing that we no longer support multiproto and are forming a smaller dedicated project group which is focusing on adding next generation S2/ISDB-T/DVB-H/DVB-T2/DVB-SH support to the kernel through a different and simpler API.

Basic patches and demo code for this API is currently available here.

http://www.steventoth.net/linux/s2

Does it even work? Yes
Is this new API complete? No
Is it perfect? No, we've already had feedback on structural and namingspace changes that people would like to see.
Does it have bugs? Of course, we have a list of things we already know we want to fix.

but ...

Is the new approach flexible? Yes, we're moving away from passing fixed modulation structures into the kernel.
Can we add to it without breaking the future ABI when unforseen modulations types occur? Yes
Does it preserve backwards compatibility? Yes
Importantly, is the overall direction correct? Yes
Does it impact existing frontend drivers? No.
What's the impact to dvb-core? Small.
What's the impact to application developers? None, unless an application developer wants to support the new standards - binary compatibility!

We want feedback and we want progress, we aim to achieve it.

Importantly, this project group seeks your support.

If you also feel frustrated by the multiproto situation and agree in principle with this new approach, and the overall direction of the API changes, then we welcome you and ask you to help us.

Growing the list of supporting names by 100%, and allowing us to publish your name on the public mailing list, would show the non-maintainer development community that we recognize the problem and we're taking steps to correct the problem. We want to make LinuxTV a perfect platform for S2, ISDB-T and other advanced modulation types, without using the multiproto patches.

We're not asking you for technical help, although we'd like that :) , we're just asking for your encouragement to move away from multiproto.

If you feel that you want to support our movement then please help us by acking this email.

Regards - Steve, Mike, Patrick and Mauro.

Quoted 4 lines

Acked-by Patrick Boettcher <[email protected]>

Acked-by Michael Krufky <[email protected]>

Acked-by Steven Toth <[email protected]>

Acked-by Mauro Carvalho Chehab <[email protected]>

Acked-by Nicolas Will <[email protected]>

I can't review code or provide any, but I have a server if needed.

DVB-S2 and DVB-T2 (when it arrrives) are of interst to me.

If you also feel frustrated by the multiproto situation and agree in principle with this new approach, and the overall direction of the API changes, then we welcome you and ask you to help us.

Quoted 4 lines

If you also feel frustrated by the multiproto situation and agree in principle with this new approach, and the overall direction of the API changes, then we welcome you and ask you to help us.

I wholeheartedly agree.

Although I can't offer any programming input, I do have a variety of DVB hardware and different architectures on which I can test your creations.

Happy to help.

Quoted 5 lines · Charles Price

Quoted 4 lines

If you also feel frustrated by the multiproto situation and agree in principle with this new approach, and the overall direction of the API changes, then we welcome you and ask you to help us.

Quoted 6 lines

I wholeheartedly agree.

Although I can't offer any programming input, I do have a variety of DVB hardware and different architectures on which I can test your creations.

Happy to help.

Let's put another thing in here: Greg Kroah Hartman Linux Guy reverted

my patch in favour of supporting the binary Firmware upload tool of Dell (I fully support Dell here too) although claiming to be opensource but still running after someone (please comment this one - it confused me at 'your' position). It was just like ok let's revert it but not asking why?!

Quoted 1 line · Markus Rechberger

Let's put another thing in here: Greg Kroah Hartman Linux Guy reverted

If you're going to spell my full last name out, please get it right, you forgot a '-' :)

Quoted 5 lines

my patch in favour of supporting the binary Firmware upload tool of Dell (I fully support Dell here too) although claiming to be opensource but still running after someone (please comment this one - it confused me at 'your' position). It was just like ok let's revert it but not asking why?!

What patch specifically are you referring to here?

And what does this have to do with v4l and DVB issues?

thanks,

greg k-h

-----Original Message-----
From: [email protected] [mailto:linux-dvb- [email protected]] On Behalf Of Markus Rechberger
Sent: 31 August 2008 04:58
To: Steven Toth; Linux Kernel Mailing List; Greg KH
Cc: [email protected]; [email protected]
Subject: Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

Quoted 2 lines · Steven Toth

Quoted 1 line · Charles Price

Quoted 1 line

If you also feel frustrated by the multiproto situation and agree

in

Quoted 1 line

Quoted 1 line

Quoted 1 line

principle with this new approach, and the overall direction of the

API

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

changes, then we welcome you and ask you to help us.

I wholeheartedly agree.

Although I can't offer any programming input, I do have a variety of

DVB

Quoted 1 line

Quoted 1 line

hardware and different architectures on which I can test your

creations.

Quoted 3 lines

Quoted 2 lines

Happy to help.

not reading the parts above, but saying this is Steven, not caring about the main people who work on something.

There's a split between a few people here (including myself) and other people from that scene who just don't care about anything.

Manu and the others put in alot work, why screw what he wrote (code) he has been on vacation (I know he married a few weeks ago - since I got the invitation) Hauppauge people (Michael Krufky and Steven Toth) are running their personal own game .. sorry to say that but it's that way.

I have logs and mails here where Steven and Mike wrote hey that would be a cool idea about compatibility but when "I" mentioned it again and spent work on it it was like hey we're linux only (I don't only care about linux since I also work alot with commercial companies in that area look at the dibcom website - Job requirement 'independent' code neither do I want to depend on Windows nor Linux but having something that works on both in case of hardware is fine - especially I2C is trivial to realize for everything).

Rethink your position and try to get people onboard but don't try to screw people and run your own game.

Seeing the comments Acked-By: xyz - I cannot review neither contribute code but I can provide webspace .. hilarious. get down on earth again Steven, Mike expecially Mauro - try to get Manufacturers onboard instead working against you.
I talked alot with Manu he has good connections and is avoing to work together just as I am because of certain Monopoly and copyright infringements which you are building here (I see Mauro using leaked code here!) . Mauro is spreading foo, Manu has the specs for xyz. I fully understand Manu's point since Mauro did the same with me, however .. I better don't comment it.

Let's put another thing in here: Greg Kroah Hartman Linux Guy reverted my patch in favour of supporting the binary Firmware upload tool of Dell (I fully support Dell here too) although claiming to be opensource but still running after someone (please comment this one - it confused me at 'your' position). It was just like ok let's revert it but not asking why?!
I'm just getting up with this just because I saw following yesterday:
21:07 < pmp> hmm: request_firmware(&fw, CX24116_DEFAULT_FIRMWARE, &state->i2c->dev) ?
21:08 < pmp> the &state->i2c->dev looks strange and the kernel is saying that about it: kobject_add failed
for i2c-1 with -EEXIST, don't try to re....
21:09 < pmp> other fe-driver have a callback in their config-struct... 21:09 < pmp> I start to believe there is a reason ;)

I better cut it now.

Markus

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.138 / Virus Database: 270.6.14/1643 - Release Date:
30/08/2008 17:18

Quoted 11 lines · Steven Toth

Quoted 10 lines · Charles Price

Quoted 4 lines

If you also feel frustrated by the multiproto situation and agree in principle with this new approach, and the overall direction of the API changes, then we welcome you and ask you to help us.

I wholeheartedly agree.

Although I can't offer any programming input, I do have a variety of DVB hardware and different architectures on which I can test your creations.

Happy to help.

not reading the parts above, but saying this is Steven, not caring about the main people who work on something.

There's a split between a few people here (including myself) and other people from that scene who just don't care about anything.

Manu and the others put in alot work, why screw what he wrote (code) he has been on vacation (I know he married a few weeks ago - since I got the invitation) Hauppauge people (Michael Krufky and Steven Toth) are running their personal own game .. sorry to say that but it's that way.

I have logs and mails here where Steven and Mike wrote hey that would be a cool idea about compatibility but when "I" mentioned it again and spent work on it it was like hey we're linux only (I don't only care about linux since I also work alot with commercial companies in that area look at the dibcom website - Job requirement 'independent' code neither do I want to depend on Windows nor Linux but having something that works on both in case of hardware is fine - especially I2C is trivial to realize for everything).

Rethink your position and try to get people onboard but don't try to screw people and run your own game.

Seeing the comments Acked-By: xyz - I cannot review neither contribute code but I can provide webspace .. hilarious. get down on earth again Steven, Mike expecially Mauro - try to get Manufacturers onboard instead working against you.
I talked alot with Manu he has good connections and is avoing to work together just as I am because of certain Monopoly and copyright infringements which you are building here (I see Mauro using leaked code here!) . Mauro is spreading foo, Manu has the specs for xyz. I fully understand Manu's point since Mauro did the same with me, however .. I better don't comment it.

Let's put another thing in here: Greg Kroah Hartman Linux Guy reverted my patch in favour of supporting the binary Firmware upload tool of Dell (I fully support Dell here too) although claiming to be opensource but still running after someone (please comment this one - it confused me at 'your' position). It was just like ok let's revert it but not asking why?!
I'm just getting up with this just because I saw following yesterday:
21:07 < pmp> hmm: request_firmware(&fw, CX24116_DEFAULT_FIRMWARE, &state->i2c->dev) ?
21:08 < pmp> the &state->i2c->dev looks strange and the kernel is saying that about it: kobject_add failed
for i2c-1 with -EEXIST, don't try to re....
21:09 < pmp> other fe-driver have a callback in their config-struct... 21:09 < pmp> I start to believe there is a reason ;)

I better cut it now.

Regarding the multiproto situation:

we're just asking for your encouragement to move away from multiproto.

If you feel that you want to support our movement then please help us by acking this email.

Regards - Steve, Mike, Patrick and Mauro.

Dear people.

Let me introduce my position. I've bought an unsupported board. The hardware developer gave me some code, derived from the Windows driver. I'm trying to tidy up the code sufficiently for inclusion.

What bothers me about this discussion, is that NO technical facts pro or contra are exchanged, and that it seems like a personal and/or progress issue.
Looking at:
http://linuxtv.org/docs.php
I find that neither party includes an update on the Documentation tree
http://linuxtv.org/hg/v4l-dvb/file/tip/linux/Documentation/dvb/
This means that actually trying to find out the pros and cons of what is proposed must be derived from reading all the code and/or walking through some years' worth of mail group contents.

So my questions are:
1) Why are the latex sources of the API documentation still maintained in CVS ?
http://linuxtv.org/cgi-bin/viewcvs.cgi/DVB/doc/
2) Are both solutions bit-for-bit compatible with the interfaces as published on :
http://linuxtv.org/downloads/linux-dvb-api-1.0.0.pdf
3) If so: what is the problem ? Both conform to the standard.
4) If not so: please provide updated documentation for both solutions, so that we can make a trade-off based on high-level descriptions and consistency rather than based on lots of code of either side.

So far, my reaction (for what it's worth) is a NACK.

Regarding the multiproto situation:

A number of developers, maintainers and users are unhappy with the multiproto situation, actually they've been unhappy for a considerable amount of time. The linuxtv developer community (to some degree) is

as a joke and a bunch in-fighting people. Multiproto is a great demonstration of this. [1] The multiproto project has gone too far,

too long and no longer has any credibility in the eyes of many people.

In response, a number developers have agreed that "enough is enough"

"it's time to take a new direction", for these developers the

political and personal cost of multiproto is too high. These

have decided to make an announcement.

Mauro Chehab, Michael Krufky, Patrick Boettcher and myself are hereby announcing that we no longer support multiproto and are forming a smaller dedicated project group which is focusing on adding next generation S2/ISDB-T/DVB-H/DVB-T2/DVB-SH support to the kernel through

different and simpler API.

Basic patches and demo code for this API is currently available here.

http://www.steventoth.net/linux/s2

Does it even work? Yes
Is this new API complete? No
Is it perfect? No, we've already had feedback on structural and namingspace changes that people would like to see.
Does it have bugs? Of course, we have a list of things we already know we want to fix.

but ...

Is the new approach flexible? Yes, we're moving away from passing

modulation structures into the kernel.
Can we add to it without breaking the future ABI when unforseen modulations types occur? Yes
Does it preserve backwards compatibility? Yes Importantly, is the overall direction correct? Yes Does it impact existing frontend drivers? No.
What's the impact to dvb-core? Small.
What's the impact to application developers? None, unless an

developer wants to support the new standards - binary compatibility!

We want feedback and we want progress, we aim to achieve it.

Importantly, this project group seeks your support.

If you also feel frustrated by the multiproto situation and agree in principle with this new approach, and the overall direction of the API changes, then we welcome you and ask you to help us.

Growing the list of supporting names by 100%, and allowing us to

your name on the public mailing list, would show the non-maintainer development community that we recognize the problem and we're taking steps to correct the problem. We want to make LinuxTV a perfect

for S2, ISDB-T and other advanced modulation types, without using the multiproto patches.

We're not asking you for technical help, although we'd like that :) , we're just asking for your encouragement to move away from multiproto.

If you feel that you want to support our movement then please help us

acking this email.

Regards - Steve, Mike, Patrick and Mauro.

Acked-by Patrick Boettcher <[email protected]>

Acked-by Michael Krufky <[email protected]>

Acked-by Steven Toth <[email protected]>

Acked-by Mauro Carvalho Chehab <[email protected]>

* [1]. Rather than point out the issues with multiproto here, take a look at the patches and/or read the comments on the mailing lists.

Hi Steve,

Quoted 5 lines · On Friday 29 August 2008 20:29:30 Steven Toth wrote:

Regarding the multiproto situation:

A number of developers, maintainers and users are unhappy with the multiproto situation, actually they've been unhappy for a considerable amount of time. The linuxtv developer community (to some degree) is

seen

Quoted 2 lines

as a joke and a bunch in-fighting people. Multiproto is a great demonstration of this. [1] The multiproto project has gone too far,

for

Quoted 3 lines

too long and no longer has any credibility in the eyes of many people.

In response, a number developers have agreed that "enough is enough"

and

Quoted 1 line

"it's time to take a new direction", for these developers the

technical,

Quoted 1 line

political and personal cost of multiproto is too high. These

developers

Quoted 6 lines

have decided to make an announcement.

Mauro Chehab, Michael Krufky, Patrick Boettcher and myself are hereby announcing that we no longer support multiproto and are forming a smaller dedicated project group which is focusing on adding next generation S2/ISDB-T/DVB-H/DVB-T2/DVB-SH support to the kernel through

a

Quoted 13 lines

different and simpler API.

Basic patches and demo code for this API is currently available here.

http://www.steventoth.net/linux/s2

Does it even work? Yes
Is this new API complete? No
Is it perfect? No, we've already had feedback on structural and namingspace changes that people would like to see.
Does it have bugs? Of course, we have a list of things we already know we want to fix.

Quoted 3 lines

but ...

Is the new approach flexible? Yes, we're moving away from passing

fixed

Quoted 8 lines

modulation structures into the kernel.
Can we add to it without breaking the future ABI when unforseen modulations types occur? Yes
Does it preserve backwards compatibility? Yes Importantly, is the overall direction correct? Yes Does it impact existing frontend drivers? No.
What's the impact to dvb-core? Small.
What's the impact to application developers? None, unless an

application

Quoted 3 lines

developer wants to support the new standards - binary compatibility!

We want feedback and we want progress, we aim to achieve it.

Feedback is no problem :-)

I noticed that the properties work very similar as to how extended controls work in v4l:
http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html#VIDIOC-G-EXT-CTRLS

It might be useful to compare the two.

I would recommend adding a few reserved fields, since that has proven to be very useful in v4l to make the API more future proof.

Also: is setting multiple properties an atomic action? E.g. if one fails, are all other changes rolled back as well? And how do you give the caller feedback on which property in the list failed? Will there also be a TRY_PROPERTIES variant which just checks for correctness without actually setting it? How do you query/test whether a device has certain properties?

Do you need separate get and set commands? Why not either set or get a list of properties, and setting them implies an automatic SEQ_COMPLETE at the end. By having a variable length array of properties you do not need to set the properties in multiple blocks of 16, so that simplifies the API as well.

As I said, extended controls in v4l do something very similar. I thought about the extended controls a great deal at the time, so it might provide a handy comparison for you.

Quoted 8 lines

Importantly, this project group seeks your support.

If you also feel frustrated by the multiproto situation and agree in principle with this new approach, and the overall direction of the API changes, then we welcome you and ask you to help us.

Growing the list of supporting names by 100%, and allowing us to

publish

Quoted 3 lines

your name on the public mailing list, would show the non-maintainer development community that we recognize the problem and we're taking steps to correct the problem. We want to make LinuxTV a perfect

platform

Quoted 7 lines

for S2, ISDB-T and other advanced modulation types, without using the multiproto patches.

We're not asking you for technical help, although we'd like that :) , we're just asking for your encouragement to move away from multiproto.

If you feel that you want to support our movement then please help us

by

Quoted 9 lines

acking this email.

Regards - Steve, Mike, Patrick and Mauro.

Acked-by Patrick Boettcher <[email protected]>

Acked-by Michael Krufky <[email protected]>

Acked-by Steven Toth <[email protected]>

Acked-by Mauro Carvalho Chehab <[email protected]>

Quoted 2 lines

* [1]. Rather than point out the issues with multiproto here, take a look at the patches and/or read the comments on the mailing lists.

While I am no dvb expert I do think that this is a good and simple approach that should be reasonably future proof. It needs some work to hammer out the details, but I like it.

Acked-by Hans Verkuil <[email protected]>

Quoted 1 line

Is this card able to deliver both S and T at the same time?

No, the hardware can do S/S2 or T.

The driver in the S2API tree only has S/S2 enabled (for the time being).

Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :

Quoted 6 lines

Quoted 1 line

Is this card able to deliver both S and T at the same time?

No, the hardware can do S/S2 or T.

The driver in the S2API tree only has S/S2 enabled (for the time being).

So, maybe we have to think a bit about how to add support for this kind of device.

Maybe a solution could be to have :
- adapter0/frontend0 -> S/S2 tuner
- adapter0/frontend1 -> T tuner

So applications could know that these 2 frontends are exclusive. That would not require any API change, but would have to be a rule followed by all drivers.

Quoted 13 lines · On Wednesday 10 September 2008 17:10:19 Christophe Thommeret wrote:

Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :

Quoted 5 lines

Quoted 1 line

Is this card able to deliver both S and T at the same time?

No, the hardware can do S/S2 or T.

The driver in the S2API tree only has S/S2 enabled (for the time being).

So, maybe we have to think a bit about how to add support for this kind of device.

Maybe a solution could be to have :
- adapter0/frontend0 -> S/S2 tuner
- adapter0/frontend1 -> T tuner

Quoted 3 lines

So applications could know that these 2 frontends are exclusive. That would not require any API change, but would have to be a rule followed by all drivers.

The experimental HVR4000 does this already and we have at least initial support for that in mythtv.

I don't think this was the intended use of multiple frontends in the DVB API but AFAIK all dual tuners drivers uses multiple adapters.

I like this approach.

Quoted 14 lines · Janne Grunau

Quoted 13 lines · On Wednesday 10 September 2008 17:10:19 Christophe Thommeret wrote:

Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :

Quoted 5 lines

Quoted 1 line

Is this card able to deliver both S and T at the same time?

No, the hardware can do S/S2 or T.

The driver in the S2API tree only has S/S2 enabled (for the time being).

So, maybe we have to think a bit about how to add support for this kind of device.

Maybe a solution could be to have :
- adapter0/frontend0 -> S/S2 tuner
- adapter0/frontend1 -> T tuner

Quoted 6 lines

Quoted 3 lines

So applications could know that these 2 frontends are exclusive. That would not require any API change, but would have to be a rule followed by all drivers.

The experimental HVR4000 does this already and we have at least initial support for that in mythtv.

Yes, I believe it was added sometime ago.

Quoted 3 lines

I don't think this was the intended use of multiple frontends in the DVB API but AFAIK all dual tuners drivers uses multiple adapters.

It actually was intended for use, it came from patches based on linuxtv.org/hg/~stoth/hvr3000 2 years ago, for this exact reason.

The idea died on the vine, except for a few die-hard people to maintained their own spin-off/derivative.

Quoted 1 line

Quoted 1 line

I like this approach.

So do I, it solves a lot of problems with multiple frontends on a single transport bus. At the time I did not patch the 7134 framework with the minor changes for it to comply, but if that's done then the 6-in-1 7134 Dual DVB-S/T/Analog card would also benefit greatly. Right now that card only supports some functions in the kernel (IIRC).

It's been a very long time but this was also mentioned on the mailing list.

Datum: Wed, 10 Sep 2008 17:10:19 +0200
Von: Christophe Thommeret <[email protected]>
An: Steven Toth <[email protected]>
CC: [email protected]
Betreff: Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :

Quoted 5 lines

Quoted 1 line

Is this card able to deliver both S and T at the same time?

No, the hardware can do S/S2 or T.

The driver in the S2API tree only has S/S2 enabled (for the time being).

So, maybe we have to think a bit about how to add support for this kind of device.

I mean, if the driver provides different adapters/frontends (say adapter0/frontend0 and adapter1/frontend0), a typical application will see these as separate devices, and then when a user watch a S channel, the app assumes that the T frontend is free while in fact it's not. For example, Kaffeine updates its channels list according to which channels
can be viewed (based on which frontends are free). So, if you are recording a
S channel, all channels on this freq are shown as available and all T channels are also shown as available. But in the HVR4000 case, it's false, since the T tuner isn't free.

Maybe a solution could be to have :
- adapter0/frontend0 -> S/S2 tuner
- adapter0/frontend1 -> T tuner

So applications could know that these 2 frontends are exclusive. That would not require any API change, but would have to be a rule followed by
all drivers.

-------- Original-Nachricht --------

Quoted 6 lines

Datum: Wed, 10 Sep 2008 17:10:19 +0200
Von: Christophe Thommeret <[email protected]>
An: Steven Toth <[email protected]>
CC: [email protected]
Betreff: Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

Quoted 6 lines

Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :

Quoted 3 lines

Quoted 1 line

Is this card able to deliver both S and T at the same time?

No, the hardware can do S/S2 or T.
The driver in the S2API tree only has S/S2 enabled (for the time being).

So, maybe we have to think a bit about how to add support for this kind of device.

Yes, absolutely, and I hope this can go in to S2API and the kernel. It would be a lie to claim that linux supports the HVR4000 until this is done. Fortunately Steven and Darron made experimental drivers which do this.

Quoted 12 lines

I mean, if the driver provides different adapters/frontends (say adapter0/frontend0 and adapter1/frontend0), a typical application will see these as separate devices, and then when a user watch a S channel, the app assumes that the T frontend is free while in fact it's not. For example, Kaffeine updates its channels list according to which channels
can be viewed (based on which frontends are free). So, if you are recording a
S channel, all channels on this freq are shown as available and all T channels are also shown as available. But in the HVR4000 case, it's false, since the T tuner isn't free.

Quoted 3 lines

Maybe a solution could be to have :
- adapter0/frontend0 -> S/S2 tuner
- adapter0/frontend1 -> T tuner

This is what the multifrontend (mfe) driver at http://dev.kewl.org/hauppauge does. And Kaffeine is the only major DVB app which correctly finds the two frontends and uses them correctly (well done!!). Or very nearly -- TV watching is perfect, but the only slight problem happens when you are recording:

(1) record a DVB-T channel:
-->all DVB-T channels except those in same multiplex vanish from the available channels list (correct)
-->no satellite channels vanish (incorrect)

(2) record a DVB-S channel;
-->all DVB-S channels except those on the same multiplex vanish from the available channels list (correct)
-->no DVB-T channels vanish (incorrect)

It's a small problem, easily fixed I would think.

Quoted 4 lines

So applications could know that these 2 frontends are exclusive. That would not require any API change, but would have to be a rule followed by
all drivers.

Yes, if we keep to that rule then only frontends which can operate truly simultaneously should have a different adapter number.

Quoted 58 lines · Hans Werner

-------- Original-Nachricht --------

Quoted 8 lines

Datum: Wed, 10 Sep 2008 17:10:19 +0200
Von: Christophe Thommeret <[email protected]>
An: Steven Toth <[email protected]>
CC: [email protected]
Betreff: Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

Is this card able to deliver both S and T at the same time?

No, the hardware can do S/S2 or T.
The driver in the S2API tree only has S/S2 enabled (for the time being).

So, maybe we have to think a bit about how to add support for this kind of device.

Yes, absolutely, and I hope this can go in to S2API and the kernel. It would be a lie to claim that linux supports the HVR4000 until this is done. Fortunately Steven and Darron made experimental drivers which do this.

Quoted 12 lines

I mean, if the driver provides different adapters/frontends (say adapter0/frontend0 and adapter1/frontend0), a typical application will see these as separate devices, and then when a user watch a S channel, the app assumes that the T frontend is free while in fact it's not. For example, Kaffeine updates its channels list according to which channels
can be viewed (based on which frontends are free). So, if you are recording a
S channel, all channels on this freq are shown as available and all T channels are also shown as available. But in the HVR4000 case, it's false, since the T tuner isn't free.

Quoted 3 lines

Maybe a solution could be to have :
- adapter0/frontend0 -> S/S2 tuner
- adapter0/frontend1 -> T tuner

This is what the multifrontend (mfe) driver at
http://dev.kewl.org/hauppauge does. And Kaffeine is the only major DVB app which correctly finds the two frontends and uses them correctly (well done!!). Or very nearly -- TV watching is perfect, but the only slight problem happens when you are recording:

(1) record a DVB-T channel:
-->all DVB-T channels except those in same multiplex vanish from the available channels list (correct)
-->no satellite channels vanish (incorrect)

(2) record a DVB-S channel;
-->all DVB-S channels except those on the same multiplex vanish from the available channels list (correct)
-->no DVB-T channels vanish (incorrect)

It's a small problem, easily fixed I would think.

Quoted 7 lines

Quoted 4 lines

So applications could know that these 2 frontends are exclusive. That would not require any API change, but would have to be a rule followed by
all drivers.

Yes, if we keep to that rule then only frontends which can operate truly simultaneously should have a different adapter number.

If everyone wants this in the S2API tree then it's pretty simple to add, I just didn't want to overload the tree with too much baggage that causes it to get stuck in the approval process.

We need an S2 API in the next few weeks, and anything that delays that is bad news for everyone.

I'll publish a mail about this in a separate thread, and seek feedback from everyone.

From: Christophe Thommeret <[email protected]>
Subject: [linux-dvb] Multiple frontends on a single adapter support
To: [email protected]
Date: Thursday, September 11, 2008, 4:35 PM
Hi all,

( Please don't mix this thread with the "DVB-S2 /
Multiproto and future
modulation support" thread. )

Summary:

Some devices provide several tuners, even of different types.
So called "Dual" or "Twin" tuners can
be used at the same time.
Some others (like HVR4000) can't be used at the same time.

My initial question was: How could an application know that 2 (or more) tuners
are exclusive (when one is used the other(s) is(are) not free.)

I suggested the following:
Since actually all multiple tuners drivers expose several fontend0 in separate
adapters, maybe a solution for exclusive tuners could be to have :
- adapter0/frontend0 -> S/S2 tuner
- adapter0/frontend1 -> T tuner
so, an application could assume that these tuners are exclusive.

Janne Grunau acked the idea and said that an experimental driver for HVR4000
is already doing this.

This was confirmed by Steven Toth:
"Correct, frontend1, demux1, dvr1 etc. All on the same adapter. The
driver and multi-frontend patches manage exclusive access to the single
internal resource."

Andreas Oberritter said:
"This way is used on dual and quad tuner Dreambox models." (non exclusive
tuners).
"How about dropping demux1 and dvr1 for this adapter (exclusive tuners), since
they don't create any benefit? IMHO the number of demux devices should always
equal the number of simultaneously usable transport stream inputs."

Uri Shkolnik said:
"Some of the hardware devices which using our chipset have two tuners per
instance, and should expose 1-2 tuners with 0-2 demux (TS), since not all DTV
standard are TS based, and when they are (TS based), it depends when you are
using two given tuners together (diversity  mode, same content) or each one
is used separately (different frequency and modulation, different content,
etc.)."

So, here are my questions:

@Steven Toth:
What do you think of Andreas' suggestion? Do you think it could be done that
way for HVR4000 (and 3000?) ?

@Uri Shkolnik:
Do you mean that non-TS based standards don't make use of multiplexing at all?

Signature · 8 lines

-- 
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Andreas Oberritter said:
"This way is used on dual and quad tuner Dreambox models." (non exclusive tuners).
"How about dropping demux1 and dvr1 for this adapter (exclusive tuners), since they don't create any benefit? IMHO the number of demux devices should always equal the number of simultaneously usable transport stream inputs."

So, here are my questions:

@Steven Toth:
What do you think of Andreas' suggestion? Do you think it could be done that way for HVR4000 (and 3000?) ?

Quoted 4 lines

So applications could know that these 2 frontends are exclusive. That would not require any API change, but would have to be a rule followed by
all drivers.

Yes, if we keep to that rule then only frontends which can operate truly simultaneously should have a different adapter number.

Quoted 7 lines · Hans Werner

Quoted 4 lines

So applications could know that these 2 frontends are exclusive. That would not require any API change, but would have to be a rule followed by
all drivers.

Yes, if we keep to that rule then only frontends which can operate truly simultaneously should have a different adapter number.

An adapter refers to a self-contained piece of hardware, whose parts can not be used by a second adapter (e.g. adapter0/demux0 can not access the data from adapter1/frontend1). In a commonly used setup it means that adapter0 is the first initialized PCI card and adapter1 is the second.

Now, if you want a device with two tuners that can be accessed simultaneously to create a second adapter, then you would have to artificially divide its components so that it looks like two independant PCI cards. This might become very complicated and limits the functions of the hardware.

However, on a setup with multiple accessible tuners you can expect at least the same amount of accessible demux devices on the same adapter (and also dvr devices for that matter). There is an ioctl to connect a frontend to a specific demux (DMX_SET_SOURCE).

So, if there are demux0, frontend0 and frontend1, then the application knows that it can't use both frontends simultaneously. Otherwise, if there are demux0, demux1, frontend0 and frontend1, then it can use both of them (by using both demux devices and connecting them to the frontends via the ioctl mentioned above).

Le Thursday 11 September 2008 00:59:31 Andreas Oberritter, vous avez écrit :

Quoted 23 lines

Quoted 6 lines · Hans Werner

Quoted 4 lines

So applications could know that these 2 frontends are exclusive. That would not require any API change, but would have to be a rule followed by
all drivers.

Yes, if we keep to that rule then only frontends which can operate truly simultaneously should have a different adapter number.

An adapter refers to a self-contained piece of hardware, whose parts can not be used by a second adapter (e.g. adapter0/demux0 can not access the data from adapter1/frontend1). In a commonly used setup it means that adapter0 is the first initialized PCI card and adapter1 is the second.

Now, if you want a device with two tuners that can be accessed simultaneously to create a second adapter, then you would have to artificially divide its components so that it looks like two independant PCI cards. This might become very complicated and limits the functions of the hardware.

However, on a setup with multiple accessible tuners you can expect at least the same amount of accessible demux devices on the same adapter (and also dvr devices for that matter). There is an ioctl to connect a frontend to a specific demux (DMX_SET_SOURCE).

Quoted 5 lines

So, if there are demux0, frontend0 and frontend1, then the application knows that it can't use both frontends simultaneously. Otherwise, if there are demux0, demux1, frontend0 and frontend1, then it can use both of them (by using both demux devices and connecting them to the frontends via the ioctl mentioned above).

Sounds logical. And that's why Kaffeine search for frontend/demux/dvr > 0 and uses demux1 with frontend1. (That was just a guess since i've never seen neither any such devices nor comments/recommendations/rules about such case).

However, all dual tuners devices drivers i know expose the 2 frontends as frontend0 in separate adapters. But all these devices seems to be USB.

The fact that Kaffeine works with the experimental hvr4000 driver indicates that this driver populates frontend1/demux1/dvr1 and then doesn't follow the way you describe (since the tuners can't be used at once).
I would like to hear from Steve on this point.

Quoted 34 lines · Christophe Thommeret

Le Thursday 11 September 2008 00:59:31 Andreas Oberritter, vous avez écrit :

Quoted 23 lines

Quoted 6 lines · Hans Werner

Quoted 4 lines

So applications could know that these 2 frontends are exclusive. That would not require any API change, but would have to be a rule followed by
all drivers.

Yes, if we keep to that rule then only frontends which can operate truly simultaneously should have a different adapter number.

An adapter refers to a self-contained piece of hardware, whose parts can not be used by a second adapter (e.g. adapter0/demux0 can not access the data from adapter1/frontend1). In a commonly used setup it means that adapter0 is the first initialized PCI card and adapter1 is the second.

Now, if you want a device with two tuners that can be accessed simultaneously to create a second adapter, then you would have to artificially divide its components so that it looks like two independant PCI cards. This might become very complicated and limits the functions of the hardware.

However, on a setup with multiple accessible tuners you can expect at least the same amount of accessible demux devices on the same adapter (and also dvr devices for that matter). There is an ioctl to connect a frontend to a specific demux (DMX_SET_SOURCE).

Quoted 5 lines

So, if there are demux0, frontend0 and frontend1, then the application knows that it can't use both frontends simultaneously. Otherwise, if there are demux0, demux1, frontend0 and frontend1, then it can use both of them (by using both demux devices and connecting them to the frontends via the ioctl mentioned above).

Sounds logical. And that's why Kaffeine search for frontend/demux/dvr > 0 and uses demux1 with frontend1. (That was just a guess since i've never seen neither any such devices nor comments/recommendations/rules about such case).

Quoted 9 lines

However, all dual tuners devices drivers i know expose the 2 frontends as frontend0 in separate adapters. But all these devices seems to be USB.

The fact that Kaffeine works with the experimental hvr4000 driver indicates that this driver populates frontend1/demux1/dvr1 and then doesn't follow the way you describe (since the tuners can't be used at once).
I would like to hear from Steve on this point.

Correct, frontend1, demux1, dvr1 etc. All on the same adapter. The driver and multi-frontend patches manage exclusive access to the single internal resource.

Hi,

Am Mittwoch, den 10.09.2008, 21:00 -0400 schrieb Steven Toth:

Quoted 43 lines

Quoted 42 lines · Christophe Thommeret

Le Thursday 11 September 2008 00:59:31 Andreas Oberritter, vous avez écrit :

Quoted 23 lines

Quoted 6 lines · Hans Werner

Quoted 4 lines

So applications could know that these 2 frontends are exclusive. That would not require any API change, but would have to be a rule followed by
all drivers.

Yes, if we keep to that rule then only frontends which can operate truly simultaneously should have a different adapter number.

An adapter refers to a self-contained piece of hardware, whose parts can not be used by a second adapter (e.g. adapter0/demux0 can not access the data from adapter1/frontend1). In a commonly used setup it means that adapter0 is the first initialized PCI card and adapter1 is the second.

Now, if you want a device with two tuners that can be accessed simultaneously to create a second adapter, then you would have to artificially divide its components so that it looks like two independant PCI cards. This might become very complicated and limits the functions of the hardware.

However, on a setup with multiple accessible tuners you can expect at least the same amount of accessible demux devices on the same adapter (and also dvr devices for that matter). There is an ioctl to connect a frontend to a specific demux (DMX_SET_SOURCE).

Quoted 5 lines

So, if there are demux0, frontend0 and frontend1, then the application knows that it can't use both frontends simultaneously. Otherwise, if there are demux0, demux1, frontend0 and frontend1, then it can use both of them (by using both demux devices and connecting them to the frontends via the ioctl mentioned above).

Sounds logical. And that's why Kaffeine search for frontend/demux/dvr > 0 and uses demux1 with frontend1. (That was just a guess since i've never seen neither any such devices nor comments/recommendations/rules about such case).

However, all dual tuners devices drivers i know expose the 2 frontends as frontend0 in separate adapters. But all these devices seems to be USB.

The fact that Kaffeine works with the experimental hvr4000 driver indicates that this driver populates frontend1/demux1/dvr1 and then doesn't follow the way you describe (since the tuners can't be used at once).
I would like to hear from Steve on this point.

Quoted 4 lines

Correct, frontend1, demux1, dvr1 etc. All on the same adapter. The driver and multi-frontend patches manage exclusive access to the single internal resource.

then please explain what is about the analog usage, which can always be first and don't tell it has to stay back, since you always sit on that bridge and else come nowhere ...

Quoted 46 lines · hermann pitton

Hi,

Am Mittwoch, den 10.09.2008, 21:00 -0400 schrieb Steven Toth:

Quoted 43 lines

Quoted 42 lines · Christophe Thommeret

Le Thursday 11 September 2008 00:59:31 Andreas Oberritter, vous avez écrit :

Quoted 23 lines

Quoted 6 lines · Hans Werner

Quoted 4 lines

So applications could know that these 2 frontends are exclusive. That would not require any API change, but would have to be a rule followed by
all drivers.

Yes, if we keep to that rule then only frontends which can operate truly simultaneously should have a different adapter number.

An adapter refers to a self-contained piece of hardware, whose parts can not be used by a second adapter (e.g. adapter0/demux0 can not access the data from adapter1/frontend1). In a commonly used setup it means that adapter0 is the first initialized PCI card and adapter1 is the second.

Now, if you want a device with two tuners that can be accessed simultaneously to create a second adapter, then you would have to artificially divide its components so that it looks like two independant PCI cards. This might become very complicated and limits the functions of the hardware.

However, on a setup with multiple accessible tuners you can expect at least the same amount of accessible demux devices on the same adapter (and also dvr devices for that matter). There is an ioctl to connect a frontend to a specific demux (DMX_SET_SOURCE).

Quoted 5 lines

So, if there are demux0, frontend0 and frontend1, then the application knows that it can't use both frontends simultaneously. Otherwise, if there are demux0, demux1, frontend0 and frontend1, then it can use both of them (by using both demux devices and connecting them to the frontends via the ioctl mentioned above).

Sounds logical. And that's why Kaffeine search for frontend/demux/dvr > 0 and uses demux1 with frontend1. (That was just a guess since i've never seen neither any such devices nor comments/recommendations/rules about such case).

However, all dual tuners devices drivers i know expose the 2 frontends as frontend0 in separate adapters. But all these devices seems to be USB.

The fact that Kaffeine works with the experimental hvr4000 driver indicates that this driver populates frontend1/demux1/dvr1 and then doesn't follow the way you describe (since the tuners can't be used at once).
I would like to hear from Steve on this point.

Quoted 8 lines

Quoted 4 lines

Correct, frontend1, demux1, dvr1 etc. All on the same adapter. The driver and multi-frontend patches manage exclusive access to the single internal resource.

then please explain what is about the analog usage, which can always be first and don't tell it has to stay back, since you always sit on that bridge and else come nowhere ...

Hermann, I'm not sure I understand your question, but I'll try.

This has nothing to do with analog, I never suggested these patches effected analog.

Either you're confused, or I am :)

The multifrontend patches are related to DVB only, the analog ports on the cx88 remain untouched, unchanged.

Am Mittwoch, den 10.09.2008, 22:59 -0400 schrieb Steven Toth:

Quoted 59 lines

Quoted 46 lines · hermann pitton

Hi,

Am Mittwoch, den 10.09.2008, 21:00 -0400 schrieb Steven Toth:

Quoted 43 lines

Quoted 42 lines · Christophe Thommeret

Le Thursday 11 September 2008 00:59:31 Andreas Oberritter, vous avez écrit :

Quoted 23 lines

Quoted 6 lines · Hans Werner

Quoted 4 lines

So applications could know that these 2 frontends are exclusive. That would not require any API change, but would have to be a rule followed by
all drivers.

Yes, if we keep to that rule then only frontends which can operate truly simultaneously should have a different adapter number.

An adapter refers to a self-contained piece of hardware, whose parts can not be used by a second adapter (e.g. adapter0/demux0 can not access the data from adapter1/frontend1). In a commonly used setup it means that adapter0 is the first initialized PCI card and adapter1 is the second.

Now, if you want a device with two tuners that can be accessed simultaneously to create a second adapter, then you would have to artificially divide its components so that it looks like two independant PCI cards. This might become very complicated and limits the functions of the hardware.

However, on a setup with multiple accessible tuners you can expect at least the same amount of accessible demux devices on the same adapter (and also dvr devices for that matter). There is an ioctl to connect a frontend to a specific demux (DMX_SET_SOURCE).

Quoted 5 lines

So, if there are demux0, frontend0 and frontend1, then the application knows that it can't use both frontends simultaneously. Otherwise, if there are demux0, demux1, frontend0 and frontend1, then it can use both of them (by using both demux devices and connecting them to the frontends via the ioctl mentioned above).

Sounds logical. And that's why Kaffeine search for frontend/demux/dvr > 0 and uses demux1 with frontend1. (That was just a guess since i've never seen neither any such devices nor comments/recommendations/rules about such case).

However, all dual tuners devices drivers i know expose the 2 frontends as frontend0 in separate adapters. But all these devices seems to be USB.

The fact that Kaffeine works with the experimental hvr4000 driver indicates that this driver populates frontend1/demux1/dvr1 and then doesn't follow the way you describe (since the tuners can't be used at once).
I would like to hear from Steve on this point.

Quoted 7 lines

Quoted 4 lines

Correct, frontend1, demux1, dvr1 etc. All on the same adapter. The driver and multi-frontend patches manage exclusive access to the single internal resource.

then please explain what is about the analog usage, which can always be first and don't tell it has to stay back, since you always sit on that bridge and else come nowhere ...

Hermann, I'm not sure I understand your question, but I'll try.

This has nothing to do with analog, I never suggested these patches effected analog.

Quoted 4 lines

Either you're confused, or I am :)

The multifrontend patches are related to DVB only, the analog ports on the cx88 remain untouched, unchanged.

Steve,

likely we should have all some sleep previously again.

But I'm quit sure what I'talking about.

If using the dma engines of the saa713x at once, you can't say analog and dvb are not related!

There are clear restrictions and you can cause major dammage ignoring them.

Quoted 65 lines · hermann pitton

Am Mittwoch, den 10.09.2008, 22:59 -0400 schrieb Steven Toth:

Quoted 63 lines

Quoted 46 lines · hermann pitton

Hi,

Am Mittwoch, den 10.09.2008, 21:00 -0400 schrieb Steven Toth:

Quoted 43 lines

Quoted 42 lines · Christophe Thommeret

Le Thursday 11 September 2008 00:59:31 Andreas Oberritter, vous avez écrit :

Quoted 23 lines

Quoted 6 lines · Hans Werner

Quoted 4 lines

So applications could know that these 2 frontends are exclusive. That would not require any API change, but would have to be a rule followed by
all drivers.

Yes, if we keep to that rule then only frontends which can operate truly simultaneously should have a different adapter number.

An adapter refers to a self-contained piece of hardware, whose parts can not be used by a second adapter (e.g. adapter0/demux0 can not access the data from adapter1/frontend1). In a commonly used setup it means that adapter0 is the first initialized PCI card and adapter1 is the second.

Now, if you want a device with two tuners that can be accessed simultaneously to create a second adapter, then you would have to artificially divide its components so that it looks like two independant PCI cards. This might become very complicated and limits the functions of the hardware.

However, on a setup with multiple accessible tuners you can expect at least the same amount of accessible demux devices on the same adapter (and also dvr devices for that matter). There is an ioctl to connect a frontend to a specific demux (DMX_SET_SOURCE).

Quoted 5 lines

So, if there are demux0, frontend0 and frontend1, then the application knows that it can't use both frontends simultaneously. Otherwise, if there are demux0, demux1, frontend0 and frontend1, then it can use both of them (by using both demux devices and connecting them to the frontends via the ioctl mentioned above).

Sounds logical. And that's why Kaffeine search for frontend/demux/dvr > 0 and uses demux1 with frontend1. (That was just a guess since i've never seen neither any such devices nor comments/recommendations/rules about such case).

However, all dual tuners devices drivers i know expose the 2 frontends as frontend0 in separate adapters. But all these devices seems to be USB.

The fact that Kaffeine works with the experimental hvr4000 driver indicates that this driver populates frontend1/demux1/dvr1 and then doesn't follow the way you describe (since the tuners can't be used at once).
I would like to hear from Steve on this point.

Quoted 7 lines

Quoted 4 lines

Correct, frontend1, demux1, dvr1 etc. All on the same adapter. The driver and multi-frontend patches manage exclusive access to the single internal resource.

then please explain what is about the analog usage, which can always be first and don't tell it has to stay back, since you always sit on that bridge and else come nowhere ...

Hermann, I'm not sure I understand your question, but I'll try.

This has nothing to do with analog, I never suggested these patches effected analog.

Either you're confused, or I am :)

The multifrontend patches are related to DVB only, the analog ports on the cx88 remain untouched, unchanged.

Quoted 3 lines

Steve,

likely we should have all some sleep previously again.

Hermann, I have problems trying to understand your written English, I do not always understand what you write. This leads to confusion.

Quoted 2 lines

But I'm quit sure what I'talking about.

Of course you do, I never suggested that you were not.

Quoted 3 lines

If using the dma engines of the saa713x at once, you can't say analog and dvb are not related!

Oh, I understand the topic you are mentioning now.

I have no experience with the 7134 and I'm not aware of it's hardware capabilities, or lack of. I'm not fit to comment on what resources can be shared and the implications of.

What I can say with confidence, is that if it has a digital transport port, and if some of the cards share this port with DVB-T and DVB-S then the multiple-frontend patches will probably help with those designs. Rather than having to specify DVB-T or DVB-S during module load time, the patches will negotiate user access and allow both to be present.

This may be a good feature for the 7134, it may not.

Quoted 2 lines

There are clear restrictions and you can cause major dammage ignoring them.

Nobody is ignoring them, thank you for raising the issue.

- Steve

Quoted 6 lines · Christophe Thommeret

Sounds logical. And that's why Kaffeine search for frontend/demux/dvr > 0 and uses demux1 with frontend1. (That was just a guess since i've never seen neither any such devices nor comments/recommendations/rules about such case).

However, all dual tuners devices drivers i know expose the 2 frontends as frontend0 in separate adapters. But all these devices seems to be USB.

Quoted 6 lines

The fact that Kaffeine works with the experimental hvr4000 drier indicates that this driver populates frontend1/demux1/dvr1 and then doesn't follow the way you describe (since the tuners can't be used at once).
I would like to hear from Steve on this point.

Correct, frontend1, demux1, dvr1 etc. All on the same adapter. The driver and multi-frontend patches manage exclusive access to the single internal resource.

From: Andreas Oberritter <[email protected]>
Subject: Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support
To: [email protected]
Date: Thursday, September 11, 2008, 7:22 AM

Quoted 2 lines · Steven Toth

Quoted 1 line · Christophe Thommeret

Sounds logical. And that's why Kaffeine search

for frontend/demux/dvr > 0 and

Quoted 1 line

Quoted 1 line

uses demux1 with frontend1. (That was just a guess

since i've never seen

Quoted 1 line

Quoted 1 line

neither any such devices nor

comments/recommendations/rules about such case).

Quoted 2 lines

Quoted 2 lines

However, all dual tuners devices drivers i know

expose the 2 frontends as

Quoted 1 line

Quoted 1 line

frontend0 in separate adapters. But all these

devices seems to be USB.

The way I described is used on dual and quad tuner Dreambox models.

Quoted 1 line

Quoted 1 line

The fact that Kaffeine works with the experimental

hvr4000 drier indicates

Quoted 1 line

Quoted 1 line

that this driver populates frontend1/demux1/dvr1

and then doesn't follow the

Quoted 1 line

Quoted 1 line

way you describe (since the tuners can't be

used at once).

Quoted 5 lines

Quoted 3 lines

I would like to hear from Steve on this point.

Correct, frontend1, demux1, dvr1 etc. All on the same

adapter. The

Quoted 1 line

driver and multi-frontend patches manage exclusive

access to the single

Quoted 1 line

internal resource.

How about dropping demux1 and dvr1 for this adapter, since they don't
create any benefit? IMHO the number of demux devices should always equal
the number of simultaneously usable transport stream inputs.

Regards,
Andreas

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

How about dropping demux1 and dvr1 for this adapter, since they don't create any benefit? IMHO the number of demux devices should always equal the number of simultaneously usable transport stream inputs.

Quoted 3 lines · Andreas Oberritter

How about dropping demux1 and dvr1 for this adapter, since they don't create any benefit? IMHO the number of demux devices should always equal the number of simultaneously usable transport stream inputs.

I like this `solution', but I'm not sure it is optimal...

Sure, it works for 2x devices, where only one at a time can be used, but if one has a hypothetical DVB-S(2) + DVB-C/T device, with two RF inputs, so that one could simultaneously use sat and one of cable/terrestrial, you'd get two demux devices, and three frontends, and you'd need to map the exclusivity of the cable/terrestrial frontend somehow.

From: Steven Toth <[email protected]>
Subject: Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support
To: "Christophe Thommeret" <[email protected]>
Cc: [email protected]
Date: Thursday, September 11, 2008, 4:00 AM

Quoted 1 line · Christophe Thommeret

Le Thursday 11 September 2008 00:59:31 Andreas

Oberritter, vous avez écrit :

Quoted 2 lines

Quoted 2 lines

Quoted 1 line · Hans Werner

Quoted 1 line

So applications could know that these 2

frontends are exclusive.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

That would not require any API change, but

would have to be a rule

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

followed by
all drivers.

Yes, if we keep to that rule then only

frontends which can operate truly

Quoted 1 line

Quoted 1 line

Quoted 1 line

simultaneously should have a different adapter

number.

Quoted 1 line

Quoted 1 line

An adapter refers to a self-contained piece of

hardware, whose parts can

Quoted 1 line

Quoted 1 line

not be used by a second adapter (e.g.

adapter0/demux0 can not access the

Quoted 1 line

Quoted 1 line

data from adapter1/frontend1). In a commonly used

setup it means that

Quoted 1 line

Quoted 1 line

adapter0 is the first initialized PCI card and

adapter1 is the second.

Quoted 2 lines

Quoted 2 lines

Now, if you want a device with two tuners that can

be accessed

Quoted 1 line

Quoted 1 line

simultaneously to create a second adapter, then

you would have to

Quoted 1 line

Quoted 1 line

artificially divide its components so that it

looks like two independant

Quoted 1 line

Quoted 1 line

PCI cards. This might become very complicated and

limits the functions

Quoted 3 lines

Quoted 3 lines

of the hardware.

However, on a setup with multiple accessible

tuners you can expect at

Quoted 1 line

Quoted 1 line

least the same amount of accessible demux devices

on the same adapter

Quoted 1 line

Quoted 1 line

(and also dvr devices for that matter). There is

an ioctl to connect a

Quoted 3 lines

Quoted 3 lines

frontend to a specific demux (DMX_SET_SOURCE).

So, if there are demux0, frontend0 and frontend1,

then the application

Quoted 1 line

Quoted 1 line

knows that it can't use both frontends

simultaneously. Otherwise, if

Quoted 1 line

Quoted 1 line

there are demux0, demux1, frontend0 and frontend1,

then it can use both

Quoted 1 line

Quoted 1 line

of them (by using both demux devices and

connecting them to the

Quoted 3 lines

Quoted 1 line

frontends via the ioctl mentioned above).

Sounds logical. And that's why Kaffeine search for

frontend/demux/dvr > 0 and

Quoted 1 line

uses demux1 with frontend1. (That was just a guess

since i've never seen

Quoted 1 line

neither any such devices nor

comments/recommendations/rules about such case).

Quoted 2 lines

However, all dual tuners devices drivers i know expose

the 2 frontends as

Quoted 1 line

frontend0 in separate adapters. But all these devices

seems to be USB.

Quoted 2 lines

The fact that Kaffeine works with the experimental

hvr4000 driver indicates

Quoted 1 line

that this driver populates frontend1/demux1/dvr1 and

then doesn't follow the

Quoted 1 line

way you describe (since the tuners can't be used

at once).

Quoted 3 lines

I would like to hear from Steve on this point.

Correct, frontend1, demux1, dvr1 etc. All on the same adapter. The
driver and multi-frontend patches manage exclusive access to the single
internal resource.

- Steve

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :

Quoted 4 lines

Quoted 1 line

Is this card able to deliver both S and T at the same time?

No, the hardware can do S/S2 or T.

The driver in the S2API tree only has S/S2 enabled (for the time being).

So, maybe we have to think a bit about how to add support for this kind of device.

I mean, if the driver provides different adapters/frontends (say adapter0/frontend0 and adapter1/frontend0), a typical application will see these as separate devices, and then when a user watch a S channel, the app assumes that the T frontend is free while in fact it's not.
For example, Kaffeine updates its channels list according to which channels can be viewed (based on which frontends are free). So, if you are recording a S channel, all channels on this freq are shown as available and all T channels are also shown as available. But in the HVR4000 case, it's false, since the T tuner isn't free.

Maybe a solution could be to have :
- adapter0/frontend0 -> S/S2 tuner
- adapter0/frontend1 -> T tuner

So applications could know that these 2 frontends are exclusive. That would not require any API change, but would have to be a rule followed by all drivers.