Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Manu Abraham]

Manu Abraham wrote:
> frankio wrote:
>> Manu Abraham wrote:
>>> Francesco Schiavarelli wrote:
>>>  
 Johannes Stezenbach wrote:

> On Sat, Nov 03, 2007, Manu Abraham wrote:
>  
>> If you see H.2 and H.3, the difference is between CCM and VCM
>> (Note: that both are cases of multiple "TS's")
>>
>> H.2 (CCM) is applicable for DVB-T muxes. Here there is a HP/LP stream
>> selection in some fashion combined with the merger/slicer where
>> stream id is used. 
> What makes you think there is HP/LP involved? All H.2 says
> is that two DVB-T streams are transmitted using one
> DVB-S2 transponder to a DVB-T transmitter. The DVB-T transmitter
> could then transmit them on two different frequencies in
> non-hierarchical mode.
>
> (Indeed H.2 says "two DTT MUXes at 24 Mbit/s each" indicating
> they are not hierarchical because you can't get that
> bitrate in DVB-T hierarchical mode. But even if it were DVB-T
> hierarchical mode it has nothing to do with DVB-S2 backwards
> compatible mode hierarchical modulation.)
>
>   
 I agree with you, Johannes.
 There is no evidence of hierarchical modulation, nevertheless the two
 streams I was looking at had the same channel protection that is no
 HP/LP, and I was told it was DVB-S2 CCM.

 When the transponder will be up again I'll be able to do more tests.
 
>>> Yeah, looks more like that, will have a patch soon to do some tests
>>> for it.
>>> STM's comments confirm that.
>>>
>>> Manu
>>>
>>>   
>> Now the beam is up on 13.0E 11373 H 27500 8PSK 2/3
>> It is made up of 2 DTT muxes (no HP/LP)
>> ISI1   16QAM 1/2 1/49.953 Mbps
>> ISI2   64QAM 5/6 1/424.882 Mbps
>>
>> Unfortunately I don't  know how long it will last, so let the tests
>> begin! :-)
>> I'll wait for the patch.
>>
> 
> In the meantime, can you please pull a copy of the multiproto tree
> http://jusst.de/hg/multiproto/
> 

Just try whether you can acquire a lock.

> and try to parse the S2 satellite delivery system descriptor ?
> dvbsnoop, or even libucsi will be able to do this.
>

Was too fast about this one. :-(

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 API vs. HVR4000: When?

[Manu Abraham]

frankio wrote:
> Manu Abraham wrote:
>> Francesco Schiavarelli wrote:
>>  
>>> Johannes Stezenbach wrote:
>>>
 On Sat, Nov 03, 2007, Manu Abraham wrote:
  
> If you see H.2 and H.3, the difference is between CCM and VCM
> (Note: that both are cases of multiple "TS's")
>
> H.2 (CCM) is applicable for DVB-T muxes. Here there is a HP/LP stream
> selection in some fashion combined with the merger/slicer where
> stream id is used. 
 What makes you think there is HP/LP involved? All H.2 says
 is that two DVB-T streams are transmitted using one
 DVB-S2 transponder to a DVB-T transmitter. The DVB-T transmitter
 could then transmit them on two different frequencies in
 non-hierarchical mode.

 (Indeed H.2 says "two DTT MUXes at 24 Mbit/s each" indicating
 they are not hierarchical because you can't get that
 bitrate in DVB-T hierarchical mode. But even if it were DVB-T
 hierarchical mode it has nothing to do with DVB-S2 backwards
 compatible mode hierarchical modulation.)

   
>>> I agree with you, Johannes.
>>> There is no evidence of hierarchical modulation, nevertheless the two
>>> streams I was looking at had the same channel protection that is no
>>> HP/LP, and I was told it was DVB-S2 CCM.
>>>
>>> When the transponder will be up again I'll be able to do more tests.
>>> 
>>
>> Yeah, looks more like that, will have a patch soon to do some tests
>> for it.
>> STM's comments confirm that.
>>
>> Manu
>>
>>   
> Now the beam is up on 13.0E 11373 H 27500 8PSK 2/3
> It is made up of 2 DTT muxes (no HP/LP)
> ISI1   16QAM 1/2 1/49.953 Mbps
> ISI2   64QAM 5/6 1/424.882 Mbps
> 
> Unfortunately I don't  know how long it will last, so let the tests
> begin! :-)
> I'll wait for the patch.
>

In the meantime, can you please pull a copy of the multiproto tree
http://jusst.de/hg/multiproto/

and try to parse the S2 satellite delivery system descriptor ?
dvbsnoop, or even libucsi will be able to do this.
 
> thanks,
> Francesco
> 
> 

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 API vs. HVR4000: When?

[frankio]

Manu Abraham wrote:
> Francesco Schiavarelli wrote:
>   
>> Johannes Stezenbach wrote:
>> 
>>> On Sat, Nov 03, 2007, Manu Abraham wrote:
>>>   
 If you see H.2 and H.3, the difference is between CCM and VCM
 (Note: that both are cases of multiple "TS's")

 H.2 (CCM) is applicable for DVB-T muxes. Here there is a HP/LP stream
 selection in some fashion combined with the merger/slicer where
 stream id is used. 
 
>>> What makes you think there is HP/LP involved? All H.2 says
>>> is that two DVB-T streams are transmitted using one
>>> DVB-S2 transponder to a DVB-T transmitter. The DVB-T transmitter
>>> could then transmit them on two different frequencies in
>>> non-hierarchical mode.
>>>
>>> (Indeed H.2 says "two DTT MUXes at 24 Mbit/s each" indicating
>>> they are not hierarchical because you can't get that
>>> bitrate in DVB-T hierarchical mode. But even if it were DVB-T
>>> hierarchical mode it has nothing to do with DVB-S2 backwards
>>> compatible mode hierarchical modulation.)
>>>
>>>   
>> I agree with you, Johannes.
>> There is no evidence of hierarchical modulation, nevertheless the two
>> streams I was looking at had the same channel protection that is no
>> HP/LP, and I was told it was DVB-S2 CCM.
>>
>> When the transponder will be up again I'll be able to do more tests.
>> 
>
> Yeah, looks more like that, will have a patch soon to do some tests for it.
> STM's comments confirm that.
>
> Manu
>
>   
Now the beam is up on 13.0E 11373 H 27500 8PSK 2/3
It is made up of 2 DTT muxes (no HP/LP)
ISI1   16QAM 1/2 1/49.953 Mbps
ISI2   64QAM 5/6 1/424.882 Mbps

Unfortunately I don't  know how long it will last, so let the tests 
begin! :-)
I'll wait for the patch.

thanks,
Francesco


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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Manu Abraham]

Francesco Schiavarelli wrote:
> Johannes Stezenbach wrote:
>> On Sat, Nov 03, 2007, Manu Abraham wrote:
>>> If you see H.2 and H.3, the difference is between CCM and VCM
>>> (Note: that both are cases of multiple "TS's")
>>>
>>> H.2 (CCM) is applicable for DVB-T muxes. Here there is a HP/LP stream
>>> selection in some fashion combined with the merger/slicer where
>>> stream id is used. 
>>
>> What makes you think there is HP/LP involved? All H.2 says
>> is that two DVB-T streams are transmitted using one
>> DVB-S2 transponder to a DVB-T transmitter. The DVB-T transmitter
>> could then transmit them on two different frequencies in
>> non-hierarchical mode.
>>
>> (Indeed H.2 says "two DTT MUXes at 24 Mbit/s each" indicating
>> they are not hierarchical because you can't get that
>> bitrate in DVB-T hierarchical mode. But even if it were DVB-T
>> hierarchical mode it has nothing to do with DVB-S2 backwards
>> compatible mode hierarchical modulation.)
>>
> I agree with you, Johannes.
> There is no evidence of hierarchical modulation, nevertheless the two
> streams I was looking at had the same channel protection that is no
> HP/LP, and I was told it was DVB-S2 CCM.
> 
> When the transponder will be up again I'll be able to do more tests.

Yeah, looks more like that, will have a patch soon to do some tests for it.
STM's comments confirm that.

Manu



Manu,

MIS allows the selection of streams using the stream identifier.

Regard Peter

PS,  I just go back from a trip.

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Steven Toth]

Ian Bonham wrote:
> On 06/11/2007, *Steven Toth* <[EMAIL PROTECTED] 
> > wrote:
> 
> Gregoire Favre wrote:
>  > On Mon, Nov 05, 2007 at 01:52:26PM -0500, Steven Toth wrote:
>   At this stage I'm looking for a "Yes, in principle we like the
> idea, but
>   show me how you do feature XYZ" from other devs. At which
> point I'll flush
>   out more code this would probably lead to an RFC for your
> approval.
>  >>>
>  >>> Seems like no one is interested.
>  >> yeah, apparently.
>  >
>  > Well, you only asked developpers... I think it would be a good
> idea...
> 
> You and I appear to be in a very small minority.
> 
> 
> 
> Ahem?! :)

3 is small :)

> 
>  >
>  >> In reality, that was a year ago and maybe it's time to revisit DVB-S
>  >> support for the HVR4000. Given the current political climate I
> think I
>  >> like that idea. I'll rework the driver and present a patch later
> this week.
>  >
>  > HVR-4000 without DVB-S2 support could be added directly from
>  > http://dev.kewl.org/hvr4000/v4l-dvb-hg-2007-11-04.diff which is
> based on
>  > a removed hg repo. (See http://dev.kewl.org/hvr4000/ ).
>  >
>  > I always wondered why this patch (or previous ones) weren't
> included in
>  > v4l-dvb ???
> 
> 
> I built an new tree last night with HVR4000 and HVR4000lite support
> taken from my other trees. After testing I'll likely push that tree up
> this evening. My dish is compromised right now, so no doubt we'll
> have fun.
> 
> Darron's patch has some IR and I2C related changes that I'm not
> comfortable merging, without more information/investigation.
> 
> We can persue those after the test tree is built, and merge any
> subsequent changes and/when required.
> 
> This will be a good step forward.
> 
> - Steve
> 
> 
> As soon as the new tree is up, I'll grab it and give it a test out here. 
> I am stuck for a couple of days with work, but can put in some testing 
> time and report back anything I find.

Thanks, much appreciated.

Steve


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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Francesco Schiavarelli]

Johannes Stezenbach wrote:
> On Sat, Nov 03, 2007, Manu Abraham wrote:
>> If you see H.2 and H.3, the difference is between CCM and VCM
>> (Note: that both are cases of multiple "TS's")
>>
>> H.2 (CCM) is applicable for DVB-T muxes. Here there is a HP/LP 
>> stream selection in some fashion combined with the merger/slicer 
>> where stream id is used. 
> 
> What makes you think there is HP/LP involved? All H.2 says
> is that two DVB-T streams are transmitted using one
> DVB-S2 transponder to a DVB-T transmitter. The DVB-T transmitter
> could then transmit them on two different frequencies in
> non-hierarchical mode.
> 
> (Indeed H.2 says "two DTT MUXes at 24 Mbit/s each" indicating
> they are not hierarchical because you can't get that
> bitrate in DVB-T hierarchical mode. But even if it were DVB-T
> hierarchical mode it has nothing to do with DVB-S2 
> backwards compatible mode hierarchical modulation.)
> 
I agree with you, Johannes.
There is no evidence of hierarchical modulation, nevertheless the two 
streams I was looking at had the same channel protection that is no 
HP/LP, and I was told it was DVB-S2 CCM.

When the transponder will be up again I'll be able to do more tests.

Francesco


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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Steven Toth]

Gregoire Favre wrote:
> On Mon, Nov 05, 2007 at 01:52:26PM -0500, Steven Toth wrote:
 At this stage I'm looking for a "Yes, in principle we like the idea, but 
 show me how you do feature XYZ" from other devs. At which point I'll flush 
 out more code this would probably lead to an RFC for your approval.
>>>
>>> Seems like no one is interested.
>> yeah, apparently.
> 
> Well, you only asked developpers... I think it would be a good idea...

You and I appear to be in a very small minority.

> 
>> In reality, that was a year ago and maybe it's time to revisit DVB-S 
>> support for the HVR4000. Given the current political climate I think I 
>> like that idea. I'll rework the driver and present a patch later this week.
> 
> HVR-4000 without DVB-S2 support could be added directly from
> http://dev.kewl.org/hvr4000/v4l-dvb-hg-2007-11-04.diff which is based on
> a removed hg repo. (See http://dev.kewl.org/hvr4000/ ).
> 
> I always wondered why this patch (or previous ones) weren't included in
> v4l-dvb ???


I built an new tree last night with HVR4000 and HVR4000lite support 
taken from my other trees. After testing I'll likely push that tree up 
this evening. My dish is compromised right now, so no doubt we'll have fun.

Darron's patch has some IR and I2C related changes that I'm not 
comfortable merging, without more information/investigation.

We can persue those after the test tree is built, and merge any 
subsequent changes and/when required.

This will be a good step forward.

- Steve


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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Ian Bonham]

