[linux-dvb] DVB-S2 / Multiproto and future modulation support

[linux-dvb] DVB-S2 / Multiproto and future modulation support

[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.

Acked-by: Patrick Boettcher <pb@linuxtv.org>
Acked-by: Michael Krufky <mkrufky@linuxtv.org>
Acked-by: Steven Toth <stoth@linuxtv.org>
Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>

* [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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Hans Werner]

-------- Original-Nachricht --------
> Datum: Fri, 29 Aug 2008 14:29:30 -0400
> Von: Steven Toth <stoth@linuxtv.org>
> An: linux-dvb <linux-dvb@linuxtv.org>
> 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 <pb@linuxtv.org>
> Acked-by: Michael Krufky <mkrufky@linuxtv.org>
> Acked-by: Steven Toth <stoth@linuxtv.org>
> Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
> 
> * [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
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Dear Steve, Michael, Patrick and Mauro,

wow! Let me be the first to congratulate all of you on taking a bold, decisive step, which
I am sure with your combined talents can be successful. I agree that it is time to move on
from the multiproto era and work to create something to be proud of. Your alternative approach
sounds intriguing. I will take some time to try and understand your patch before commenting
any further.

Best regards,
Hans

Acked-by: Hans Werner <hwerner4@gmx.de>


-- 
Release early, release often. Really, you should.

Psssst! Schon das coole Video vom GMX MultiMessenger gesehen?
Der Eine für Alle: http://www.gmx.net/de/go/messenger03

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[P. van Gaans]

On 08/29/2008 08:29 PM, 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
> 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 <pb@linuxtv.org>
> Acked-by: Michael Krufky <mkrufky@linuxtv.org>
> Acked-by: Steven Toth <stoth@linuxtv.org>
> Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
> 
> * [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
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
> 

It's pretty clear to me multiproto is likely never going to make it to 
the kernel. And the things you sum up here sound good. I haven't used 
multiproto much, and I understood some parts of it are a pain from 
dev-POV. And stuff that doesn't go in-kernel gets little support from 
applications.

Also, if we would NOT accept the solution you propose now, I see 
linux-DVB getting killed off altogether, more (other) developers working 
on multiproto and eventually the (atm messy) multiproto project (or some 
spinoff) going in-kernel, replacing linux-DVB.

That's radical. I'm not even sure that's possible. But I think it should 
be said it's an alternative.

Since you are the current linux-DVB developers and you support this new 
solution, I'll support you and am willing to abandon multiproto (haven't 
used it much anyway). On the other hand: if more people prefer 
multiproto and it grows seriously and goes in-kernel (after which 
enduser apps would start supporting it), I'll install that on my 
machine. In short, the most important thing to me, an enduser: I want a 
solution that for now brings me DVB-S2 and will later on be capable of 
supporting new standards.

For now, I am willing to support this new solution. Both because you 
support and, and because it sounds good. Being an ignorant enduser I 
can't judge much other things.

Acked-by: P. van Gaans (please no unsolicited bulk mail)

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Grégoire FAVRE]

Hello,

nice job :-)

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).

Thank.
-- 
Grégoire FAVRE
http://picasaweb.google.com/Gregoire.Favre
http://gregoire.favre.googlepages.com/
http://fr.wikipedia.org/wiki/N%C3%A9tiquette
http://en.wikipedia.org/wiki/Netiquette

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Christophe Thommeret]

Le Friday 29 August 2008 20:29:30 Steven Toth, vous avez écrit :
> 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.

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 <hftom@free.fr>

P.S.
1) imho, DTV_ prefix would make more sense.
2) if someone want to donate a S2 card ...

> Regards - Steve, Mike, Patrick and Mauro.
>
> Acked-by: Patrick Boettcher <pb@linuxtv.org>
> Acked-by: Michael Krufky <mkrufky@linuxtv.org>
> Acked-by: Steven Toth <stoth@linuxtv.org>
> Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
>
> * [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
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

-- 
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

>> 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 <hftom@free.fr>

Thanks.

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

I'll add this to the list as a discussion point.

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

Email me privately, let's talk - I have some spares :)

- Steve

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Oliver Endriss]

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
> 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 <pb@linuxtv.org>
> Acked-by: Michael Krufky <mkrufky@linuxtv.org>
> Acked-by: Steven Toth <stoth@linuxtv.org>
> Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
> 
> * [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.

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.

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.

Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Christian Tramnitz]

Steven Toth wrote:
> 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!


Best regards,
    Christian


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[ChaosMedia > WebDev]

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 <webdev@chaosmedia.org>



Steven Toth wrote:
> 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 <pb@linuxtv.org>
> Acked-by: Michael Krufky <mkrufky@linuxtv.org>
> Acked-by: Steven Toth <stoth@linuxtv.org>
> Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
>
> * [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
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>
>   

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Andreas Oberritter]

Steven Toth wrote:
> 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 <obi@linuxtv.org>

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.

+		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?

Regards,
Andreas

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

> 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.

Understood. Thank you for taking the time to review the approach and 
provide feedback.

Regards,

Steve

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Christian Tramnitz wrote:
> Steven Toth wrote:
>> 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!

Christian, thank you for your support.

We'll be working hard to get suport in all applications.

Regards,

Steve


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

ChaosMedia > WebDev wrote:
> 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.

Thank you, it was time to take a position and it's good to see many 
people supporting us now.

> 
> 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".

Agreed.

> 
> 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.

Agreed.

> 
> 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.

Great, please do.

> 
> 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.

Great, thanks.

> 
> Marc.
> 
> Acked-by: Marc Delcambre <webdev@chaosmedia.org>


Regards,

Steve

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Andreas Oberritter wrote:
> Steven Toth wrote:
>> 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 <obi@linuxtv.org>

Andreas, thank you for your support.

> 
> 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.
> 
> +		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?

I'm collecting all of the feedback, we have lots of comments and change 
suggests - but largely we're heading in a good direction.

You've pointed out some obvious missing pieces (the new s2 patch was 
written in 12 hours - so it hasn't had the time multiproto had to be 
developers), so we're going to have to fill in some missing pieces.

When the mailing list settles down I'm going to publish an email to all 
interested parties about all of the comments, and we can respond to each 
comment until we feels it's resolved.

Again, thank you for your support.

Regards,

Steve

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Artem Makhutov]

Hi,

On Fri, Aug 29, 2008 at 02:29:30PM -0400, 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
> 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.

2. Multiproto is not in kernel

Manu Abraham has just announced that multiproto can be merged:
http://www.linuxtv.org/pipermail/linux-dvb/2008-August/028351.html

I am using multiproto for some time now, and it works great.
It would be a waste of resources if you start a new project instead of
supporting multiproto.

Multiproto is ready, and can be merged in kernel NOW!
What we all want is support for new standards like DVB-S2.
Multiproto has accieved this. So why not using it?

Regards, Artem

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Artem Makhutov wrote:
> Hi,
> 
> On Fri, Aug 29, 2008 at 02:29:30PM -0400, 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
>> 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?


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.

Thanks your for your feedback.

Regards,

Steve



_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Janne Grunau]

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.
>
> 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.

> 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.

Acked-by: Janne Grunau <janne-dvb@grunau.be>

Janne

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Udo Richter]

Grégoire FAVRE wrote:
> 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).

There is none yet of course, but once the new API is ready, it might be 
less difficult to get VDR 1.7.0 running on the new API than it looks.

One could start with my dvb-api-wrapper patch for VDR 1.7.0. (Basically 
an userspace wrapper that translates multiproto calls into old API 
calls.) To get VDR running on the new API, only three multiproto API 
calls must be translated to the new API, and these are already isolated 
in separate functions ioctl_DVBFE_SET_DELSYS(), ioctl_DVBFE_SET_PARAMS() 
and ioctl_DVBFE_GET_DELSYS(). Without taking a too deep look into the 
new API, I think this should be possible without too much trouble.

This is of course a temporary solution, nothing final. Maybe, until 
things settle, its even a good idea to get VDR working on all three 
APIs, so people can use whatever works best for them.


Cheers,

Udo


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Goga777]

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 ?

Goga




_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Manu Abraham]

On Sat, Aug 30, 2008 at 7:14 PM, Steven Toth <stoth@linuxtv.org> wrote:
> Artem Makhutov wrote:
>> Hi,
>>
>> On Fri, Aug 29, 2008 at 02:29:30PM -0400, Steven Toth wrote:
>>> Regarding the multiproto situation:
>>>

>>
>> 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?

Adding a new modulation is just as good as adding in a new definition,
nothing more than that.

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

There is more than enough space in the enumeration for anything to be added.
Just adding more definitions without supported hardware is purely pointless.

> that isn't a forward looking future proof API.

The future doesn't lie in terms of some just basic modulation definitions alone.

> 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.

In fact in legacy mode, it is just as large as the existing API. In non-legacy
mode it is even still lighter. It's quite absurd to state that it is too big.

Also you need custom algorithm support for many of the newer demodulators
(Eg: stb0899 and others) which the existing API doesn't support. Well this
is also supported by the multiproto tree.


Manu

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Douglas Schilling Landgraf]

Hello,

On Fri, 29 Aug 2008 14:29:30 -0400
Steven Toth <stoth@linuxtv.org> wrote:

> 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 <pb@linuxtv.org>
> Acked-by: Michael Krufky <mkrufky@linuxtv.org>
> Acked-by: Steven Toth <stoth@linuxtv.org>
> Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>

Acked-by: Douglas Schilling Landgraf <dougsland@linuxtv.org>

Cheers,
Douglas

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Nicolas Will]

On Fri, 2008-08-29 at 14:29 -0400, 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
> 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 <pb@linuxtv.org>
> Acked-by: Michael Krufky <mkrufky@linuxtv.org>
> Acked-by: Steven Toth <stoth@linuxtv.org>
> Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>

Acked-by: Nicolas Will <nico@youplala.net>

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.

Nico


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Manu Abraham]

On Sat, Aug 30, 2008 at 7:08 PM, Artem Makhutov <artem@makhutov.org> wrote:
> Hi,
>
> On Fri, Aug 29, 2008 at 02:29:30PM -0400, 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
>> 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.

Let me clear this up. There isn't any binary incompatibility. If you
need the newer
modulations/delivery systems, then you need to recompile the application for the
newer systems. Binary compatibilty exists completely with the old API.
Even if you
add in newer delivery systems/modulations later (with the API update),
as the size
of the data structures do not change, there doesn't occur any binary
incompatibility

Regards,
Manu

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Janne Grunau wrote:
> 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.
>>
>> 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. 

Changing the namespace is a common message, I hear this a lot. This will 
  probably be one of the first things to change.

> 
> 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.

Johannes suggested we lose the fixed length approach and instead pass in 
struct containing the number of elements... I happen to like this, and 
it removed an unnecessary restriction.

So if 16 feels odd, we're soon not going to have any practical limit.