On 06/11/2007, Steven Toth <[EMAIL PROTECTED]> wrote:
>
> Gregoire Favre wrote:
> > On Mon, Nov 05, 2007 at 01:52:26PM -0500, Steven Toth wrote:
>  At this stage I'm looking for a "Yes, in principle we like the idea,
> but
>  show me how you do feature XYZ" from other devs. At which point I'll
> flush
>  out more code this would probably lead to an RFC for your approval.
> >>>
> >>> Seems like no one is interested.
> >> yeah, apparently.
> >
> > Well, you only asked developpers... I think it would be a good idea...
>
> You and I appear to be in a very small minority.



Ahem?! :)

>
> >> In reality, that was a year ago and maybe it's time to revisit DVB-S
> >> support for the HVR4000. Given the current political climate I think I
> >> like that idea. I'll rework the driver and present a patch later this
> week.
> >
> > HVR-4000 without DVB-S2 support could be added directly from
> > http://dev.kewl.org/hvr4000/v4l-dvb-hg-2007-11-04.diff which is based on
> > a removed hg repo. (See http://dev.kewl.org/hvr4000/ ).
> >
> > I always wondered why this patch (or previous ones) weren't included in
> > v4l-dvb ???
>
>
> I built an new tree last night with HVR4000 and HVR4000lite support
> taken from my other trees. After testing I'll likely push that tree up
> this evening. My dish is compromised right now, so no doubt we'll have
> fun.
>
> Darron's patch has some IR and I2C related changes that I'm not
> comfortable merging, without more information/investigation.
>
> We can persue those after the test tree is built, and merge any
> subsequent changes and/when required.
>
> This will be a good step forward.
>
> - Steve


As soon as the new tree is up, I'll grab it and give it a test out here. I
am stuck for a couple of days with work, but can put in some testing time
and report back anything I find.

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Steven Toth]

Gregoire Favre wrote:
> On Mon, Nov 05, 2007 at 01:52:26PM -0500, Steven Toth wrote:
 At this stage I'm looking for a "Yes, in principle we like the idea, but 
 show me how you do feature XYZ" from other devs. At which point I'll flush 
 out more code this would probably lead to an RFC for your approval.
>>>
>>> Seems like no one is interested.
>> yeah, apparently.
> 
> Well, you only asked developpers... I think it would be a good idea...

You and I appear to be in a very small minority.

> 
>> In reality, that was a year ago and maybe it's time to revisit DVB-S 
>> support for the HVR4000. Given the current political climate I think I 
>> like that idea. I'll rework the driver and present a patch later this week.
> 
> HVR-4000 without DVB-S2 support could be added directly from
> http://dev.kewl.org/hvr4000/v4l-dvb-hg-2007-11-04.diff which is based on
> a removed hg repo. (See http://dev.kewl.org/hvr4000/ ).
> 
> I always wondered why this patch (or previous ones) weren't included in
> v4l-dvb ???


I built an new tree last night with HVR4000 and HVR4000lite support 
taken from my other trees. After testing I'll likely push that tree up 
this evening. My dish is compromised right now, so no doubt we'll have fun.

Darron's patch has some IR and I2C related changes that I'm not 
comfortable merging, without more information/investigation.

We can persue those after the test tree is built, and merge any 
subsequent changes and/when required.

This will be a good step forward.

- Steve


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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Gregoire Favre]

On Mon, Nov 05, 2007 at 01:52:26PM -0500, Steven Toth wrote:
> 
> >> At this stage I'm looking for a "Yes, in principle we like the idea, but 
> >> show me how you do feature XYZ" from other devs. At which point I'll flush 
> >> out more code this would probably lead to an RFC for your approval.
> > 
> > 
> > Seems like no one is interested.
> 
> yeah, apparently.

Well, you only asked developpers... I think it would be a good idea...

> In reality, that was a year ago and maybe it's time to revisit DVB-S 
> support for the HVR4000. Given the current political climate I think I 
> like that idea. I'll rework the driver and present a patch later this week.

HVR-4000 without DVB-S2 support could be added directly from
http://dev.kewl.org/hvr4000/v4l-dvb-hg-2007-11-04.diff which is based on
a removed hg repo. (See http://dev.kewl.org/hvr4000/ ).

I always wondered why this patch (or previous ones) weren't included in
v4l-dvb ???
-- 
Grégoire FAVRE  http://gregoire.favre.googlepages.com  http://www.gnupg.org
   http://picasaweb.google.com/Gregoire.Favre

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Steven Toth]

>> At this stage I'm looking for a "Yes, in principle we like the idea, but 
>> show me how you do feature XYZ" from other devs. At which point I'll flush 
>> out more code this would probably lead to an RFC for your approval.
> 
> 
> Seems like no one is interested.

yeah, apparently.

(unrelated: thanks for the ioctl patch - mrec also pointed me in the 
right direction).

> 
> 
> BTW, since every DVB-S2 demod is also a DVB-S demod, why does
> no one split the DVB-S parts of their driver for merging
> first? It would make the users happy as it would change the
> state from "card not supported" to "card works for 95% of existing
> transponders". (Dunno how this fits into this thread but...)

It doesn't fit into the thread, but you're welcome to raise it. DVB-S 
only, I did that during late 2005, prior to adopting multiproto. Quickly 
it was clear that the community was behind Manu's project so I dropped 
it and started modifications for multiproto.

Since then I've pushed back on the idea (in hindsight for way too long) 
because multiproto was close to completion for so long.

In reality, that was a year ago and maybe it's time to revisit DVB-S 
support for the HVR4000. Given the current political climate I think I 
like that idea. I'll rework the driver and present a patch later this week.

I can't speak for Manu's STB0899 driver.

- Steve



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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Marcel Siegert]

On Monday 05 November 2007, Johannes Stezenbach wrote:
> On Mon, Nov 05, 2007, Steven Toth wrote:
> > Johannes Stezenbach wrote:
> >>
> >>struct dvb_tuning_param p[3] = {
> >>{ .id = MODULATION, .val = MOD_8VSB },
> >>{ .id = FREQUENCY,  .val = 59125 },
> >>{ .id = 0 }
> >>};
> >>ioctl(fd, DVB_TUNE, p);
> >
> >
> > You can't reliably pass in variably length arrays into the kernel, or none 
> > of the other kernel wide drivers do, they need to be fixed length for 
> > sanity reasons.
> 
> Of course you can have variable length args to ioctl(). It's
> just that you can't let dvb_usercopy() do the work anymore but
> have to call copy_from_user() yourself, but I would favor a simple,
> generic API anytime over one with unnecessary, arbitrary
> limits, so IMHO it's worth the little extra effort.
> 
> #define DVB_TUNE _IOC(_IOC_WRITE,'o',82,0)
> 
> plus
> 
> 
> diff -r 1acfe4149714 linux/drivers/media/dvb/dvb-core/dvbdev.c
> --- a/linux/drivers/media/dvb/dvb-core/dvbdev.c   Mon Nov 05 10:30:39 
> 2007 -0200
> +++ b/linux/drivers/media/dvb/dvb-core/dvbdev.c   Mon Nov 05 18:23:41 
> 2007 +0100
> @@ -362,9 +362,11 @@ int dvb_usercopy(struct inode *inode, st
>   case _IOC_READ: /* some v4l ioctls are marked wrong ... */
>   case _IOC_WRITE:
>   case (_IOC_WRITE | _IOC_READ):
> - if (_IOC_SIZE(cmd) <= sizeof(sbuf)) {
> + if (_IOC_SIZE(cmd) == 0)
> + parg = arg;
> + else if (_IOC_SIZE(cmd) <= sizeof(sbuf))
>   parg = sbuf;
> - } else {
> + else {
>   /* too big to allocate from stack */
>   mbuf = kmalloc(_IOC_SIZE(cmd),GFP_KERNEL);
>   if (NULL == mbuf)
> 
> (untested)
> 
> (BTW, the majority of ioctls don't encode the argument size, this
> feature was invented just a few years ago; see man ioctl_list)
> 
> Or you could encode the lenght seperately like e.g.
> I2C_RDWR does with its struct i2c_rdwr_ioctl_data argument.
> It's a matter of taste, not sanity or security.
> 
> 
> > 1) I've made minor changes to dvb_core to interpret these messages and 
> > handle the ioctl. No changes have been made to the frontend drivers.
> >
> > 2) Adding support for s2 _inside_ the kernel will mean adding a single 
> > method to dvb_frontend_ops which allows the dvb_core to notify a new S2 
> > driver. The goal here is to minimize these changes also. I haven't 
> > demonstrated that code here, becuse I felt it was more important to show 
> > the impact to the userland API/ABI, knowing that DVB-S2 and other advanced 
> > types (including analog) would naturally fit well within this model.
> >
> > 3) This applies to all devs. I welcome all feedback, for sure the sytax 
> > might need some cleanup, but please don't shoot the idea down when it's 
> > only had 6-8 hours work of engineering behind it. It's proof of concept. It 
> > doesn't contain any of Manu's code so I don't feel bound politically or 
> > technically. I think given another 4-5 hours I could show the HVR4000 
> > working, and demonstrate many of the userland signal/statistic API's.
> >
> > At this stage I'm looking for a "Yes, in principle we like the idea, but 
> > show me how you do feature XYZ" from other devs. At which point I'll flush 
> > out more code this would probably lead to an RFC for your approval.
> 
> 
> Seems like no one is interested.
> 
> 
> BTW, since every DVB-S2 demod is also a DVB-S demod, why does
> no one split the DVB-S parts of their driver for merging
> first? It would make the users happy as it would change the
> state from "card not supported" to "card works for 95% of existing
> transponders". (Dunno how this fits into this thread but...)
> 

hi everybody,

what are we doing now?

imho we are discussing a new change to the dvb-s2 api again. 
although i do like this ioctl approach for further enhancements of the api, 
i must admit that things that are already done have to be done again.

iirc, there is a multiproto version of szap, vdr, ...

although, existing drivers e.g. stb0899 must be rewritten/patched to handle the
new iotcl. 

at least i do not know what this will mean to the rework and test scenario, 
on both sides. this means if we take multiproto from manu - what has steven got 
to do,
and, if we take stevens approach, whats on manus side.

i would really appreciate to get a working compromise instead of starting this 
api extension
all over again for the X time since Nov. 2005 when - iirc felix domke and me - 
started the discussion.


"Yes, in principle I like the idea" but someday we must get an end to the 
implementation and 
merge it.

best regards
marcel





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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Ian Bonham]

On 05/11/2007, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
>
>
> Seems like no one is interested.
>
>
> BTW, since every DVB-S2 demod is also a DVB-S demod, why does
> no one split the DVB-S parts of their driver for merging
> first? It would make the users happy as it would change the
> state from "card not supported" to "card works for 95% of existing
> transponders". (Dunno how this fits into this thread but...)



I'm fascinated just to see the development process. Like the idea of
splitting the demods, I'd be happy with S working fine and adding S2 as that
evolves.

Just so u know at least someone is watching! ;)

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Johannes Stezenbach]

On Mon, Nov 05, 2007, Johannes Stezenbach wrote:
> 
> Of course you can have variable length args to ioctl(). It's
> just that you can't let dvb_usercopy() do the work anymore but
> have to call copy_from_user() yourself, but I would favor a simple,
> generic API anytime over one with unnecessary, arbitrary
> limits, so IMHO it's worth the little extra effort.
> 
> #define DVB_TUNE _IOC(_IOC_WRITE,'o',82,0)
> 
> plus

Here's a better patch, still untested but without
obvious bugs, I hope ;-) :