> 
>> 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.
> 
> Acked-by: Janne Grunau <janne-dvb@grunau.be>

Janne, thank you for your support.

Regards,

Steve

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Douglas Schilling Landgraf wrote:
> Hello,
> 
> On Fri, 29 Aug 2008 14:29:30 -0400
> Steven Toth <stoth@linuxtv.org> wrote:
> 
>> 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 <pb@linuxtv.org>
>> Acked-by: Michael Krufky <mkrufky@linuxtv.org>
>> Acked-by: Steven Toth <stoth@linuxtv.org>
>> Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
> 
> Acked-by: Douglas Schilling Landgraf <dougsland@linuxtv.org>

Douglas, thank you, your support is very much appreciated.

Regards,

Steve

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Nicolas Will wrote:
> On Fri, 2008-08-29 at 14:29 -0400, 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
>> 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 <pb@linuxtv.org>
>> Acked-by: Michael Krufky <mkrufky@linuxtv.org>
>> Acked-by: Steven Toth <stoth@linuxtv.org>
>> Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
> 
> Acked-by: Nicolas Will <nico@youplala.net>
> 
> I can't review code or provide any, but I have a server if needed.

Nico, understood. Thats for the offer.

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

... and many other people.

Thanks for your support.

Regards,

Steve

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Goga777 wrote:
> Hi, Steven
> 
> - if new api will be approve, who will update the drivers for stb0899 based cards ?


I suspect Manu has included the stb0899 driver in his recent pull 
request, which by definition will have his sign-off. So, people are free 
to derive new drivers form his work providing they follow his licensing 
rules.

I have one of those boards. Assuming the stb0899 TT-3200 drivers are GPL 
- and signed-off for release, if nobody else offers to do this then I will.

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

If the API is approved then HVR4000 support will also be included with 
that merge.

I don't know the stb0899 driver specifically so I can't say whether it 
would be part of the initial merge, but I would expect it to follow 
shortly afterwards.

Regards,

- Steve


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Charles Price]

> 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.


Acked-by: Charlie Price <cpwp@w3z.co.uk>

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Charles Price wrote:
>> 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.

Thanks Charles.

Regards,

Steve

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [vdr] DVB-S2 / Multiproto and future modulation support

[Johannes Stezenbach]

On Sat, Aug 30, 2008, Oliver Endriss wrote:
> Steven Toth wrote:
> > 
> > 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

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [vdr] DVB-S2 / Multiproto and future modulation support

[hermann pitton]

Hi,

Am Samstag, den 30.08.2008, 22:13 +0200 schrieb Johannes Stezenbach:
> On Sat, Aug 30, 2008, Oliver Endriss wrote:
> > Steven Toth wrote:
> > > 
> > > 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
> 

I might still be wrong, but since such stuff did get _very_ personal
sometimes, I still ask why.

Fact is, tell me lies, that potential and good people were running for
NDAs very hard that time and some did know this game already better than
others, who were giving the patch monkeys.

I still do say, that this whole mess we saw, is fully caused by kernel
rules and accepted as collateral damage.

Tell me, who did try to intercept these obviously colliding trains from
somewhere above and backed you to stop it?

Greetings,
Hermann







_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Markus Rechberger]

On Sat, Aug 30, 2008 at 8:03 PM, Steven Toth <stoth@linuxtv.org> wrote:
> Charles Price wrote:
>>> 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.

Markus

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Michael J. Curtis]

All

Firstly, I would like to thank ALL contributors for their time and effort so far in furthering the development of DVB-S2 on Linux, in particular the TT3200-S2 card

I will confirm that the Multiproto route has been a very frustrating experience for me over the two years, I think? that I have had this card!!

Each attempt to get this to work has introduced new and different 'challenges' and has frustrated my aim to have this work with MythTV

Any attempt to rationalize where we are now and publish attainable goals with support for mainstream applications will get my support

Kind regards

Michael Curtis

> -----Original Message-----
> From: linux-dvb-bounces@linuxtv.org [mailto:linux-dvb-
> bounces@linuxtv.org] On Behalf Of Markus Rechberger
> Sent: 31 August 2008 04:58
> To: Steven Toth; Linux Kernel Mailing List; Greg KH
> Cc: mrechberger@sundtek.com; linux-dvb@linuxtv.org
> Subject: Re: [linux-dvb] DVB-S2 / Multiproto and future modulation
> support
>
> On Sat, Aug 30, 2008 at 8:03 PM, Steven Toth <stoth@linuxtv.org> wrote:
> > Charles Price wrote:
> >>> 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.
>
> Markus
>
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> 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

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Jan Hoogenraad]

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.

Steven Toth wrote:
> 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.
> 



-- 
Jan Hoogenraad
Hoogenraad Interface Services
Postbus 2717
3500 GS Utrecht

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Igor M. Liplianin]

В сообщении от 29 August 2008 21:29:30 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.
>
> Acked-by: Patrick Boettcher <pb@linuxtv.org>
> Acked-by: Michael Krufky <mkrufky@linuxtv.org>
> Acked-by: Steven Toth <stoth@linuxtv.org>
> Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
>
> * [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
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

I am not much a letter writer.
So one way or another, DVB-S2 needs to be included.
Who makes first technical step? I mean working S2 driver in v4l-dvb tree.
I truly want to see that!

I see the problem like that - I have a card, I want it to work under Linux,
I don't see any reasons to wait for someone to make a driver (it is lasting 
for years, you know), I make it myself. Any political reasons?

So I am not asking you for technical help, although I'd like that too :)