diff -r 1acfe4149714 linux/drivers/media/dvb/dvb-core/dvbdev.c
--- a/linux/drivers/media/dvb/dvb-core/dvbdev.c Mon Nov 05 10:30:39 2007 -0200
+++ b/linux/drivers/media/dvb/dvb-core/dvbdev.c Mon Nov 05 18:41:43 2007 +0100
@@ -362,9 +362,11 @@ int dvb_usercopy(struct inode *inode, st
case _IOC_READ: /* some v4l ioctls are marked wrong ... */
case _IOC_WRITE:
case (_IOC_WRITE | _IOC_READ):
-   if (_IOC_SIZE(cmd) <= sizeof(sbuf)) {
+   if (_IOC_SIZE(cmd) == 0)
+   parg = arg;
+   else if (_IOC_SIZE(cmd) <= sizeof(sbuf))
parg = sbuf;
-   } else {
+   else {
/* too big to allocate from stack */
mbuf = kmalloc(_IOC_SIZE(cmd),GFP_KERNEL);
if (NULL == mbuf)
@@ -373,7 +375,7 @@ int dvb_usercopy(struct inode *inode, st
}
 
err = -EFAULT;
-   if (copy_from_user(parg, (void __user *)arg, _IOC_SIZE(cmd)))
+   if (_IOC_SIZE(cmd) && copy_from_user(parg, (void __user *)arg, 
_IOC_SIZE(cmd)))
goto out;
break;
}
@@ -390,7 +392,7 @@ int dvb_usercopy(struct inode *inode, st
{
case _IOC_READ:
case (_IOC_WRITE | _IOC_READ):
-   if (copy_to_user((void __user *)arg, parg, _IOC_SIZE(cmd)))
+   if (_IOC_SIZE(cmd) && copy_to_user((void __user *)arg, parg, 
_IOC_SIZE(cmd)))
err = -EFAULT;
break;
}


Johannes

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Johannes Stezenbach]

On Mon, Nov 05, 2007, Steven Toth wrote:
> Johannes Stezenbach wrote:
>>
>>  struct dvb_tuning_param p[3] = {
>>  { .id = MODULATION, .val = MOD_8VSB },
>>  { .id = FREQUENCY,  .val = 59125 },
>>  { .id = 0 }
>>  };
>>  ioctl(fd, DVB_TUNE, p);
>
>
> You can't reliably pass in variably length arrays into the kernel, or none 
> of the other kernel wide drivers do, they need to be fixed length for 
> sanity reasons.

Of course you can have variable length args to ioctl(). It's
just that you can't let dvb_usercopy() do the work anymore but
have to call copy_from_user() yourself, but I would favor a simple,
generic API anytime over one with unnecessary, arbitrary
limits, so IMHO it's worth the little extra effort.

#define DVB_TUNE _IOC(_IOC_WRITE,'o',82,0)

plus


diff -r 1acfe4149714 linux/drivers/media/dvb/dvb-core/dvbdev.c
--- a/linux/drivers/media/dvb/dvb-core/dvbdev.c Mon Nov 05 10:30:39 2007 -0200
+++ b/linux/drivers/media/dvb/dvb-core/dvbdev.c Mon Nov 05 18:23:41 2007 +0100
@@ -362,9 +362,11 @@ int dvb_usercopy(struct inode *inode, st
case _IOC_READ: /* some v4l ioctls are marked wrong ... */
case _IOC_WRITE:
case (_IOC_WRITE | _IOC_READ):
-   if (_IOC_SIZE(cmd) <= sizeof(sbuf)) {
+   if (_IOC_SIZE(cmd) == 0)
+   parg = arg;
+   else if (_IOC_SIZE(cmd) <= sizeof(sbuf))
parg = sbuf;
-   } else {
+   else {
/* too big to allocate from stack */
mbuf = kmalloc(_IOC_SIZE(cmd),GFP_KERNEL);
if (NULL == mbuf)

(untested)

(BTW, the majority of ioctls don't encode the argument size, this
feature was invented just a few years ago; see man ioctl_list)

Or you could encode the lenght seperately like e.g.
I2C_RDWR does with its struct i2c_rdwr_ioctl_data argument.
It's a matter of taste, not sanity or security.


> 1) I've made minor changes to dvb_core to interpret these messages and 
> handle the ioctl. No changes have been made to the frontend drivers.
>
> 2) Adding support for s2 _inside_ the kernel will mean adding a single 
> method to dvb_frontend_ops which allows the dvb_core to notify a new S2 
> driver. The goal here is to minimize these changes also. I haven't 
> demonstrated that code here, becuse I felt it was more important to show 
> the impact to the userland API/ABI, knowing that DVB-S2 and other advanced 
> types (including analog) would naturally fit well within this model.
>
> 3) This applies to all devs. I welcome all feedback, for sure the sytax 
> might need some cleanup, but please don't shoot the idea down when it's 
> only had 6-8 hours work of engineering behind it. It's proof of concept. It 
> doesn't contain any of Manu's code so I don't feel bound politically or 
> technically. I think given another 4-5 hours I could show the HVR4000 
> working, and demonstrate many of the userland signal/statistic API's.
>
> At this stage I'm looking for a "Yes, in principle we like the idea, but 
> show me how you do feature XYZ" from other devs. At which point I'll flush 
> out more code this would probably lead to an RFC for your approval.


Seems like no one is interested.


BTW, since every DVB-S2 demod is also a DVB-S demod, why does
no one split the DVB-S parts of their driver for merging
first? It would make the users happy as it would change the
state from "card not supported" to "card works for 95% of existing
transponders". (Dunno how this fits into this thread but...)


Johannes

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Steven Toth]

Markus Rechberger wrote:
> On 11/5/07, Steven Toth <[EMAIL PROTECTED]> wrote:
>> Johannes Stezenbach wrote:
>>> On Fri, Nov 02, 2007, Steven Toth wrote:
 The design goals for me are:

 1) We stop trying to predict what the API will need in 5 years, and focus
 on building a very simplistic ioctl API for getting and setting generic
 frontend properties, it should be basic enough to deal with any new
 modulation type (or advanced tuner) that we know of today.
>>> good one
>>>
 2) We change the tuning mechanism from being (mostly) atomic
>> (SET_FRONTEND)
 to a looser command/sequence definition. (Thereby stepping away from
>> fixed
 structs that define the ABI). With two new ioctls
 (get_property/set_property) and a simple property struct which specifies
 how generic types are passed to/from the kernel.
>>> no so good
>>>
 3) A userland library _may_ offer a number of helper functions to
>> simplify
 in terms of applications development, turning this:
>>> many people seem to hate ALSA, there's a lesson to be learned here
>>>
 command.id = BEGIN_TRANSACTION
 ioctl(SET_PROPERTY, &command);

 command.id = SET_MODULATION
 command.arg = 8VSB
 ioctl(SET_PROPERTY, &command);

 command.id = SET_FREQUENCY
 command.arg = 59125
 ioctl(SET_PROPERTY, &command);

 command.id = VALIDATE_TRANSACTION
 ioctl(SET_PROPERTY, &command);

 command.id = END_TRANSACTION
 ioctl(SET_PROPERTY, &command);

 Into a more human readable form like this:

 int tune_8vsb(frequency);

 It's a basic approach, we trade off multiple ioctls (at a very low rate)
 entering the kernel, for a very flexible tuning approach to frontend
 control.
>>> Once you have those tag/value pairs, you could batch them
>>> together in an array and pass them down in one ioctl. This
>>> avoids the ugly transaction stuff and keeps it atomic.
>>> And I think it wouldn't look too ugly in user code, e.g.:
>>>
>>> struct dvb_tuning_param p[3] = {
>>> { .id = MODULATION, .val = MOD_8VSB },
>>> { .id = FREQUENCY,  .val = 59125 },
>>> { .id = 0 }
>>> };
>>> ioctl(fd, DVB_TUNE, p);
>>
>> You can't reliably pass in variably length arrays into the kernel, or
>> none of the other kernel wide drivers do, they need to be fixed length
>> for sanity reasons. That being said, I have a newly defined type which
>> represents an array enabling 16 messages to be passed in a single
>> transaction.
>>
> 
> Hi Steven,
> 
> just have a look at the i2c-dev driver it passes a variable length to
> the kernel.
> 

Hey Markus,

Good. I looked at about 40 different drivers, then ran some kernel wide 
greps before giving up. I can see it now, this is a much nicer approach.

Thanks,

- Steve


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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Markus Rechberger]

On 11/5/07, Steven Toth <[EMAIL PROTECTED]> wrote:
> Johannes Stezenbach wrote:
> > On Fri, Nov 02, 2007, Steven Toth wrote:
> >> The design goals for me are:
> >>
> >> 1) We stop trying to predict what the API will need in 5 years, and focus
> >> on building a very simplistic ioctl API for getting and setting generic
> >> frontend properties, it should be basic enough to deal with any new
> >> modulation type (or advanced tuner) that we know of today.
> >
> > good one
> >
> >> 2) We change the tuning mechanism from being (mostly) atomic
> (SET_FRONTEND)
> >> to a looser command/sequence definition. (Thereby stepping away from
> fixed
> >> structs that define the ABI). With two new ioctls
> >> (get_property/set_property) and a simple property struct which specifies
> >> how generic types are passed to/from the kernel.
> >
> > no so good
> >
> >> 3) A userland library _may_ offer a number of helper functions to
> simplify
> >> in terms of applications development, turning this:
> >
> > many people seem to hate ALSA, there's a lesson to be learned here
> >
> >> command.id = BEGIN_TRANSACTION
> >> ioctl(SET_PROPERTY, &command);
> >>
> >> command.id = SET_MODULATION
> >> command.arg = 8VSB
> >> ioctl(SET_PROPERTY, &command);
> >>
> >> command.id = SET_FREQUENCY
> >> command.arg = 59125
> >> ioctl(SET_PROPERTY, &command);
> >>
> >> command.id = VALIDATE_TRANSACTION
> >> ioctl(SET_PROPERTY, &command);
> >>
> >> command.id = END_TRANSACTION
> >> ioctl(SET_PROPERTY, &command);
> >>
> >> Into a more human readable form like this:
> >>
> >> int tune_8vsb(frequency);
> >>
> >> It's a basic approach, we trade off multiple ioctls (at a very low rate)
> >> entering the kernel, for a very flexible tuning approach to frontend
> >> control.
> >
> > Once you have those tag/value pairs, you could batch them
> > together in an array and pass them down in one ioctl. This
> > avoids the ugly transaction stuff and keeps it atomic.
> > And I think it wouldn't look too ugly in user code, e.g.:
> >
> > struct dvb_tuning_param p[3] = {
> > { .id = MODULATION, .val = MOD_8VSB },
> > { .id = FREQUENCY,  .val = 59125 },
> > { .id = 0 }
> > };
> > ioctl(fd, DVB_TUNE, p);
>
>
> You can't reliably pass in variably length arrays into the kernel, or
> none of the other kernel wide drivers do, they need to be fixed length
> for sanity reasons. That being said, I have a newly defined type which
> represents an array enabling 16 messages to be passed in a single
> transaction.
>

Hi Steven,

just have a look at the i2c-dev driver it passes a variable length to
the kernel.

Markus

> IE. It's no limited by array size. ioctls can be chained together to
> form atomic tuning operations and are not bound by length, should any
> future hardware require radically different parameters/operations.
>
> Here's the message set I've using with QAM for example:
>
> tv_properties_t _qam_cmdseq = {
>   { .cmd = TV_SEQ_START },
>   { .cmd = TV_SET_FREQUENCY,  .u.data = 56100 },
>   { .cmd = TV_SET_MODULATION, .u.data = QAM_AUTO },
>   { .cmd = TV_SET_INVERSION,  .u.data = INVERSION_AUTO },
>   { .cmd = TV_SET_BANDWIDTH,  .u.data = BANDWIDTH_AUTO },
>   { .cmd = TV_SEQ_COMPLETE },
>   { .cmd = 0 },
> };
>
> ... and here's the ioctl structure in question from frontend.h
>
> typedef struct {
>  __u32 cmd;
>  union {
>  __u32 data;
>  struct {
>  __u8 data[32];
>  __u32 len;
>  } buffer;
>  } u;
> } tv_property_t;
>
> /* No more than 16 properties during any given ioctl */
> typedef tv_property_t tv_properties_t[16];
>
> #define FE_SET_PROPERTY_IOW('o', 82, tv_properties_t)
>
> I have other changes to frontend.h that I'll describe below, in answer
> to your other points.
>
> Unrelated: It's important to note that the new API allows messages to be
> atomic individually, or grouped into transactions for a single atomic
> operation. One example is a single message to control DiSEqC, which in
> the current published API occurs immediately. The current API is
> completely atomic, and offers nothing for future hardware which may need
> a finer grain of control. (Think analog)
>
> Hence, this API supports both mechanisms.
>
>
> >
> >
> > But there's more work to do:
> > - need for .val being variable lenght or a union of different types?
>
> See the current union. It supports a generic u32 for passing enums or
> other values, and also a generic byte buffer (which can be chained with
> multiple messages and multiple ioctls via transactions grouping). This
> generic buffer is large enough to store the current DiSEqC message
> mechanisms, but scalable to be able to support any number of future
> messages with any message lengths, literally into multi megabytes if
> that's what is required.
>
>
> > - extend existing enums or define new ones for MODULATION etc

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Steven Toth]

Johannes Stezenbach wrote:
> On Fri, Nov 02, 2007, Steven Toth wrote:
>> The design goals for me are:
>>
>> 1) We stop trying to predict what the API will need in 5 years, and focus 
>> on building a very simplistic ioctl API for getting and setting generic 
>> frontend properties, it should be basic enough to deal with any new 
>> modulation type (or advanced tuner) that we know of today.
> 
> good one
> 
>> 2) We change the tuning mechanism from being (mostly) atomic (SET_FRONTEND) 
>> to a looser command/sequence definition. (Thereby stepping away from fixed 
>> structs that define the ABI). With two new ioctls 
>> (get_property/set_property) and a simple property struct which specifies 
>> how generic types are passed to/from the kernel.
> 
> no so good
> 
>> 3) A userland library _may_ offer a number of helper functions to simplify 
>> in terms of applications development, turning this:
> 
> many people seem to hate ALSA, there's a lesson to be learned here
> 
>> command.id = BEGIN_TRANSACTION
>> ioctl(SET_PROPERTY, &command);
>>
>> command.id = SET_MODULATION
>> command.arg = 8VSB
>> ioctl(SET_PROPERTY, &command);
>>
>> command.id = SET_FREQUENCY
>> command.arg = 59125
>> ioctl(SET_PROPERTY, &command);
>>
>> command.id = VALIDATE_TRANSACTION
>> ioctl(SET_PROPERTY, &command);
>>
>> command.id = END_TRANSACTION
>> ioctl(SET_PROPERTY, &command);
>>
>> Into a more human readable form like this:
>>
>> int tune_8vsb(frequency);
>>
>> It's a basic approach, we trade off multiple ioctls (at a very low rate) 
>> entering the kernel, for a very flexible tuning approach to frontend 
>> control.
> 
> Once you have those tag/value pairs, you could batch them
> together in an array and pass them down in one ioctl. This
> avoids the ugly transaction stuff and keeps it atomic.
> And I think it wouldn't look too ugly in user code, e.g.:
> 
>   struct dvb_tuning_param p[3] = {
>   { .id = MODULATION, .val = MOD_8VSB },
>   { .id = FREQUENCY,  .val = 59125 },
>   { .id = 0 }
>   };
>   ioctl(fd, DVB_TUNE, p);