BR
Igor

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Markus Rechberger wrote:
> On Sat, Aug 30, 2008 at 8:03 PM, Steven Toth <stoth@linuxtv.org> wrote:
>> Charles Price wrote:
>>>> 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.

I've learned never to expect anything different from you, such a pity.

Steve

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Jan Hoogenraad wrote:
> 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.

Sorry Jan, I don't maintain the documentation so I can't comment on that.

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

Understood.

Thanks anyway for taking the time to review and provide feedback.

Regards,

Steve


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Igor M. Liplianin wrote:
> В сообщении от 29 August 2008 21:29:30 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.
>>
>> Acked-by: Patrick Boettcher <pb@linuxtv.org>
>> Acked-by: Michael Krufky <mkrufky@linuxtv.org>
>> Acked-by: Steven Toth <stoth@linuxtv.org>
>> Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
>>
>> * [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
>> linux-dvb@linuxtv.org
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
> 
> I am not much a letter writer.
> So one way or another, DVB-S2 needs to be included.
> Who makes first technical step? I mean working S2 driver in v4l-dvb tree.
> I truly want to see that!
> 
> I see the problem like that - I have a card, I want it to work under Linux,
> I don't see any reasons to wait for someone to make a driver (it is lasting 
> for years, you know), I make it myself. Any political reasons?

Is this the HVR4000 driver that I wrote in 2006 (still not in the 
kernel)? I feel your pain.

Thanks for your feedback Igor.

Regards,

Steve


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[VDR User]

After some consideration, I can not ack this new api proposal.  I
believe a lot of the support for it is based in people not knowing the
current state of multiproto and thinking this might be the only path
to new needed drivers.  It hasn't helped that there has been some
misinformation spread such as the binary compatibility and so on.
There is a current pull request for multiproto right now and if done,
drivers could start being developed right now.  In the end that's what
matters to users, especially those of us who've been patiently waiting
several months or even years.

To my knowledge the multiproto api is very robust and can be easily
updated to accommodate new modulations, etc. From a technical
standpoint, I can't justify disregarding all the work thats been done
on multiproto, especially when it's finally ready to go.  In Mauro's
own response to the pull request, he admits the multiproto code is
complete.  Unless someone can provide legitimate reasons why we should
wait for yet another api to be written when multiproto is (finally)
ready to be pulled now, I'm afraid I can't support the idea.

People have been waiting to move forward with a new api for a long
time and it seems we can with multiproto right now, today.  I don't
agree that makes a very strong case of too little, too late.  Whether
it's openly admitted or not, I think we're mostly all aware that there
is some personal politics involved in this as well, which is
unfortunate.  Hopefully people will be mature enough to put that aside
and do what's best for us, the linux dvb user base, as a whole.  After
learning that multiproto is ready and there's no technical reason
against it, I wonder how many people still choose to wait for another
api to be written..?

Best regards guys!

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Jelle De Loecker]