You can't reliably pass in variably length arrays into the kernel, or 
none of the other kernel wide drivers do, they need to be fixed length 
for sanity reasons. That being said, I have a newly defined type which 
represents an array enabling 16 messages to be passed in a single 
transaction.

IE. It's no limited by array size. ioctls can be chained together to 
form atomic tuning operations and are not bound by length, should any 
future hardware require radically different parameters/operations.

Here's the message set I've using with QAM for example:

tv_properties_t _qam_cmdseq = {
{ .cmd = TV_SEQ_START },
{ .cmd = TV_SET_FREQUENCY,  .u.data = 56100 },
{ .cmd = TV_SET_MODULATION, .u.data = QAM_AUTO },
{ .cmd = TV_SET_INVERSION,  .u.data = INVERSION_AUTO },
{ .cmd = TV_SET_BANDWIDTH,  .u.data = BANDWIDTH_AUTO },
{ .cmd = TV_SEQ_COMPLETE },
{ .cmd = 0 },
};

... and here's the ioctl structure in question from frontend.h

typedef struct {
 __u32 cmd;
 union {
 __u32 data;
 struct {
 __u8 data[32];
 __u32 len;
 } buffer;
 } u;
} tv_property_t;

/* No more than 16 properties during any given ioctl */
typedef tv_property_t tv_properties_t[16];

#define FE_SET_PROPERTY_IOW('o', 82, tv_properties_t)

I have other changes to frontend.h that I'll describe below, in answer 
to your other points.

Unrelated: It's important to note that the new API allows messages to be 
atomic individually, or grouped into transactions for a single atomic 
operation. One example is a single message to control DiSEqC, which in 
the current published API occurs immediately. The current API is 
completely atomic, and offers nothing for future hardware which may need 
a finer grain of control. (Think analog)

Hence, this API supports both mechanisms.


> 
> 
> But there's more work to do:
> - need for .val being variable lenght or a union of different types?

See the current union. It supports a generic u32 for passing enums or 
other values, and also a generic byte buffer (which can be chained with 
multiple messages and multiple ioctls via transactions grouping). This 
generic buffer is large enough to store the current DiSEqC message 
mechanisms, but scalable to be able to support any number of future 
messages with any message lengths, literally into multi megabytes if 
that's what is required.


> - extend existing enums or define new ones for MODULATION etc?

A mixture of both.

Where appropriate the current enums have been extended to support new 
modulation types, FECs etc. In more cases than not, this is the case.

Where appropriate new enums/type have been defined to support new user 
facing attributes (rolloff/pilot) being a classic case (although both 
current drivers detect Pilot aut

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Steven Toth]

Grégoire FAVRE wrote:
> Hello :-)
> 
> Just as a reminder : http://dev.kewl.org/hvr4000/ contains a
> patch against v4l-dvb which add hvr-4000 support (without
> DVB-S2) : http://dev.kewl.org/hvr4000/v4l-dvb-hg-2007-08-31.diff
> 
> And there is also a copy of the hvr4000 repo which could be used
> as a base to develop for this great card :-)

Hi,

Darron did a good amount of work in relation to DiSEqC and helped 
tremendously with the pilot related issues (or the fact it wasn't tuning 
corrrectly in Europe).

I'm glad he's still holding a tree based on Multiproto.

I _do_ expect to release a newer tree soon, not based on multiproto.

Stay tuned here.

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 API vs. HVR4000: When?

[Grégoire FAVRE]

Hello :-)

Just as a reminder : http://dev.kewl.org/hvr4000/ contains a
patch against v4l-dvb which add hvr-4000 support (without
DVB-S2) : http://dev.kewl.org/hvr4000/v4l-dvb-hg-2007-08-31.diff

And there is also a copy of the hvr4000 repo which could be used
as a base to develop for this great card :-)
-- 
Grégoire FAVRE
http://picasaweb.google.com/Gregoire.Favre
http://gregoire.favre.googlepages.com/

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Steven Toth]

Igor Nikanov wrote:
> Hi, Steven
> 
> is it possible to discuss about HVR4000  in this mail list now ?
> There's several questions after some tests with this card
> 
> Regards
> Igor

Hi,

You've always been welcome to post any comments about the HVR4000 in the 
public mailing list, I only asked not to be contacted personally about 
the patches until any it's Linux future was clear.

A number of other HVR4000 users are also on this list, and they are 
probably also willing to help.

Ask away, someone will probably hve answers to your questions. :)

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 API vs. HVR4000: When?

[Igor Nikanov]

Hi, Steven

is it possible to discuss about HVR4000  in this mail list now ?
There's several questions after some tests with this card

Regards
Igor





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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[hermann pitton]

Am Samstag, den 03.11.2007, 00:56 +0100 schrieb rjkm:
> Manu Abraham writes:
>  > If you have had crack, then you will see cracks everywhere . :)
>  > 
>  > > I don't understand Ralph's involvement in your Linux projects, and why
>  > > the alternative direction mattered to him.
>  > > 
>  > 
>  > If you see the initial proposal, there were so many people involved, Ralph 
> too,
>  > he used to hang out on IRC along with us. Please see the original post 
> when 
>  > the STB0899 driver was made public.
>  > 
>  > There were reasons why it mattered to him. He was also involved in an
>  > STB0899 based project, which he can disclose if he is interested.
>  > 
> 
> 
> There is a nice little PCIe dual STB0899 reference platform I wrote
> drivers for. But I don't know if it will ever be built by anybody.
> 
> 
> Ralph
> 

Ralph,

thanks for your comment, and you never did let a beginner hang into
something, when it starts to become serious, iirc.

I ask frankly now.

Was there really something going that wrong, that Manu still feels he is
right intercepting all from v4l, because Mauro did also some harm to
you, likely without any chance to avoid it, simply not knowing what it
could be all about, since we were on blank bones after Gerd got it sick?

That is what I got told from him when it became, hmm, _quite strange_
previously over a long amount of time and tried to ask ...

He told me that Mauro crossed your ways somehow too, but it was that
abstract still, that I did not understood where the point of it should
ever be and after fair and fully understandable explanations, what he
has to face too, it ended up within hours then that we are all
idiots ... , because I said Mauro is none.

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 API vs. HVR4000: When?

[Manu Abraham]

Johannes Stezenbach wrote:
> On Sat, Nov 03, 2007, Manu Abraham wrote:
>> If you see H.2 and H.3, the difference is between CCM and VCM
>> (Note: that both are cases of multiple "TS's")
>>
>> H.2 (CCM) is applicable for DVB-T muxes. Here there is a HP/LP 
>> stream selection in some fashion combined with the merger/slicer 
>> where stream id is used. 
> 
> What makes you think there is HP/LP involved? All H.2 says
> is that two DVB-T streams are transmitted using one
> DVB-S2 transponder to a DVB-T transmitter. The DVB-T transmitter
> could then transmit them on two different frequencies in
> non-hierarchical mode.
> 
> (Indeed H.2 says "two DTT MUXes at 24 Mbit/s each" indicating
> they are not hierarchical because you can't get that
> bitrate in DVB-T hierarchical mode. But even if it were DVB-T
> hierarchical mode it has nothing to do with DVB-S2 
> backwards compatible mode hierarchical modulation.)
> 
>> It is a combination of both, rather than a simple stream id.
>> (In this case Rolloff=0.20, Pilots do not exist) in this case the 
>> QPSK stream is with FEC 5/6 
>>
>> H.3 (VCM) is applicable for a HDTV/SDTV mux. here it is quite similar 
>> to H.2 exception that (In this case Rolloff=0.25, Pilots do exist)
>> in this case the QPSK stream is with FEC 3/4 and the 16APSK stream 
>> is with FEC 3/4
>>
>> H.2 is playing with the DVB-S signal level (saturating a transponder) 
>> where as H.3 is using differential protection. It is not very clear how 
>> both of these are distinguished from each other.
> 
> The thing is that you don't need to distinguish them in the
> demod API at all. DVB-S2 allows changing modulation parameters
> with every PLFRAME (for VCM), and the only way this can work is
> if the demod can figure them out by itself. This works because
> the PLHEADER is sent with a fixed coding and modulation which
> is independent from the rest of the PLFRAME.
> 
> That's why you don't have to worry about the details of the
> transmission parameters, and why they don't exist in the
> EN 300 468 S2 satellite delivery system descriptor.
> 
> (Those details are interesting for the broadcaster, of course,
> who needs to optimize throughput vs. receiption performance.)
> 
>> Also, on the demod other than the MIS flag (according to the specs) 
>> there is another bitfield to select the HP/LP stream, which makes it a 
>> bit even more confusing. There exists some clarity, but again there are 
>> some clouds which hinder how it looks.
>>
>> I am not really very clear on handling this. We will get more clarifications 
>> the coming days.
> 
> HP/LP is only used for backwards compatible (to DVB-S) mode, as
> one of two options. A DVB-S receiver will only see the HP stream,
> the DVB-S2 signal will appear as additional noise to it.
> 
> OTOH a DVB-S2 receiver can choose between HP and LP.
> 
> I don't know how this is implemented in DVB-S2 demods, it could be
> a selection bit in a register, or the demod could output the LP stream
> in DVB-S2 mode and the HP stream in DVB-S mode.
> 
> 
> That's how I think it works.

Most probably you are right, but i still do not feel comfortable, well will see
what the vendor has to say.

Manu


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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Manu Abraham]

Johannes Stezenbach wrote:
> On Sat, Nov 03, 2007, Manu Abraham wrote:
>> Also, i forgot to mention one more thing, 16APSK is denoted as 
>> 4 + 12 APSK, (for the demod) not sure why either.
> 
> See 5.4.3 Bit mapping into 16APSK constellation.
> 

Right, didn't think of that.

Thanks,
Manu

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Johannes Stezenbach]

On Sat, Nov 03, 2007, Manu Abraham wrote:
> 
> Also, i forgot to mention one more thing, 16APSK is denoted as 
> 4 + 12 APSK, (for the demod) not sure why either.

See 5.4.3 Bit mapping into 16APSK constellation.


Johannes

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Johannes Stezenbach]

On Sat, Nov 03, 2007, Manu Abraham wrote:
> 
> If you see H.2 and H.3, the difference is between CCM and VCM
> (Note: that both are cases of multiple "TS's")
> 
> H.2 (CCM) is applicable for DVB-T muxes. Here there is a HP/LP 
> stream selection in some fashion combined with the merger/slicer 
> where stream id is used. 

What makes you think there is HP/LP involved? All H.2 says
is that two DVB-T streams are transmitted using one
DVB-S2 transponder to a DVB-T transmitter. The DVB-T transmitter
could then transmit them on two different frequencies in
non-hierarchical mode.

(Indeed H.2 says "two DTT MUXes at 24 Mbit/s each" indicating
they are not hierarchical because you can't get that
bitrate in DVB-T hierarchical mode. But even if it were DVB-T
hierarchical mode it has nothing to do with DVB-S2 
backwards compatible mode hierarchical modulation.)

> It is a combination of both, rather than a simple stream id.
> (In this case Rolloff=0.20, Pilots do not exist) in this case the 
> QPSK stream is with FEC 5/6 
> 
> H.3 (VCM) is applicable for a HDTV/SDTV mux. here it is quite similar 
> to H.2 exception that (In this case Rolloff=0.25, Pilots do exist)
> in this case the QPSK stream is with FEC 3/4 and the 16APSK stream 
> is with FEC 3/4
> 
> H.2 is playing with the DVB-S signal level (saturating a transponder) 
> where as H.3 is using differential protection. It is not very clear how 
> both of these are distinguished from each other.

The thing is that you don't need to distinguish them in the
demod API at all. DVB-S2 allows changing modulation parameters
with every PLFRAME (for VCM), and the only way this can work is
if the demod can figure them out by itself. This works because
the PLHEADER is sent with a fixed coding and modulation which
is independent from the rest of the PLFRAME.