[-- Attachment #1.1: Type: text/plain, Size: 2039 bytes --]

You said everything that needed to be said, I agree with you 100 %

I vote for the merging of multiproto.

/Met vriendelijke groeten,/

*Jelle De Loecker*
Kipdola Studios - Tomberg


VDR User schreef:
> After some consideration, I can not ack this new api proposal.  I
> believe a lot of the support for it is based in people not knowing the
> current state of multiproto and thinking this might be the only path
> to new needed drivers.  It hasn't helped that there has been some
> misinformation spread such as the binary compatibility and so on.
> There is a current pull request for multiproto right now and if done,
> drivers could start being developed right now.  In the end that's what
> matters to users, especially those of us who've been patiently waiting
> several months or even years.
>
> To my knowledge the multiproto api is very robust and can be easily
> updated to accommodate new modulations, etc. From a technical
> standpoint, I can't justify disregarding all the work thats been done
> on multiproto, especially when it's finally ready to go.  In Mauro's
> own response to the pull request, he admits the multiproto code is
> complete.  Unless someone can provide legitimate reasons why we should
> wait for yet another api to be written when multiproto is (finally)
> ready to be pulled now, I'm afraid I can't support the idea.
>
> People have been waiting to move forward with a new api for a long
> time and it seems we can with multiproto right now, today.  I don't
> agree that makes a very strong case of too little, too late.  Whether
> it's openly admitted or not, I think we're mostly all aware that there
> is some personal politics involved in this as well, which is
> unfortunate.  Hopefully people will be mature enough to put that aside
> and do what's best for us, the linux dvb user base, as a whole.  After
> learning that multiproto is ready and there's no technical reason
> against it, I wonder how many people still choose to wait for another
> api to be written..?
>
> Best regards guys!
>   

[-- Attachment #1.2: Type: text/html, Size: 2444 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Mauro Carvalho Chehab]

Hi all,

Thanks for your feedback.

All of us are waiting for a long time for support for the new DTV standards.

The idea is not to postpone it, but to be sure that the API changes will be
flexible enough. Once an API change goes to kernel, It may take a large amount
of time for it to be removed. So extra care is taken on patches adding a
new kernel to userspace API.

I dunno if you are aware of how kernel development cycles are. 

There is a short period of 2 weeks for merging API changes and driver
improvements. This starts when a new kernel is released. After that 2 weeks
period, a bug fix period starts. We are currently under bug fix period for
kernel 2.6.27, at release candidate 5 (-rc5).

So, the minimum Kernel release that we may expect to add support for other
protocols is 2.6.28.

In general, a kernel bug fix cycle goes up to -rc8 or -rc9, being one rc
release by week. So, 2.6.27 kernel is likely to be released sometime after the
end of Plumbers conf. 

So, there's no gain of merging the API changes and the corresponding DVB-S2
drivers now.

Since several active Linuxtv maintainers will be at the conf for the Video
Input Infrastructure Miniconf, this will give us a perfect opportunity for
working together, carefully examining the technical details of both proposals,
and finish whatever is needed for the addition of API changes as soon as
possible and submit feedbacks to the ML.

So, it is very likely that we'll add support for those protocols for 2.6.28
inclusion.

Thanks,
Mauro.


On Mon, 01 Sep 2008 19:24:10 +0200
Jelle De Loecker <skerit@kipdola.com> wrote:

> You said everything that needed to be said, I agree with you 100 %
> 
> I vote for the merging of multiproto.


> 
> /Met vriendelijke groeten,/
> 
> *Jelle De Loecker*
> Kipdola Studios - Tomberg
> 
> 
> VDR User schreef:
> > After some consideration, I can not ack this new api proposal.  I
> > believe a lot of the support for it is based in people not knowing the
> > current state of multiproto and thinking this might be the only path
> > to new needed drivers.  It hasn't helped that there has been some
> > misinformation spread such as the binary compatibility and so on.
> > There is a current pull request for multiproto right now and if done,
> > drivers could start being developed right now.  In the end that's what
> > matters to users, especially those of us who've been patiently waiting
> > several months or even years.
> >
> > To my knowledge the multiproto api is very robust and can be easily
> > updated to accommodate new modulations, etc. From a technical
> > standpoint, I can't justify disregarding all the work thats been done
> > on multiproto, especially when it's finally ready to go.  In Mauro's
> > own response to the pull request, he admits the multiproto code is
> > complete.  Unless someone can provide legitimate reasons why we should
> > wait for yet another api to be written when multiproto is (finally)
> > ready to be pulled now, I'm afraid I can't support the idea.
> >
> > People have been waiting to move forward with a new api for a long
> > time and it seems we can with multiproto right now, today.  I don't
> > agree that makes a very strong case of too little, too late.  Whether
> > it's openly admitted or not, I think we're mostly all aware that there
> > is some personal politics involved in this as well, which is
> > unfortunate.  Hopefully people will be mature enough to put that aside
> > and do what's best for us, the linux dvb user base, as a whole.  After
> > learning that multiproto is ready and there's no technical reason
> > against it, I wonder how many people still choose to wait for another
> > api to be written..?
> >
> > Best regards guys!
> >   


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Mauro Carvalho Chehab]

On Mon, 1 Sep 2008 09:38:40 -0700
"VDR User" <user.vdr@gmail.com> wrote:

> In Mauro's own response to the pull request, he admits the multiproto code is
> complete.

Sorry, it seems that you misunderstood me. I meant to say that multiproto code
is more mature, since it is being under development for a long time. I didn't
have time yet to review the code changes introduced by the latest version. I'm
planning to do such revision carefully during my trip.

Thanks,
Mauro

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Hans Verkuil]

Hi Steve,

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
> 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.

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.

> 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 <pb@linuxtv.org>
> Acked-by: Michael Krufky <mkrufky@linuxtv.org>
> Acked-by: Steven Toth <stoth@linuxtv.org>
> Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
> 
> * [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 <hverkuil@xs4all.nl>

Regards,

	Hans

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Hans Verkuil wrote:
> Hi Steve,
> 
> 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
>> 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.
> 
> 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.


yes, another developer also suggested this. It would be good to 
implement simmilar ideas - especially then they are already well 
established.


> 
> 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.

Interesting.

> 
> 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?

I've been thinking about this a lot and I'm leaning away from making the 
  sequence atomic, partly for the issue you raised and partly because 
when I tried to find concrete use cases where this was required I only 
came up with a few.

I want to explore this more, after I've published all of the feedback.

> 
> 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.

The 16 limit is going to be removed in favor of a more flexible (and 
traditional approach). A complete set of set's or get's is interesting. 
Let me see if I can find a use-case where we'd mix the two... if not 
then I agree with this, and it would simplify things even further.

We'll explore this more.

> 
> 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.

Yes.

> 
>> 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 <pb@linuxtv.org>
>> Acked-by: Michael Krufky <mkrufky@linuxtv.org>
>> Acked-by: Steven Toth <stoth@linuxtv.org>
>> Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
>>
>> * [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 <hverkuil@xs4all.nl>

Hans, thanks for your support and feedback.

Regards,

Steve


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Aidan Thornton]

On Sun, Aug 31, 2008 at 5:21 AM, Greg KH <greg@kroah.com> wrote:
> On Sun, Aug 31, 2008 at 05:57:46AM +0200, Markus Rechberger wrote:
>> 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 '-' :)
>
>> 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

Hi,

Markus submitted a patch to the firmware loader code that fixed a
sysfs filename collision by appending a suffix to the sysfs filename
it used. This bug broke the use of the firmware loader from i2c device
drivers (specifically, the drivers for the xc3028 TV tuner chip) with
certain (not particularly unusual) kernel configurations - IIRC, it
affected kernels with I2C compiled as a module and a particular value
of some option related to sysfs depreciated support. The patch was
reverted by you because it broke binary-only firmware upload tools for
Dell hardware, screwing over normal desktop users in the process.

See, for example, http://lkml.org/lkml/2008/4/26/319 - this is fairly
typical. IIRC, the only drivers for the xc3028 that aren't affected
are Markus' recent ones, since they compile the firmware into the
driver (ugh). This may have been fixed since, but I'm not sure.