That's why you don't have to worry about the details of the
transmission parameters, and why they don't exist in the
EN 300 468 S2 satellite delivery system descriptor.

(Those details are interesting for the broadcaster, of course,
who needs to optimize throughput vs. receiption performance.)

> Also, on the demod other than the MIS flag (according to the specs) 
> there is another bitfield to select the HP/LP stream, which makes it a 
> bit even more confusing. There exists some clarity, but again there are 
> some clouds which hinder how it looks.
> 
> I am not really very clear on handling this. We will get more clarifications 
> the coming days.

HP/LP is only used for backwards compatible (to DVB-S) mode, as
one of two options. A DVB-S receiver will only see the HP stream,
the DVB-S2 signal will appear as additional noise to it.

OTOH a DVB-S2 receiver can choose between HP and LP.

I don't know how this is implemented in DVB-S2 demods, it could be
a selection bit in a register, or the demod could output the LP stream
in DVB-S2 mode and the HP stream in DVB-S mode.


That's how I think it works.


Johannes

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Manu Abraham]

rjkm wrote:
> Manu Abraham writes:
>  > If you have had crack, then you will see cracks everywhere . :)
>  > 
>  > > I don't understand Ralph's involvement in your Linux projects, and why
>  > > the alternative direction mattered to him.
>  > > 
>  > 
>  > If you see the initial proposal, there were so many people involved, Ralph 
> too,
>  > he used to hang out on IRC along with us. Please see the original post 
> when 
>  > the STB0899 driver was made public.
>  > 
>  > There were reasons why it mattered to him. He was also involved in an
>  > STB0899 based project, which he can disclose if he is interested.
>  > 
> 
> 
> There is a nice little PCIe dual STB0899 reference platform I wrote
> drivers for. But I don't know if it will ever be built by anybody.
> 

I have the picture here: http://abraham.manu.googlepages.com/mic.jpg

Manu

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[rjkm]

Manu Abraham writes:
 > If you have had crack, then you will see cracks everywhere . :)
 > 
 > > I don't understand Ralph's involvement in your Linux projects, and why
 > > the alternative direction mattered to him.
 > > 
 > 
 > If you see the initial proposal, there were so many people involved, Ralph 
 > too,
 > he used to hang out on IRC along with us. Please see the original post when 
 > the STB0899 driver was made public.
 > 
 > There were reasons why it mattered to him. He was also involved in an
 > STB0899 based project, which he can disclose if he is interested.
 > 


There is a nice little PCIe dual STB0899 reference platform I wrote
drivers for. But I don't know if it will ever be built by anybody.


Ralph

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Manu Abraham]

Manu Abraham wrote:
> Hi Johannes,
> 
> Johannes Stezenbach wrote:
>> On Sat, Nov 03, 2007, Manu Abraham wrote:
>>> When Johannes stated: handling multiple streams is as simple as setting 
>>> a stream id, well it is not that i blame him, the specs look that way. 
>>> There 
>>> are couple of ways the same thing is done for example. You apply a 
>>> wrong one and the API is screwed and you have to bear that brunt for 
>>> a long time to come.
>> Hey, if you know more than I do then please explain it to me.
>>
>> Until proven wrong I continue to believe that there isn't any more
>> magic to handling multi stream mode than choosing one of them
>> by writing the stream id into the appropriate demod register.
> 
> ;-) of course. I have learned it the hard way, that proving a person 
> wrong can be disastrous.
> 
> Nevertheless i will explain my understanding, eventhough not a 
> great one. :)
> 
> If you see H.2 and H.3, the difference is between CCM and VCM
> (Note: that both are cases of multiple "TS's")
> 
> H.2 (CCM) is applicable for DVB-T muxes. Here there is a HP/LP 
> stream selection in some fashion combined with the merger/slicer 
> where stream id is used. 
> 
> It is a combination of both, rather than a simple stream id.
> (In this case Rolloff=0.20, Pilots do not exist) in this case the 
> QPSK stream is with FEC 5/6 
> 
> H.3 (VCM) is applicable for a HDTV/SDTV mux. here it is quite similar 
> to H.2 exception that (In this case Rolloff=0.25, Pilots do exist)
> in this case the QPSK stream is with FEC 3/4 and the 16APSK stream 
> is with FEC 3/4
> 

Also, i forgot to mention one more thing, 16APSK is denoted as 
4 + 12 APSK, (for the demod) not sure why either.

> H.2 is playing with the DVB-S signal level (saturating a transponder) 
> where as H.3 is using differential protection. It is not very clear how 
> both of these are distinguished from each other.
> 
> Also, on the demod other than the MIS flag (according to the specs) 
> there is another bitfield to select the HP/LP stream, which makes it a 
> bit even more confusing. There exists some clarity, but again there are 
> some clouds which hinder how it looks.
> 
> I am not really very clear on handling this. We will get more clarifications 
> the coming days.
> 
> Manu
> 


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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Manu Abraham]

Hi Johannes,

Johannes Stezenbach wrote:
> On Sat, Nov 03, 2007, Manu Abraham wrote:
>> When Johannes stated: handling multiple streams is as simple as setting 
>> a stream id, well it is not that i blame him, the specs look that way. There 
>> are couple of ways the same thing is done for example. You apply a 
>> wrong one and the API is screwed and you have to bear that brunt for 
>> a long time to come.
> 
> Hey, if you know more than I do then please explain it to me.
> 
> Until proven wrong I continue to believe that there isn't any more
> magic to handling multi stream mode than choosing one of them
> by writing the stream id into the appropriate demod register.

;-) of course. I have learned it the hard way, that proving a person 
wrong can be disastrous.

Nevertheless i will explain my understanding, eventhough not a 
great one. :)

If you see H.2 and H.3, the difference is between CCM and VCM
(Note: that both are cases of multiple "TS's")

H.2 (CCM) is applicable for DVB-T muxes. Here there is a HP/LP 
stream selection in some fashion combined with the merger/slicer 
where stream id is used. 

It is a combination of both, rather than a simple stream id.
(In this case Rolloff=0.20, Pilots do not exist) in this case the 
QPSK stream is with FEC 5/6 

H.3 (VCM) is applicable for a HDTV/SDTV mux. here it is quite similar 
to H.2 exception that (In this case Rolloff=0.25, Pilots do exist)
in this case the QPSK stream is with FEC 3/4 and the 16APSK stream 
is with FEC 3/4

H.2 is playing with the DVB-S signal level (saturating a transponder) 
where as H.3 is using differential protection. It is not very clear how 
both of these are distinguished from each other.

Also, on the demod other than the MIS flag (according to the specs) 
there is another bitfield to select the HP/LP stream, which makes it a 
bit even more confusing. There exists some clarity, but again there are 
some clouds which hinder how it looks.

I am not really very clear on handling this. We will get more clarifications 
the coming days.

Manu

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Johannes Stezenbach]

On Sat, Nov 03, 2007, Manu Abraham wrote:
> 
> When Johannes stated: handling multiple streams is as simple as setting 
> a stream id, well it is not that i blame him, the specs look that way. There 
> are couple of ways the same thing is done for example. You apply a 
> wrong one and the API is screwed and you have to bear that brunt for 
> a long time to come.

Hey, if you know more than I do then please explain it to me.

Until proven wrong I continue to believe that there isn't any more
magic to handling multi stream mode than choosing one of them
by writing the stream id into the appropriate demod register.


Johannes

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Johannes Stezenbach]

On Fri, Nov 02, 2007, Steven Toth wrote:
>
> The design goals for me are:
>
> 1) We stop trying to predict what the API will need in 5 years, and focus 
> on building a very simplistic ioctl API for getting and setting generic 
> frontend properties, it should be basic enough to deal with any new 
> modulation type (or advanced tuner) that we know of today.

good one

> 2) We change the tuning mechanism from being (mostly) atomic (SET_FRONTEND) 
> to a looser command/sequence definition. (Thereby stepping away from fixed 
> structs that define the ABI). With two new ioctls 
> (get_property/set_property) and a simple property struct which specifies 
> how generic types are passed to/from the kernel.

no so good

> 3) A userland library _may_ offer a number of helper functions to simplify 
> in terms of applications development, turning this:

many people seem to hate ALSA, there's a lesson to be learned here

> command.id = BEGIN_TRANSACTION
> ioctl(SET_PROPERTY, &command);
>
> command.id = SET_MODULATION
> command.arg = 8VSB
> ioctl(SET_PROPERTY, &command);
>
> command.id = SET_FREQUENCY
> command.arg = 59125
> ioctl(SET_PROPERTY, &command);
>
> command.id = VALIDATE_TRANSACTION
> ioctl(SET_PROPERTY, &command);
>
> command.id = END_TRANSACTION
> ioctl(SET_PROPERTY, &command);
>
> Into a more human readable form like this:
>
> int tune_8vsb(frequency);
>
> It's a basic approach, we trade off multiple ioctls (at a very low rate) 
> entering the kernel, for a very flexible tuning approach to frontend 
> control.

Once you have those tag/value pairs, you could batch them
together in an array and pass them down in one ioctl. This
avoids the ugly transaction stuff and keeps it atomic.
And I think it wouldn't look too ugly in user code, e.g.:

struct dvb_tuning_param p[3] = {
{ .id = MODULATION, .val = MOD_8VSB },
{ .id = FREQUENCY,  .val = 59125 },
{ .id = 0 }
};
ioctl(fd, DVB_TUNE, p);


But there's more work to do:
- need for .val being variable lenght or a union of different types?
- extend existing enums or define new ones for MODULATION etc?
- how to do FE_GET_FRONTEND
- etc.

I'm sure we could have endless debates over the details ;-)

I hope many others will comment which approach they like better,
or which one they think will be ready for prime time sooner.

Personally I don't care either way. I spent a lot of time discussing
the "multiproto" API and I believe it could be ready soon with
a few minor tweaks. OTOH this tag/value approach seems to be
more flexible, but who knows how much work it'll take to complete.


Johannes

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Manu Abraham]

Steven Toth wrote:
> Manu Abraham wrote:
>> Steven Toth wrote:
>>  
>>> Manu Abraham wrote:
>>>
 Steven Toth wrote:
  
  
> simpler/smaller interface. I made reference to this in my first
> HVR4000
> patches where massive amounts of code were potentially being
> duplicated.
> 
 Please point out the duplication.

 
>>> At the time, the demod drivers had to provide a set_frontend() and
>>> set_params() ops method. That meant two entry points into every driver
>>> (with differing args), the same was true for many other entry points
>>> that took the new structures.
>>> 
>>
>> Btw, before you start complaining about other's code, It is always
>> better to have a look at your own code to have a feel where you are
>> standing.
>>
>> Because of some of your changes we have had long arguments by Markus,
>> (on locking) well this was in kernel. What you are complaining is
>> something not even applied to the kernel and very much pre alpha.
>>
>> Just to talk back on the same tongue.
>>
>>   
> 
> You asked for my feedback. So, I gave you all the feedback based on the
> last time I reviewed your code, I even said that these issue may already
> be fixed. (Explicitly opening myself up for attack - should you chose).

Ok, is it fixed now ? Why should i attack you if you commented on an issue ? 
If it is some nonsense then sure there is a reason.

> This review took place prior to you removing it from LinuxTV and you
> doing your own thing.

There was nothing called removing from LinuxTV. There were reasons 
why i moved my trees.

* Johannes expressed concern over crappy trees, such that it was a 
  hurdle for him to backup everything. No one paid heed to his request.
  (i did explain this earlier too)

  For me, at that time i had a local high end server, for which push was easy, 
  which the server had lot of free space.
  Not only the push time reduced for me, but on a small note, i did help by 
  removing whatever clutter i could.

  (For some people, it is the assumption that having too many trees in a 
   public place is like showing that they work on so many different things.
   Cheap publicity.)

* When you work with a tree (different people work different ways) a shell
  can be very handy to quickly export a patch, apply to another tree etc.

  Earlier the people around were easier to work with, before the merger of 
  the trees, look at any discussion, almost like clockwork, one idiot who 
  doesn't even have a single line of code, from V4L land talks crap about 
  the DVB developers.

* For the users also it was easy rather than looking at those countless crap 
  of repositories. Ask any normal sane user whether they feel comfortable.

But as usual, you were one of the chaps, who just looked at your own 
convenience or whatever you felt like.

> Why are we arguing Manu when we both want the same thing to happen, for
> multiproto to get traction?

I gave you the same options what i told Johannes, But you wanted to act
different. Is it not true ?

> Have I not always been polite in all of my offers of help, prior to my
> recent bitterness and/or sarcasm?

Were i any different from your state as you mentioned of, earlier ?

When you were struggling to get pilots working, did i got specs from one 
of my own clients to help you out how it worked for your case, did i not ? 
What changed ? Why did i have to help you ?

I just don't have anything specific issues to anyone, but what i receive, i 
just give it back in the same platter.

Do you think any of the people around will put in so much effort to help 
you so ?

It could have been that you don't find any value in all those help. 

> Look at the situation from an outsiders perspective. Whenever the
> subject of finishing the multiproto work comes up, the conversation
> never ends in a happy place.

Why does it happen that way ? You need to understand what's in there 
and what's not. Did i not explain clearly what's the TODO and COMPLETE 
things etc. Well, before you start arguing on a subject, you need to 
understand the subject. Otherwise it will sound exactly like a marketplace.
For this one needs to put in efforts to understand, nothing comes FOC.
When you think that let's have an argument and let's get ideas from 
that discussion, without any understanding of the same, many a times
it results in sparks.

As i said earlier there are more demods on the way, if we screw up, all 
those devices will be screwed up, like the DVB-T HP/LP. But this is 
something bigger than that. We are talking about 3 different modes, as 
far as i can think.

I will tell you why also. The DVB-S2 specification is damn crazy. It has 
backward compatibility stuff to incorporate for the old stuff, the current 
stuff and things yet to come. It is quite a hard specification.

When Johannes stated: handling multiple streams is as simple as setting 
a stream id, well it is not that i blame him, the specs look that wa

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Steven Toth]

Steven Toth wrote:
> Manu Abraham wrote:
>> Steven Toth wrote:
>>  
>>> Manu Abraham wrote:
>>>
 Steven Toth wrote:
  
  
> simpler/smaller interface. I made reference to this in my first 
> HVR4000
> patches where massive amounts of code were potentially being 
> duplicated.
> 
 Please point out the duplication.

 
>>> At the time, the demod drivers had to provide a set_frontend() and
>>> set_params() ops method. That meant two entry points into every driver
>>> (with differing args), the same was true for many other entry points
>>> that took the new structures.
>>> 
>>
>> Btw, before you start complaining about other's code, It is always 
>> better to have a look at your own code to have a feel where you are 
>> standing.
>>
>> Because of some of your changes we have had long arguments by Markus,
>> (on locking) well this was in kernel. What you are complaining is 
>> something not even applied to the kernel and very much pre alpha.
>>
>> Just to talk back on the same tongue.
>>
>>   
>
> You asked for my feedback. So, I gave you all the feedback based on 
> the last time I reviewed your code, I even said that these issue may 
> already be fixed. (Explicitly opening myself up for attack - should 
> you chose). This review took place prior to you removing it from 
> LinuxTV and you doing your own thing.
>
> Why are we arguing Manu when we both want the same thing to happen, 
> for multiproto to get traction?
>
> Have I not always been polite in all of my offers of help, prior to my 
> recent bitterness and/or sarcasm?
>
> Look at the situation from an outsiders perspective. Whenever the 
> subject of finishing the multiproto work comes up, the conversation 
> never ends in a happy place.
>
> I keep repeating myself when I'm say this: Nothing would make me 
> happier than seeing multiproto in a test tree, where people inside 
> (and outside) of the LinuxTV team can contribute. It would be a 
> significant step forward but whenever this subject is raised, 
> regardless of how politely I try to ask, it never results in a good 
> conversation.
>
> I wish we could find a better way to communicate (and/or work 
> together), for the good of everyone.
>
> - Steve
>
>
>
Resend.


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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Manu Abraham]

Steven Toth wrote:
> Manu Abraham wrote:
>> Steven Toth wrote:
>>  
>>> simpler/smaller interface. I made reference to this in my first HVR4000
>>> patches where massive amounts of code were potentially being duplicated.
>>> 
>>
>> Please point out the duplication.
>>
>>   
> At the time, the demod drivers had to provide a set_frontend() and
> set_params() ops method. That meant two entry points into every driver
> (with differing args), the same was true for many other entry points
> that took the new structures.

Btw, before you start complaining about other's code, It is always better 
to have a look at your own code to have a feel where you are standing.

Because of some of your changes we have had long arguments by Markus,
(on locking) well this was in kernel. What you are complaining is something 
not even applied to the kernel and very much pre alpha.

Just to talk back on the same tongue.

Manu

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Manu Abraham]

Steven Toth wrote:

> I haven't looked at the example STB0899 driver in a _long_ time, but I
> would hope those issues have since been resolved.

Complain when you are sure about it. Otherwise it is called whining.

Manu

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Manu Abraham]

Steven Toth wrote:
> Manu Abraham wrote:
>> Steven Toth wrote:
>>  
>>> Manu Abraham wrote:
>>>
 Steven Toth wrote:

  
  
> The design goals for me are:
>
> 1) We stop trying to predict what the API will need in 5 years, and
> focus on building a very simplistic ioctl API for getting and setting
> generic frontend properties, it should be basic enough to deal with
> any
> new modulation type (or advanced tuner) that we know of today.
>
> 2) We change the tuning mechanism from being (mostly) atomic
> (SET_FRONTEND) to a looser command/sequence definition. (Thereby
> stepping away from fixed structs that define the ABI). With two new
> ioctls (get_property/set_property) and a simple property struct which
> specifies how generic types are passed to/from the kernel.
>
> 3) A userland library _may_ offer a number of helper functions to
> simplify in terms of applications development, turning this:
>
> 
 [..]

  
  
> command.id = END_TRANSACTION
> ioctl(SET_PROPERTY, &command);
>
> Into a more human readable form like this:
>
> int tune_8vsb(frequency);
>
> 
 Even before you thought even, we (myself and adq) have had an
 implementation to do this, in kernel it was called "mti" and the
 userspace interface called "libdvbapi". The sample implementation was
 with the stv0299 and the ttpci card. This was more than 18 months
 back. The reason for that cause was another specific
 demodulator.

 You can read through the archives, on the same, tuning algorithms and
 so on. In that scenario, we additionally had the tuning algorithm
 in userspace too, simplifying many other things.


 
>>> Interesting, I'll dig back and read. Why didn't it gain any traction?
>>>
>>> 
>>
>> It was done around 70%, but then the STB0899 got a higher priority.
>>
>> Markus's userspace approach is also similar, not much different, small
>> differences. ;-)
>>
>> When so much is done, then i would say better it is to move all frontends
>> to userspace as well. but mti/libdvbapi had the best of both the
>> worlds, It was to be working with both in kernel and userspace
>> drivers, quite flexible.
>>
>> The whole thing started of with a small thing, an idea from Johannes
>> about a "simple user space tuning".
>>
>> I had even pointed it to Greg KH when he introduced UIO and eventually
>> it was on LWN as well. probably if you Google you might find the same.
>> Greg was happy to see such things which were completely different.
>>
>> It wasn't that it didn't gain any traction, Ralph at that time advised
>> me to pay more attention to DVB-S2/STB0899.
>>
>>
>>   
> Hmm. This is quite possibly the biggest 'crack in the floor / stuff fell
> through' story that I've heard of in quite a while.
> 

If you have had crack, then you will see cracks everywhere . :)

> I don't understand Ralph's involvement in your Linux projects, and why
> the alternative direction mattered to him.
> 

If you see the initial proposal, there were so many people involved, Ralph too,
he used to hang out on IRC along with us. Please see the original post when 
the STB0899 driver was made public.

There were reasons why it mattered to him. He was also involved in an
STB0899 based project, which he can disclose if he is interested.

Manu

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Manu Abraham]

Steven Toth wrote:
> simpler/smaller interface. I made reference to this in my first HVR4000
> patches where massive amounts of code were potentially being duplicated.

Please point out the duplication.


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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Manu Abraham]

Steven Toth wrote:
> Manu Abraham wrote:
>> Steven Toth wrote:
>>
>>  
>>> The design goals for me are:
>>>
>>> 1) We stop trying to predict what the API will need in 5 years, and
>>> focus on building a very simplistic ioctl API for getting and setting
>>> generic frontend properties, it should be basic enough to deal with any
>>> new modulation type (or advanced tuner) that we know of today.
>>>
>>> 2) We change the tuning mechanism from being (mostly) atomic
>>> (SET_FRONTEND) to a looser command/sequence definition. (Thereby
>>> stepping away from fixed structs that define the ABI). With two new
>>> ioctls (get_property/set_property) and a simple property struct which
>>> specifies how generic types are passed to/from the kernel.
>>>
>>> 3) A userland library _may_ offer a number of helper functions to
>>> simplify in terms of applications development, turning this:
>>>
>>> 
>>
>> [..]
>>
>>  
>>> command.id = END_TRANSACTION
>>> ioctl(SET_PROPERTY, &command);
>>>
>>> Into a more human readable form like this:
>>>
>>> int tune_8vsb(frequency);
>>>
>>> 
>>
>> Even before you thought even, we (myself and adq) have had an
>> implementation to do this, in kernel it was called "mti" and the
>> userspace interface called "libdvbapi". The sample implementation was
>> with the stv0299 and the ttpci card. This was more than 18 months
>> back. The reason for that cause was another specific
>> demodulator.
>>
>> You can read through the archives, on the same, tuning algorithms and
>> so on. In that scenario, we additionally had the tuning algorithm
>> in userspace too, simplifying many other things.
>>
>>
>>   
> Interesting, I'll dig back and read. Why didn't it gain any traction?
> 

It was done around 70%, but then the STB0899 got a higher priority.

Markus's userspace approach is also similar, not much different, small 
differences. ;-)

When so much is done, then i would say better it is to move all frontends
to userspace as well. but mti/libdvbapi had the best of both the worlds, It 
was to be working with both in kernel and userspace drivers, quite flexible.

The whole thing started of with a small thing, an idea from Johannes 
about a "simple user space tuning".

I had even pointed it to Greg KH when he introduced UIO and eventually 
it was on LWN as well. probably if you Google you might find the same.
Greg was happy to see such things which were completely different.

It wasn't that it didn't gain any traction, Ralph at that time advised me to 
pay more attention to DVB-S2/STB0899.

Manu


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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Manu Abraham]

Steven Toth wrote:

> The design goals for me are:
> 
> 1) We stop trying to predict what the API will need in 5 years, and
> focus on building a very simplistic ioctl API for getting and setting
> generic frontend properties, it should be basic enough to deal with any
> new modulation type (or advanced tuner) that we know of today.
> 
> 2) We change the tuning mechanism from being (mostly) atomic
> (SET_FRONTEND) to a looser command/sequence definition. (Thereby
> stepping away from fixed structs that define the ABI). With two new
> ioctls (get_property/set_property) and a simple property struct which
> specifies how generic types are passed to/from the kernel.
> 
> 3) A userland library _may_ offer a number of helper functions to
> simplify in terms of applications development, turning this:
> 

[..]

> command.id = END_TRANSACTION
> ioctl(SET_PROPERTY, &command);
> 
> Into a more human readable form like this:
> 
> int tune_8vsb(frequency);
> 

Even before you thought even, we (myself and adq) have had an 
implementation to do this, in kernel it was called "mti" and the 
userspace interface called "libdvbapi". The sample implementation 
was with the stv0299 and the ttpci card. This was more than 18 
months back. The reason for that cause was another specific
demodulator.

You can read through the archives, on the same, tuning algorithms 
and so on. In that scenario, we additionally had the tuning algorithm
in userspace too, simplifying many other things.

HTH
Manu

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Johannes Stezenbach]

Hi Steve,

On Wed, Oct 31, 2007, Steven Toth wrote:
> 
> You've miss-interpreted my comments.
> 
> I suggested that the API should be defined, but not necessarily 
> implemented. I was suggesting that we define enough API to generate a 
> test tree and make some progress. Supporting your earlier statement, I 
> suggested that the small amount of unimplemented API (which you 
> suggested was inconsequential) could be implemented while other 
> developers were testing the core TV functionality.
...
> I'm wasting my time here.

I was hoping you would outline how you would like to
proceed. Instead you ask Manu for his plans and then
declare "I don't like it" -- IMHO that's a bit lame.

May I suggest that you create a new tree which uses
just the bits from Manu's tree which you intend to
reuse (of course keeping copyright/authorship attribution
intact), and rebase your HVR4000 on top of it?

IMHO the userspace-visible API (i.e. the changes to
include/linux/dvb/frontend.h only) was discussed extensively,
and while there still are a few missing pieces I don't
see the need to restart from scratch. I know that
e.g. Felix Domke mentioned he'd prefer a more minimalistic
frontend.h API change. Personally I wouldn't mind but I think
the time to bang out a complete proposal, and discuss it
and find supporters for it will take longer than just going
with what we have now in Manu's tree.

I haven't looked at Manu's dvb-core changes yet. Currently
it is also not clear to me if your problem is with the code
or just with the fact that Manu owns the code and you can't
go forward without him. But the latter is what I tried to address
with my proposal to create a repository which splits API/dvb-core
changes from the STB0899 driver.

Please outline what your actual problem is, maybe then I
can help to resolve it.


Johannes

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[hermann pitton]