(Incidentally, looking at the conversation, I believe your remark that
"the i2c devices can fix things by changing their module names so this
collision doesn't happen :)" may be inaccurate. The firmware loader
copies the name it uses from the device passed to it, so I'm not sure
how much can be done, short of hacking around the issue by creating a
fake device to pass to the firmware loader or making potentially
compatibility-breaking changes to either the i2c core or the firmware
loader. Of course, I haven't looked at the issue that closely, so I
may be wrong.)

Aidan

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Christophe Thommeret]

Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :
> > 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.


-- 
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Janne Grunau]

On Wednesday 10 September 2008 17:10:19 Christophe Thommeret wrote:
> Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :
> > > 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.

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.

Janne

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Hans Werner]

-------- Original-Nachricht --------
> Datum: Wed, 10 Sep 2008 17:10:19 +0200
> Von: Christophe Thommeret <hftom@free.fr>
> An: Steven Toth <stoth@hauppauge.com>
> CC: linux-dvb@linuxtv.org
> Betreff: Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

> Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :
> > > 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.

> 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

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.

> 
> 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.

Regards,
Hans
-- 
Release early, release often.

Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Christophe Thommeret wrote:
> Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :
>>> 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.

This is already in progress, based on some work I did on the HVR3000 
bus-sharing changes a couple of years ago 
(http://linuxtv.org/hg/~stoth/hvr3000). People are interested in seeing 
this merged. Darron Board took the patches a long time ago and has been 
maintaining them. (Thank you)

What does this mean? Well, this is what it looks like to the applications:

/dev/dvb/adapter0/frontend0 DVB-S
/dev/dvb/adapter0/frontend1 DVB-T

I floated these patches in the linux-dvb mailing list a long time ago 
and the general feeling was of support for this approach.

I'm told myth already supports this. If anyone has experience running an 
HVR3000 with both DVB-T and DVB-T on Myth then I'd welcome their 
feedback here.


> 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

Correct, this : http://linuxtv.org/hg/~stoth/hvr3000/rev/3f78be7007f6

Quoting the original patch description:

"Multiple frontends on a single adapter support.

From: Steven Toth <stoth@hauppauge.com>

These patches are for review only.

The WinTV-HVR3000 has a single transport bus which is shared between
a DVB-T and DVB-S modulator. These patches build on the bus acquisition
cx88 work from a few weeks ago to add support for this.

So to applications the HVR3000 looks like this:
/dev/dvb/adapter0/fe0 (cx24123 DVB-S demod)
/dev/dvb/adapter0/fe1 (cx22702 DVB-T demod)

Additional boards continue as before, eg:
/dev/dvb/adapter1/fe0 (lgdt3302 ATSC demod)

The basic change is removing the single instance of the videobuf_dvb in
cx8802_dev and saa7134_dev(?) and replacing it with a list and some
supporting functions.

*NOTE* This branch was taken before v4l-dvb was closed for 2.6.19 so
two or three current cx88 patches appear to be reversed by this tree,
this will be cleaned up in the near future. The patches missing change
the mutex handing to core->lock, fix an enumeration problem.

For Review: The best place to start reviewing this patch
is videobuf_dvb. These core structures and functions are then implemented
in cx88 and (partially in) saa7134.

Signed-off-by: Steven Toth <stoth@hauppauge.com>"



> 
> 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.
> 
> 

This would be a nice addition to the S2API tree. I'll collect the new 
patches and present another patchset for review.

S2API is shaping up nicely, we just have to make sure we don't overload 
the tree and lose sight of the basic goal.

- Steve



_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Janne Grunau wrote:
> On Wednesday 10 September 2008 17:10:19 Christophe Thommeret wrote:
>> Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :
>>>> 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.
> 
> 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.

> 
> 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.

> 
> 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.

- Steve


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Hans Werner wrote:
> -------- Original-Nachricht --------
>> Datum: Wed, 10 Sep 2008 17:10:19 +0200
>> Von: Christophe Thommeret <hftom@free.fr>
>> An: Steven Toth <stoth@hauppauge.com>
>> CC: linux-dvb@linuxtv.org
>> Betreff: Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support
> 
>> Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :
>>>> 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.
> 
>> 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
> 
> 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.
> 
>> 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.

- Steve






_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] Multiple frontends on a single adapter support. (Was: Re: DVB-S2 / Multiproto and future modulation support)

[Christophe Thommeret]

Le Wednesday 10 September 2008 20:47:03 Steven Toth, vous avez écrit :
> Hans Werner wrote:
> > -------- Original-Nachricht --------
> >
> >> Datum: Wed, 10 Sep 2008 17:10:19 +0200
> >> Von: Christophe Thommeret <hftom@free.fr>
> >> An: Steven Toth <stoth@hauppauge.com>
> >> CC: linux-dvb@linuxtv.org
> >> Betreff: Re: [linux-dvb] DVB-S2 / Multiproto and future modulation
> >> support
> >>
> >> Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :
> >>>> 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.
> >
> >> 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
> >
> > 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.
> >
> >> 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.

Well, i guess i should have modified the subject, since it's not directly 
related to S2API.
Do not spend your time on this at that moment, S2API has the priority.

I just wanted to get feedback about this solution, since it does not involve 
any API change but only requires devs approval to follow this rule.


-- 
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[hermann pitton]

Hi Steve,

Am Mittwoch, den 10.09.2008, 14:39 -0400 schrieb Steven Toth:
> Janne Grunau wrote:
> > On Wednesday 10 September 2008 17:10:19 Christophe Thommeret wrote:
> >> Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :
> >>>> 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.
> > 
> > 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.
> 
> > 
> > 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.
> 
> > 
> > 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).