Am Freitag, den 02.11.2007, 01:22 +0100 schrieb Markus Rechberger:
> On 11/2/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> > On 11/1/07, Nico Sabbi <[EMAIL PROTECTED]> wrote:
> > > Il Thursday 01 November 2007 20:36:36 Steven Toth ha scritto:
> > > > Ian Bonham wrote:
> > > > > Steve,
> > > > > Does this mean you will be working on an alternative to
> > > > > MultiProto? As an HVR4000 user I am following this thread closely
> > > > > as you might imagine.
> > > > >
> > > > > Ian
> > > >
> > > > Most likely yes.
> > > >
> > > > - Steve
> > >
> > > I really hope there won't be too many ( >1 ) APIs around: right now
> > > I'd be very embarassed regarding the API choose API to extend
> > > dvbstream and mplayer...
> > >
> >
> > I wonder many people are around blindly overall within the whole
> > linuxtv project.
> > Community should mean that people support other ones.
> > Either visible on the Mailinglist uppon valid topics or providing
> > sourcecode.
> > What I've seen here is just forcing and pushing developers who don't
> > agree with a small amount of people (since most others are independent
> > and almost noone is involved with specific topics which are covered by
> > individuals). Sooner or later this will draw back since the freedom is
> > gone that way.
> >
> 
> Ah well I just read what's going on with Mandriva at the moment this
> makes me thinking about linuxtv again.
> While this crowd is playing a shitty game against each other, in
> Windows _everything's_ available. Now planing to replace around 17.000
> copies of Linux with Windows at one side seriously has a positive
> impact of supported hardware at least. Ah well continue to play
> against each other.
> 
> Markus
> 

Markus,

I don't know what you are talking about. ;)

We all, of course including you, are v4l-dvb!

So, Oliver should review Manu's multiproto patches, but get's confused
by some Kconfig stuff from Trent in between, which he now first time
interprets as in worst case personal. Total bullshit! Trent tries to
keep the build possible, as Mauro and Mike did before and he is doing a
great job.

Next Johannes should come in, that is not bound to days or weeks, and
declare that we don't ride a dead horse.

Finally Manu has to made a decision, how far we can proceed for now.
Since all what will fail will fall back to him next! Stay fair.

If he can't overcome his bttv v4l2 clash with Mauro, and we on v4l can't
let Mauro go for nothing (!!!), he might submit his patches over Andrew
or Linus directly, if he feels better then.

Until anything such happens, Steve is also only a captive of it and to
do things twice ... Nico said it.

If needed, I'm at least good for to get some hardware and crash a
little.

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 API vs. HVR4000: When?

[Markus Rechberger]

On 11/2/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> On 11/1/07, Nico Sabbi <[EMAIL PROTECTED]> wrote:
> > Il Thursday 01 November 2007 20:36:36 Steven Toth ha scritto:
> > > Ian Bonham wrote:
> > > > Steve,
> > > > Does this mean you will be working on an alternative to
> > > > MultiProto? As an HVR4000 user I am following this thread closely
> > > > as you might imagine.
> > > >
> > > > Ian
> > >
> > > Most likely yes.
> > >
> > > - Steve
> >
> > I really hope there won't be too many ( >1 ) APIs around: right now
> > I'd be very embarassed regarding the API choose API to extend
> > dvbstream and mplayer...
> >
>
> I wonder many people are around blindly overall within the whole
> linuxtv project.
> Community should mean that people support other ones.
> Either visible on the Mailinglist uppon valid topics or providing
> sourcecode.
> What I've seen here is just forcing and pushing developers who don't
> agree with a small amount of people (since most others are independent
> and almost noone is involved with specific topics which are covered by
> individuals). Sooner or later this will draw back since the freedom is
> gone that way.
>

Ah well I just read what's going on with Mandriva at the moment this
makes me thinking about linuxtv again.
While this crowd is playing a shitty game against each other, in
Windows _everything's_ available. Now planing to replace around 17.000
copies of Linux with Windows at one side seriously has a positive
impact of supported hardware at least. Ah well continue to play
against each other.

Markus

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Markus Rechberger]

On 11/1/07, Nico Sabbi <[EMAIL PROTECTED]> wrote:
> Il Thursday 01 November 2007 20:36:36 Steven Toth ha scritto:
> > Ian Bonham wrote:
> > > Steve,
> > > Does this mean you will be working on an alternative to
> > > MultiProto? As an HVR4000 user I am following this thread closely
> > > as you might imagine.
> > >
> > > Ian
> >
> > Most likely yes.
> >
> > - Steve
>
> I really hope there won't be too many ( >1 ) APIs around: right now
> I'd be very embarassed regarding the API choose API to extend
> dvbstream and mplayer...
>

I wonder many people are around blindly overall within the whole
linuxtv project.
Community should mean that people support other ones.
Either visible on the Mailinglist uppon valid topics or providing sourcecode.
What I've seen here is just forcing and pushing developers who don't
agree with a small amount of people (since most others are independent
and almost noone is involved with specific topics which are covered by
individuals). Sooner or later this will draw back since the freedom is
gone that way.

Markus

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Nico Sabbi]

Il Thursday 01 November 2007 20:36:36 Steven Toth ha scritto:
> Ian Bonham wrote:
> > Steve,
> > Does this mean you will be working on an alternative to
> > MultiProto? As an HVR4000 user I am following this thread closely
> > as you might imagine.
> >
> > Ian
>
> Most likely yes.
>
> - Steve

I really hope there won't be too many ( >1 ) APIs around: right now
I'd be very embarassed regarding the API choose API to extend
dvbstream and mplayer...

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Steven Toth]

Ian Bonham wrote:
> Steve,
> Does this mean you will be working on an alternative to MultiProto?
> As an HVR4000 user I am following this thread closely as you might imagine.
> 
> Ian
> 

Most likely yes.

- Steve

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Ian Bonham]

Steve,
Does this mean you will be working on an alternative to MultiProto?
As an HVR4000 user I am following this thread closely as you might imagine.

Ian


On 11/1/07, Steven Toth <[EMAIL PROTECTED]> wrote:
>
> Manu Abraham wrote:
> > Steven Toth wrote:
> >> Johannes Stezenbach wrote:
> >>> Hi,
> >>>
> >>> On Tue, Oct 30, 2007, Manu Abraham wrote:
> >>>
>  Johannes Stezenbach wrote:
> 
> > three weeks have passed since Steve expressed his
> > discomfort with the HVR4000 merge being blocked
> > waiting for multiproto.
> >
>  Before i state anything, Current DVB-S2 API status:
> 
> >>> [snip]
> >>>
> >>> Thanks, that's useful.
> >>>
> >>>
> >> Yes.
> >>
> > Can you give us a time frame for when the multiproto
> > merge will happen?
> >
> > Or, alternatively, can we split multiproto into
> > two repositories, one with API + dvb-core changes
> > and one (on top of it) with the STB0899 driver?
> >
>  It can be either way, which one of the following do you think is
>  better in your view ?
> 
>  (1) DVB-S2 API partly merged now and the rest of the S2 API later.
>  (2) Complete event list update and VCM and merge that also alongwith.
> 
>  in either case it can be with or without the STB0899 driver.
> 
>  What do you think ?
> 
> >>> I'd prefer to address the remaining API issues first, however
> >>> what I primarily want to avoid is that Steve rewrites the
> >>> HVR4000 driver to a competing API proposal due to
> >>> frustration with the lack of progress.
> >>>
> >>>
> >> Agreed.
> >>
> >>> IMHO there should be a clear path of actions for Steve
> >>> (or whoever else wants to help) to do that would allow merging
> >>> the HVR4000 driver. I.e. instead of having to wait for some
> >>> event beyond his control there should be a checklist, and
> >>> the merge can happen when all items are resolved.
> >>>
> >>> Or something like that. Preferably Steve would comment
> >>> how he'd like to go forward.
> >>>
> >>>
> >> If these are new API's then I suspect the HVR4000 doesn't use them. I
> >> would agree it makes sense to define them, but depending on their focus
> >> they may not need to be implemented and should not be considered a
> >> roadblock to an alpha release.
> >>
> >> If they don't impact core functionality then I see no reason why this
> >> cannot be defined now, but implement (and refined) later during the
> test
> >> cycle. (I'm expecting testing to be a very long process, because we'll
> >> need to encourage the VDR/MythTV/Other applications groups to begin
> >> integration).
> >>
> >> I am a realist. I don't expect the first tree will be perfect. I am
> >> expecting some change. I am expecting apps devs/testers to find bugs
> and
> >> problems which will cause us to rethink some parts of the multiproto
> >> core and it's S2 drivers.
> >>
> >> No doubt the VDR and MythTV folks will also have something to say and
> >> that may impact the API also. We need to pay respect to the opinions of
> >> the applications developers.
> >>
> >> I don't think the first release needs to be perfect.
> >>
> >> I think if the current API is good enough to support the needs of
> >> Myth/VDR then that's something we can start with. Release early,
> release
> >> often.
> >
> >
> > It is not how the APi is good enough to support the needs of MythTV or
> VDR,
> > but how the API can be considered as a guide for the application
> developers
> > to understand how to talk to a DVB-S2 device
> >
> >
> >> Manu, this is your patch and I respect your work, how would you suggest
> >> we proceed?
> >>
> >
> > There does exist a ported version of VDR to the new API. The current
> situation
> > is that the S2 devices cannot be tuned to certain frequencies because of
> the
> > use of Backward compatible modes, ie the API, nor the drivers currently
> do
> > support them.
> >
> > Give application developers a chance to mess up stating that the API is
> out,
> > eventually what will happen is: example look at people crying out on
> > mythtv issues with regards to DVB devices. I have had quite some
> experiences
> > trying to make application developers understand what they do wrong.
> >
> > I am waiting to hear from other developers as well, whether they would
> like to
> > do whether to do
> >
> > (1) partial DVB-S2 API support now and the rest of the DVB-S2 API later.
> > (2) DVB-S2 API what it needs to tune to all the transponders at least
> >
> > Look, this is not the question of the HVR4000 or the STB0899 alone, it
> will affect
> > all future devices. As Johannes said, what goes into the API (user ABI)
> is permanent,
> > it won't change. It is something that will be set in stone as opposed to
> the driver
> > internal API. (The driver API we can change, but not the ABI) What we
> are looking at
> > is the API-ABI
> >
> > Let me cite certain examples of such large scale screwups where people
> are stuck:
> >
> >
>
> You've miss-interpret

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Steven Toth]

Manu Abraham wrote:
> Steven Toth wrote:
>> Johannes Stezenbach wrote:
>>> Hi,
>>>
>>> On Tue, Oct 30, 2007, Manu Abraham wrote:
>>>  
 Johannes Stezenbach wrote:

> three weeks have passed since Steve expressed his
> discomfort with the HVR4000 merge being blocked
> waiting for multiproto.
>   
 Before i state anything, Current DVB-S2 API status:
 
>>> [snip]
>>>
>>> Thanks, that's useful.
>>>
>>>   
>> Yes.
>>
> Can you give us a time frame for when the multiproto
> merge will happen?
>
> Or, alternatively, can we split multiproto into
> two repositories, one with API + dvb-core changes
> and one (on top of it) with the STB0899 driver?
>   
 It can be either way, which one of the following do you think is
 better in your view ?

 (1) DVB-S2 API partly merged now and the rest of the S2 API later.
 (2) Complete event list update and VCM and merge that also alongwith.

 in either case it can be with or without the STB0899 driver.

 What do you think ?
 
>>> I'd prefer to address the remaining API issues first, however
>>> what I primarily want to avoid is that Steve rewrites the
>>> HVR4000 driver to a competing API proposal due to
>>> frustration with the lack of progress.
>>>
>>>   
>> Agreed.
>>
>>> IMHO there should be a clear path of actions for Steve
>>> (or whoever else wants to help) to do that would allow merging
>>> the HVR4000 driver. I.e. instead of having to wait for some
>>> event beyond his control there should be a checklist, and
>>> the merge can happen when all items are resolved.
>>>
>>> Or something like that. Preferably Steve would comment
>>> how he'd like to go forward.
>>>
>>>   
>> If these are new API's then I suspect the HVR4000 doesn't use them. I
>> would agree it makes sense to define them, but depending on their focus
>> they may not need to be implemented and should not be considered a
>> roadblock to an alpha release.
>>
>> If they don't impact core functionality then I see no reason why this
>> cannot be defined now, but implement (and refined) later during the test
>> cycle. (I'm expecting testing to be a very long process, because we'll
>> need to encourage the VDR/MythTV/Other applications groups to begin
>> integration).
>>
>> I am a realist. I don't expect the first tree will be perfect. I am
>> expecting some change. I am expecting apps devs/testers to find bugs and
>> problems which will cause us to rethink some parts of the multiproto
>> core and it's S2 drivers.
>>
>> No doubt the VDR and MythTV folks will also have something to say and
>> that may impact the API also. We need to pay respect to the opinions of
>> the applications developers.
>>
>> I don't think the first release needs to be perfect.
>>
>> I think if the current API is good enough to support the needs of
>> Myth/VDR then that's something we can start with. Release early, release
>> often.
> 
> 
> It is not how the APi is good enough to support the needs of MythTV or VDR, 
> but how the API can be considered as a guide for the application developers 
> to understand how to talk to a DVB-S2 device
> 
>  
>> Manu, this is your patch and I respect your work, how would you suggest
>> we proceed?
>>
> 
> There does exist a ported version of VDR to the new API. The current 
> situation 
> is that the S2 devices cannot be tuned to certain frequencies because of the 
> use of Backward compatible modes, ie the API, nor the drivers currently do 
> support them.
> 
> Give application developers a chance to mess up stating that the API is out, 
> eventually what will happen is: example look at people crying out on 
> mythtv issues with regards to DVB devices. I have had quite some experiences
> trying to make application developers understand what they do wrong.
> 
> I am waiting to hear from other developers as well, whether they would like to
> do whether to do 
> 
> (1) partial DVB-S2 API support now and the rest of the DVB-S2 API later.
> (2) DVB-S2 API what it needs to tune to all the transponders at least
> 
> Look, this is not the question of the HVR4000 or the STB0899 alone, it will 
> affect 
> all future devices. As Johannes said, what goes into the API (user ABI) is 
> permanent,
> it won't change. It is something that will be set in stone as opposed to the 
> driver 
> internal API. (The driver API we can change, but not the ABI) What we are 
> looking at 
> is the API-ABI
> 
> Let me cite certain examples of such large scale screwups where people are 
> stuck:
> 
> 

You've miss-interpreted my comments.

I suggested that the API should be defined, but not necessarily 
implemented. I was suggesting that we define enough API to generate a 
test tree and make some progress. Supporting your earlier statement, I 
suggested that the small amount of unimplemented API (which you 
suggested was inconsequential) could be implemented while other 
developers were testing the core TV functional

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Manu Abraham]

Steven Toth wrote:
> Johannes Stezenbach wrote:
>> Hi,
>>
>> On Tue, Oct 30, 2007, Manu Abraham wrote:
>>  
>>> Johannes Stezenbach wrote:
>>>
 three weeks have passed since Steve expressed his
 discomfort with the HVR4000 merge being blocked
 waiting for multiproto.
   
>>> Before i state anything, Current DVB-S2 API status:
>>> 
>> [snip]
>>
>> Thanks, that's useful.
>>
>>   
> 
> Yes.
> 
 Can you give us a time frame for when the multiproto
 merge will happen?

 Or, alternatively, can we split multiproto into
 two repositories, one with API + dvb-core changes
 and one (on top of it) with the STB0899 driver?
   
>>> It can be either way, which one of the following do you think is
>>> better in your view ?
>>>
>>> (1) DVB-S2 API partly merged now and the rest of the S2 API later.
>>> (2) Complete event list update and VCM and merge that also alongwith.
>>>
>>> in either case it can be with or without the STB0899 driver.
>>>
>>> What do you think ?
>>> 
>>
>> I'd prefer to address the remaining API issues first, however
>> what I primarily want to avoid is that Steve rewrites the
>> HVR4000 driver to a competing API proposal due to
>> frustration with the lack of progress.
>>
>>   
> 
> Agreed.
> 
>> IMHO there should be a clear path of actions for Steve
>> (or whoever else wants to help) to do that would allow merging
>> the HVR4000 driver. I.e. instead of having to wait for some
>> event beyond his control there should be a checklist, and
>> the merge can happen when all items are resolved.
>>
>> Or something like that. Preferably Steve would comment
>> how he'd like to go forward.
>>
>>   
> 
> If these are new API's then I suspect the HVR4000 doesn't use them. I
> would agree it makes sense to define them, but depending on their focus
> they may not need to be implemented and should not be considered a
> roadblock to an alpha release.
> 
> If they don't impact core functionality then I see no reason why this
> cannot be defined now, but implement (and refined) later during the test
> cycle. (I'm expecting testing to be a very long process, because we'll
> need to encourage the VDR/MythTV/Other applications groups to begin
> integration).
> 
> I am a realist. I don't expect the first tree will be perfect. I am
> expecting some change. I am expecting apps devs/testers to find bugs and
> problems which will cause us to rethink some parts of the multiproto
> core and it's S2 drivers.
> 
> No doubt the VDR and MythTV folks will also have something to say and
> that may impact the API also. We need to pay respect to the opinions of
> the applications developers.
> 
> I don't think the first release needs to be perfect.
> 
> I think if the current API is good enough to support the needs of
> Myth/VDR then that's something we can start with. Release early, release
> often.


It is not how the APi is good enough to support the needs of MythTV or VDR, 
but how the API can be considered as a guide for the application developers 
to understand how to talk to a DVB-S2 device

 
> Manu, this is your patch and I respect your work, how would you suggest
> we proceed?
> 

There does exist a ported version of VDR to the new API. The current situation 
is that the S2 devices cannot be tuned to certain frequencies because of the 
use of Backward compatible modes, ie the API, nor the drivers currently do 
support them.

Give application developers a chance to mess up stating that the API is out, 
eventually what will happen is: example look at people crying out on 
mythtv issues with regards to DVB devices. I have had quite some experiences
trying to make application developers understand what they do wrong.

I am waiting to hear from other developers as well, whether they would like to
do whether to do 

(1) partial DVB-S2 API support now and the rest of the DVB-S2 API later.
(2) DVB-S2 API what it needs to tune to all the transponders at least

Look, this is not the question of the HVR4000 or the STB0899 alone, it will 
affect 
all future devices. As Johannes said, what goes into the API (user ABI) is 
permanent,
it won't change. It is something that will be set in stone as opposed to the 
driver 
internal API. (The driver API we can change, but not the ABI) What we are 
looking at 
is the API-ABI

Let me cite certain examples of such large scale screwups where people are 
stuck:

a) DVB-T HP/LP streams. During the last FIFA (iirc), the FTA streams were on 
the LP 
stream and the scrambled HD streams were on the HP stream. Users wanted to
watch the LP stream, but the API was screwed up, because the way how to select 
the HP/LP stream was screwed up and fixing it was not possible as it is, 
without a 
change in the ABI
(Even now, we have this problem!)

b) During the early phases, Johannes/Holger thought that all DVB devices 
provided
wrong postprocess information (marketing gimmicks)  and they did some crude 
things, 
the device what they used was most proba

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Manu Abraham]

Johannes Stezenbach wrote:
> Hi,
> 
> On Tue, Oct 30, 2007, Manu Abraham wrote:
>> Johannes Stezenbach wrote:
>>> three weeks have passed since Steve expressed his
>>> discomfort with the HVR4000 merge being blocked
>>> waiting for multiproto.
>> Before i state anything, Current DVB-S2 API status:
> [snip]
> 
> Thanks, that's useful.
> 
>>> Can you give us a time frame for when the multiproto
>>> merge will happen?
>>>
>>> Or, alternatively, can we split multiproto into
>>> two repositories, one with API + dvb-core changes
>>> and one (on top of it) with the STB0899 driver?
>> It can be either way, which one of the following do you think is better in 
>> your view ?
>>
>> (1) DVB-S2 API partly merged now and the rest of the S2 API later.
>> (2) Complete event list update and VCM and merge that also alongwith.
>>
>> in either case it can be with or without the STB0899 driver.
>>
>> What do you think ?
> 
> I'd prefer to address the remaining API issues first, however
> what I primarily want to avoid is that Steve rewrites the
> HVR4000 driver to a competing API proposal due to
> frustration with the lack of progress.

It is not that progress is not there, but progress is slow, because the 
amount of information that's to be seen is quite less.

I do agree that the API issues should be addressed first, but i would 
term this as a chicken and egg situation, where one needs the driver to 
test it as well (the features added in to the API)

The mentioned features (marked TODO) currently are not handled by 
either of the drivers, as far as i can say.

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 API vs. HVR4000: When?

[Johannes Stezenbach]

Hi,

On Tue, Oct 30, 2007, Manu Abraham wrote:
> Johannes Stezenbach wrote:
> > 
> > three weeks have passed since Steve expressed his
> > discomfort with the HVR4000 merge being blocked
> > waiting for multiproto.
> 
> Before i state anything, Current DVB-S2 API status:
[snip]

Thanks, that's useful.

> > Can you give us a time frame for when the multiproto
> > merge will happen?
> > 
> > Or, alternatively, can we split multiproto into
> > two repositories, one with API + dvb-core changes
> > and one (on top of it) with the STB0899 driver?
> 
> It can be either way, which one of the following do you think is better in 
> your view ?
> 
> (1) DVB-S2 API partly merged now and the rest of the S2 API later.
> (2) Complete event list update and VCM and merge that also alongwith.
> 
> in either case it can be with or without the STB0899 driver.
> 
> What do you think ?

I'd prefer to address the remaining API issues first, however
what I primarily want to avoid is that Steve rewrites the
HVR4000 driver to a competing API proposal due to
frustration with the lack of progress.

IMHO there should be a clear path of actions for Steve
(or whoever else wants to help) to do that would allow merging
the HVR4000 driver. I.e. instead of having to wait for some
event beyond his control there should be a checklist, and
the merge can happen when all items are resolved.

Or something like that. Preferably Steve would comment
how he'd like to go forward.


Thanks,
Johannes

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

Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?

[Manu Abraham]

Hi Johannes,

Johannes Stezenbach wrote:
> Hi Manu,
> 
> three weeks have passed since Steve expressed his
> discomfort with the HVR4000 merge being blocked
> waiting for multiproto.
>

Before i state anything, Current DVB-S2 API status:

* CCM (Complete)

* API backward compatibility (Complete, guess it is fine now)
  (I would prefer if Oliver can take a look at it, or maybe you can 
   look at it as well, if you don't think it is a dead horse ;-)  )

* Search Algo status update to the event list 
   (almost there, most probably by tomorrow this will be done)

* Backward Compatible Modes (TODO, including Multiple Logical Streams)

* There are different Error types, not just BER alone. Additionally the S2 
   demod can tell the user whether a demodulation failed (TODO) so that 
   the user gets direct information from the device that a demodulation 
   failed, rather than the user guessing.

* VCM (TODO)

* ACM (Not in current scope)

There was a thread on Backward Compatible modes:
http://article.gmane.org/gmane.linux.drivers.dvb/36981/match=dvb+s2+multiple+logical+ts+same+frequency
http://article.gmane.org/gmane.linux.drivers.dvb/36901/match=dvb+s2+multiple+logical+ts+same+frequency
http://article.gmane.org/gmane.linux.drivers.dvb/36984/match=dvb+s2+multiple+logical+ts+same+frequency

Didn't get a reply from Francesco after that.
Since the scenario is not very clear, i had requested STM to lend a hand, the 
reply was thus:

Manu,

Our software engineer in on vacation right now.  Then I a travelling next
week.  Can you re-contact me on this issue in 2wks time (from 29th onwards).

 
> Can you give us a time frame for when the multiproto
> merge will happen?
> 
> Or, alternatively, can we split multiproto into
> two repositories, one with API + dvb-core changes
> and one (on top of it) with the STB0899 driver?

It can be either way, which one of the following do you think is better in your 
view ?

(1) DVB-S2 API partly merged now and the rest of the S2 API later.
(2) Complete event list update and VCM and merge that also alongwith.

in either case it can be with or without the STB0899 driver.

What do you think ?

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 API vs. HVR4000: When?

[Will Tatam]

I think this tree might be preperation for that (least i'm hoping it is)

http://linuxtv.org/hg/~mchehab/merge

see "[linux-dvb] [RFC] merged tree with newer patch series" thread

Johannes Stezenbach wrote:
> Hi Manu,
> 
> three weeks have passed since Steve expressed his
> discomfort with the HVR4000 merge being blocked
> waiting for multiproto.
> 
> Can you give us a time frame for when the multiproto
> merge will happen?
> 
> Or, alternatively, can we split multiproto into
> two repositories, one with API + dvb-core changes
> and one (on top of it) with the STB0899 driver?
> 
> So that Steve can rebase his HVR4000 driver against
> current API + dvb-core changes and get it merged ASAP.
> 
> 
> Greetings,
> Johannes
> 
> ___
> 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 API vs. HVR4000: When?

[Ian Bonham]

Am also waiting here to see what (if anything) is going to happen.

Ian


On 10/30/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
>
> Hi Manu,
>
> three weeks have passed since Steve expressed his
> discomfort with the HVR4000 merge being blocked
> waiting for multiproto.
>
> Can you give us a time frame for when the multiproto
> merge will happen?
>
> Or, alternatively, can we split multiproto into
> two repositories, one with API + dvb-core changes
> and one (on top of it) with the STB0899 driver?
>
> So that Steve can rebase his HVR4000 driver against
> current API + dvb-core changes and get it merged ASAP.
>
>
> Greetings,
> Johannes
>
> ___
> 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

[linux-dvb] DVB-S2 API vs. HVR4000: When?

[Johannes Stezenbach]

Hi Manu,

three weeks have passed since Steve expressed his
discomfort with the HVR4000 merge being blocked
waiting for multiproto.

Can you give us a time frame for when the multiproto
merge will happen?

Or, alternatively, can we split multiproto into
two repositories, one with API + dvb-core changes
and one (on top of it) with the STB0899 driver?

So that Steve can rebase his HVR4000 driver against
current API + dvb-core changes and get it merged ASAP.


Greetings,
Johannes

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