just a note on it.

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

All efforts are welcome. 

It is sad, that it needed that step to come up with new solutions,
whereas multiproto could be in the kernel since long, but only now is
allowed to be there the first time.

We have again forced competition instead of cooperation and I don't like
such, but I know you had no other choice. I'm still naive enough to hope
to rescue as much as possible from both efforts ...

For that 6-in-1 one on the saa7134, since it has two different PCI
bridges on that special PCI slot, it are in fact only two 3-in-1, except
for the shared LNB supply with its issues for the second DVB-S device,
it is really fairly simple to handle.

You just have to choose what you like to have, two DVB-S, two DVB-T
frontends or a mix of it and that is all and kaffeine will deal with it.

The only real danger is analog inputs if DVB uses already the dma
engines. Only packed formats can come through then, planar can really
cause corruption and there is no protection against it.

In the current poor, but fully usable shape, on DVB-T and DVB-S you can
do nothing wrong and just use a workaround, loading a compatible DVB-T
card, to get all possible usage conditions.

It has a manual switch for the two tda8275ac1 hybrid tuners, so you
decide, if you want DVB-T or analog RF loopthrough to both or feed a
different signal on the second.

The enabled DVB-S loopthrough can be used on an external receiver,
if wanted.

It is simpler then on m$ stuff, since fully transparent and totally safe
and fully functional, except for switching to 13Volts on the second LNB,
but they seem to have given up on it on vista too.

Cheers,
Hermann









_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Andreas Oberritter]

Hans Werner wrote:
>> 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).

Regards,
Andreas

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Christophe Thommeret]

Le Thursday 11 September 2008 00:59:31 Andreas Oberritter, vous avez écrit :
> Hans Werner wrote:
> >> 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).

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.


-- 
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Christophe Thommeret wrote:
> Le Thursday 11 September 2008 00:59:31 Andreas Oberritter, vous avez écrit :
>> Hans Werner wrote:
>>>> 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).
> 
> 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.
> 
> 

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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[hermann pitton]

Hi,

Am Mittwoch, den 10.09.2008, 21:00 -0400 schrieb Steven Toth:
> Christophe Thommeret wrote:
> > Le Thursday 11 September 2008 00:59:31 Andreas Oberritter, vous avez écrit :
> >> Hans Werner wrote:
> >>>> 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).
> > 
> > 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.
> > 
> > 
> 
> 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 ...

Cheers,
Hermann







_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

hermann pitton wrote:
> Hi,
> 
> Am Mittwoch, den 10.09.2008, 21:00 -0400 schrieb Steven Toth:
>> Christophe Thommeret wrote:
>>> Le Thursday 11 September 2008 00:59:31 Andreas Oberritter, vous avez écrit :
>>>> Hans Werner wrote:
>>>>>> 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).
>>> 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.
>>>
>>>
>> 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.

- Steve



_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[hermann pitton]

Am Mittwoch, den 10.09.2008, 22:59 -0400 schrieb Steven Toth:
> hermann pitton wrote:
> > Hi,
> > 
> > Am Mittwoch, den 10.09.2008, 21:00 -0400 schrieb Steven Toth:
> >> Christophe Thommeret wrote:
> >>> Le Thursday 11 September 2008 00:59:31 Andreas Oberritter, vous avez écrit :
> >>>> Hans Werner wrote:
> >>>>>> 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).
> >>> 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.
> >>>
> >>>
> >> 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.

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.

Cheers,
Hermann





_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Andreas Oberritter]

Steven Toth wrote:
> Christophe Thommeret wrote:
>> 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 way I described is used on dual and quad tuner Dreambox models.

>> 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.

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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Uri Shkolnik]

--- On Thu, 9/11/08, Andreas Oberritter <obi@linuxtv.org> wrote:

> From: Andreas Oberritter <obi@linuxtv.org>
> Subject: Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support
> To: linux-dvb@linuxtv.org
> Date: Thursday, September 11, 2008, 7:22 AM
> Steven Toth wrote:
> > Christophe Thommeret wrote:
> >> 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 way I described is used on dual and quad tuner Dreambox
> models.
> 
> >> 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.
> 
> 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
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

My input for this -

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.). 

Those hardware devices can use various bus interfaces - SDIO, USB, SPI, TS, I2C, HIF.....


Uri Shkolnik
Software Architect
Siano Mobile Silicon


      

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Uri Shkolnik]

--- On Thu, 9/11/08, Steven Toth <stoth@linuxtv.org> wrote:

> From: Steven Toth <stoth@linuxtv.org>
> Subject: Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support
> To: "Christophe Thommeret" <hftom@free.fr>
> Cc: linux-dvb@linuxtv.org
> Date: Thursday, September 11, 2008, 4:00 AM
> Christophe Thommeret wrote:
> > Le Thursday 11 September 2008 00:59:31 Andreas
> Oberritter, vous avez écrit :
> >> Hans Werner wrote:
> >>>> 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).
> > 
> > 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.
> > 
> > 
> 
> 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
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

I wrote about it in a previous post, it's not always so. What about diversity (two frontends, single demux (or non if it's not TS based content)?


      

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

hermann pitton wrote:
> Am Mittwoch, den 10.09.2008, 22:59 -0400 schrieb Steven Toth:
>> hermann pitton wrote:
>>> Hi,
>>>
>>> Am Mittwoch, den 10.09.2008, 21:00 -0400 schrieb Steven Toth:
>>>> Christophe Thommeret wrote:
>>>>> Le Thursday 11 September 2008 00:59:31 Andreas Oberritter, vous avez écrit :
>>>>>> Hans Werner wrote:
>>>>>>>> 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).
>>>>> 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.
>>>>>
>>>>>
>>>> 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.
> 
> 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.

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

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

> 
> 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.

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

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

- Steve



_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] Multiple frontends on a single adapter support

[Christophe Thommeret]

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?


-- 
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[barry bouwsma]

--- On Thu, 9/11/08, Andreas Oberritter <obi@linuxtv.org> wrote:

> 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.

The `problem' I see with the separate adapters, is that, should
my dream PCI card with 2xSat, 2xDVB-T(2), and 2xDVB-C ever
materialise (and obsolete analogue), I'd need 6 /dev/dvb/adapter
entries, coming close to the current #define of 8.

My `production' machine has reached its limit of 4, and I'm
cautiously considering upgrading parts of it, not yet sure if
that limit is thanks to device minor numbers or what, but then,
its hardware capacity is almost reached with three USB DVB
devices.  (A quick test on my current kernel revealed that minor
numbers isn't a problem nowadays)


thanks,
barry bouwsma


      


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Multiple frontends on a single adapter support

[Uri Shkolnik]

--- On Thu, 9/11/08, Christophe Thommeret <hftom@free.fr> wrote:

> From: Christophe Thommeret <hftom@free.fr>
> Subject: [linux-dvb] Multiple frontends on a single adapter support
> To: linux-dvb@linuxtv.org
> 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?
> 

Take CMMB for example, some standard's options are that the content is RTP based, so the content path is via the IP stack, another CMMB mode is Mpeg4 frames. 
DAB (and DAB-IP) are other good examples.

By demux.h ( http://www.linuxtv.org/cgi-bin/viewcvs.cgi/dvb-kernel-v4/linux/include/linux/dvb/demux.h?view=markup ) demux is "de-multiplexing of a transport stream (TS)", since those standards are not TS based, they can not be "demuxed". If its an IP-based DTV standard, you just create a pipe from the device into the IP stack and pass all content. If it a frames based standards, you need other mechanism, anyway, you don't need a demux 

> 
> -- 
> Christophe Thommeret
> 
> 
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb


      

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Andreas Oberritter]

barry bouwsma wrote:
> --- On Thu, 9/11/08, Andreas Oberritter <obi@linuxtv.org> wrote:
> 
>> 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.

That's indeed a case where you can not easily determine how many inputs
can be handled at the same time. This might require another enhancement
of the userland API. Until then, for such a small number of frontends,
an application could simply try out which combination of frontends can
be used at the same time (either open() or DMX_SET_SOURCE would fail if
you try to use the mentioned -C and -T at the same time).

Regards,
Andreas

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Multiple frontends on a single adapter support

[Steven Toth]

> 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?) ?

Could it, yes. I'll go with the majority on this to be honest.

As far as I'm concerned the hvr3000 patches (if you read the patch 
description) were not to be merged as-is, they were for discussion and 
review. It's encouraging good to see that discussion happening now, 
later than expect, but good.

The inodes largely reflect API usage so it needs to be obvious, if we 
think this isn't, then we should come to a consensus and resolve for the 
future.

Obviously, the impact would be that existing applications that are using 
unofficial patches would have to be patched again, away from the current 
approach.

- Steve



_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[hermann pitton]

Am Donnerstag, den 11.09.2008, 08:51 -0400 schrieb Steven Toth:
> hermann pitton wrote:
> > Am Mittwoch, den 10.09.2008, 22:59 -0400 schrieb Steven Toth:
> >> hermann pitton wrote:
> >>> Hi,
> >>>
> >>> Am Mittwoch, den 10.09.2008, 21:00 -0400 schrieb Steven Toth:
> >>>> Christophe Thommeret wrote:
> >>>>> Le Thursday 11 September 2008 00:59:31 Andreas Oberritter, vous avez écrit :
> >>>>>> Hans Werner wrote:
> >>>>>>>> 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).
> >>>>> 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.
> >>>>>
> >>>>>
> >>>> 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.
> > 
> > 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.

Sorry, let me know if you have any further question about the Medion
Quad or any other multiple frontend device on the saa7134 and I try to
answer it taking more care on my English.

> > 
> > But I'm quit sure what I'talking about.
> 
> Of course you do, I never suggested that you were not.
> 
> > 
> > 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.

Yes, for sure it will be and no additional problems with dma throughput
will appear. If kaffeine knows what to do and keeps the same usability
as it is discussed.
 
> > There are clear restrictions and you can cause major dammage ignoring
> > them.
> 
> Nobody is ignoring them, thank you for raising the issue.
> 
> - Steve
> 

Hopefully you have lots of testers and contributors and I will be one of
them as soon I find time. I did test the latest multiproto so far
without issues.

The point I try to raise for your testers is to keep in mind, on the
saa7134 they can use analog inputs from tuners or external sources with
DVB-T/S at once, but only if the analog feed is using packed formats.

For example mplayer/mencoder uses a planar format by default.
This will lead to a corrupted recorded file and in worst case to file
system corruption, if used with DVB at once.

Hartmut considered once to disable all planar formats because of that, 
but we don't have a solution yet and people should be aware.

Means also, if a capture in a planar format is already running for
analog inputs, no DVB will come through.

There is no priority handling, notification or anything yet and I just
point to it again.

Cheers,
Hermann




_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb