Hi all,
>>> * "The current API doesn't allow you to tune into -S2 transponders."
>> We have solved this one already, drivers also exists, people watch S2
According to the DVB-S2 specification, there can be multiple logical TS's
within a single TS alone.
>From the specification and the STB0899
Manu Abraham wrote:
> Hi,
>
> Simon Hailstone wrote:
>> Hi All,
>>
>> If it sheds any light on the nature of DVB-ASI, there are Linux drivers
>> available ( with source ) for the DekTec ASI adapters here :
>>
>> http://www.dektec.com/Products/LinuxSDK/Downloads/LinuxSDK.zip
>>
>
> If someone has
Hi,
Simon Hailstone wrote:
> Hi All,
>
> If it sheds any light on the nature of DVB-ASI, there are Linux drivers
> available ( with source ) for the DekTec ASI adapters here :
>
> http://www.dektec.com/Products/LinuxSDK/Downloads/LinuxSDK.zip
>
If someone has the hardware, we can take a go at
Hi All,
If it sheds any light on the nature of DVB-ASI, there are Linux drivers
available ( with source ) for the DekTec ASI adapters here :
http://www.dektec.com/Products/LinuxSDK/Downloads/LinuxSDK.zip
Best Regards,
Simon Hailstone
On 16/09/2007, Wolfgang Wegner <[EMAIL PROTECTED]> wrote:
>
>
> " In 1998 the Technotrend GmbH develops the still very popular PC DVB
> card with a full-
> featured STB processor on it. In 1999 Siemens produces a card based on
> the Technotrend
> design"
>
> However, Manu recounts, and other things that I have seen written
> collaborate with his recollection
Michael Hunold wrote:
> Hello all,
>
> before taking part of this discussion, please make sure to have read the
> v4 wiki page:
>
> http://www.linuxtv.org/wiki/index.php/Linux_DVB_API_Version_4
>
> In particular, please read the most recent Linux DVB API v4 documentation:
>
> http://linuxtv.org/dow
I cannot resist ;-)
since I stumbled over the RCU documentation I seriously would like to
invite several linuxtv people (especially Steven Stoth, Mauro Chehab,
Michael Krufky, Manu Abraham last but not least myself [but I read
already it] ;-) to read about RCU...
"RCU is a synchronization mechani
On 9/20/07, Steven Toth <[EMAIL PROTECTED]> wrote:
> Markus Rechberger wrote:
> > On 9/19/07, hermann pitton <[EMAIL PROTECTED]> wrote:
> >
> >> Am Dienstag, den 18.09.2007, 19:07 +0400 schrieb Manu Abraham:
> >>
> >>> Mauro Carvalho Chehab wrote:
> >>>
> Em Ter, 2007-09-18 às 18:33 +0400, Man
Markus Rechberger wrote:
> On 9/19/07, hermann pitton <[EMAIL PROTECTED]> wrote:
>
>> Am Dienstag, den 18.09.2007, 19:07 +0400 schrieb Manu Abraham:
>>
>>> Mauro Carvalho Chehab wrote:
>>>
Em Ter, 2007-09-18 às 18:33 +0400, Manu Abraham escreveu:
> Mauro Carval
Am Mittwoch, den 19.09.2007, 10:24 +0200 schrieb Markus Rechberger:
> On 9/19/07, hermann pitton <[EMAIL PROTECTED]> wrote:
> > Am Dienstag, den 18.09.2007, 19:07 +0400 schrieb Manu Abraham:
> > > Mauro Carvalho Chehab wrote:
> > > > Em Ter, 2007-09-18 às 18:33 +0400, Manu Abraham escreveu:
> > > >
On 9/19/07, hermann pitton <[EMAIL PROTECTED]> wrote:
> Am Dienstag, den 18.09.2007, 19:07 +0400 schrieb Manu Abraham:
> > Mauro Carvalho Chehab wrote:
> > > Em Ter, 2007-09-18 às 18:33 +0400, Manu Abraham escreveu:
> > >> Mauro Carvalho Chehab wrote:
> > >
> > >>> I'm just interested on see things
Am Dienstag, den 18.09.2007, 19:07 +0400 schrieb Manu Abraham:
> Mauro Carvalho Chehab wrote:
> > Em Ter, 2007-09-18 às 18:33 +0400, Manu Abraham escreveu:
> >> Mauro Carvalho Chehab wrote:
> >
> >>> I'm just interested on see things moving forward. Please stop with your
> >>> flame wars. If you a
Felix Domke wrote:
>>> Why don't abstract the dvb layer from enduser applications and put a
>>> general library infront which does that version check and tries to
>>> keep things consistend to the end applications?
>> It is a nice idea, yes.
>> Two things, looking at
>> http://linuxtv.org/hg/dvb-ap
>> Why don't abstract the dvb layer from enduser applications and put a
>> general library infront which does that version check and tries to
>> keep things consistend to the end applications?
> It is a nice idea, yes.
> Two things, looking at
> http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/
Christophe Thommeret wrote:
> Le mardi 18 septembre 2007 18:41, Aidan Thornton a écrit :
>> On 9/18/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
>>> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
Markus Rechberger wrote:
> Hi,
>
>
> Why don't abstract the dvb layer fro
Le mardi 18 septembre 2007 18:41, Aidan Thornton a écrit :
> On 9/18/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> > On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> > > Markus Rechberger wrote:
> > > > Hi,
> > > >
> > > >
> > > > Why don't abstract the dvb layer from enduser applications
On 9/18/07, Aidan Thornton <[EMAIL PROTECTED]> wrote:
> On 9/18/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> > On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> > > Markus Rechberger wrote:
> > > > Hi,
> > > >
> > > >
> > > > Why don't abstract the dvb layer from enduser applications and
On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> Markus Rechberger wrote:
> > On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> >> Markus Rechberger wrote:
> >>> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> Markus Rechberger wrote:
> > On 9/18/07, Manu Abraham <[EMAIL PRO
On 9/18/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> > Markus Rechberger wrote:
> > > Hi,
> > >
> > >
> > > Why don't abstract the dvb layer from enduser applications and put a
> > > general library infront which does that version check an
Markus Rechberger wrote:
> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>> Markus Rechberger wrote:
>>> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
Markus Rechberger wrote:
> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>> Markus Rechberger wrote:
>>> Hi,
On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> Markus Rechberger wrote:
> > On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> >> Markus Rechberger wrote:
> >>> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> Markus Rechberger wrote:
> > Hi,
> >
> >
> > Why don'
Marcel Siegert wrote:
> Markus Rechberger schrieb:
> ---snip---
>
>>
>> Why don't abstract the dvb layer from enduser applications and put a
>> general library infront which does that version check and tries to
>> keep things consistend to the end applications?
>> The enduser applications would ha
Markus Rechberger wrote:
> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>> Markus Rechberger wrote:
>>> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
Markus Rechberger wrote:
> Hi,
>
>
> Why don't abstract the dvb layer from enduser applications and put a
> gen
On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> Markus Rechberger wrote:
> > On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> >> Markus Rechberger wrote:
> >>> Hi,
> >>>
> >>>
> >>> Why don't abstract the dvb layer from enduser applications and put a
> >>> general library infront which d
Markus Rechberger schrieb:
---snip---
>
> Why don't abstract the dvb layer from enduser applications and put a
> general library infront which does that version check and tries to
> keep things consistend to the end applications?
> The enduser applications would have to implement that API one tim
Felix Domke wrote:
> BTW, this doesn't hold my "backward compatibility" request - if an
> application wants to tune a dvb-s transponder with the new api
> (DVBFE_SET_PARAMS), it won't run against an old api (which only
> implements FE_SET_FRONTEND, but could technically tune). But it seems
> that
Mauro Carvalho Chehab wrote:
> Em Ter, 2007-09-18 às 18:33 +0400, Manu Abraham escreveu:
>> Mauro Carvalho Chehab wrote:
>
>>> I'm just interested on see things moving forward. Please stop with your
>>> flame wars. If you are not interested on serious discussions, you
>>> shouldn't have started th
Markus Rechberger wrote:
> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>> Markus Rechberger wrote:
>>> Hi,
>>>
>>>
>>> Why don't abstract the dvb layer from enduser applications and put a
>>> general library infront which does that version check and tries to
>>> keep things consistend to th
Em Ter, 2007-09-18 às 18:33 +0400, Manu Abraham escreveu:
> Mauro Carvalho Chehab wrote:
> > I'm just interested on see things moving forward. Please stop with your
> > flame wars. If you are not interested on serious discussions, you
> > shouldn't have started the thread.
>
> (bla, bla, bla)
If
On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> Markus Rechberger wrote:
> > Hi,
> >
> >
> > Why don't abstract the dvb layer from enduser applications and put a
> > general library infront which does that version check and tries to
> > keep things consistend to the end applications?
>
> It i
Manu Abraham wrote:
> Markus Rechberger wrote:
>> Hi,
>>
>>
>> Why don't abstract the dvb layer from enduser applications and put a
>> general library infront which does that version check and tries to
>> keep things consistend to the end applications?
>
> It is a nice idea, yes.
>
> Two things,
Markus Rechberger wrote:
> Hi,
>
>
> Why don't abstract the dvb layer from enduser applications and put a
> general library infront which does that version check and tries to
> keep things consistend to the end applications?
It is a nice idea, yes.
Two things, looking at
http://linuxtv.org/hg/d
Hi,
On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> Felix Domke wrote:
> > Manu Abraham wrote:
> >>> I'm not against mmap, I'm against using development resources for
> >>> implementing it. I can't see the big show-stopper in this issue.
> >>> So, seriously: Is there anybody here who *needs*
Mauro Carvalho Chehab wrote:
> Em Ter, 2007-09-18 às 17:58 +0400, Manu Abraham escreveu:
>> Mauro Carvalho Chehab wrote:
>> And I think it would be wrong to delay DVB-S2 support until you
>> have all of DVB-H, DVB-T2, etc. properly hammered out.
>>> I have to agree with Johannes. The curren
Felix Domke wrote:
> Manu Abraham wrote:
>>> I'm not against mmap, I'm against using development resources for
>>> implementing it. I can't see the big show-stopper in this issue.
>>> So, seriously: Is there anybody here who *needs* this, based on his own
>>> experience?
>>> If yes, I'll might chan
Em Ter, 2007-09-18 às 17:58 +0400, Manu Abraham escreveu:
> Mauro Carvalho Chehab wrote:
> And I think it would be wrong to delay DVB-S2 support until you
> have all of DVB-H, DVB-T2, etc. properly hammered out.
> >
> > I have to agree with Johannes. The current 2.6 development model is
Manu Abraham wrote:
>> I'm not against mmap, I'm against using development resources for
>> implementing it. I can't see the big show-stopper in this issue.
>> So, seriously: Is there anybody here who *needs* this, based on his own
>> experience?
>> If yes, I'll might change my mind.
> I think it w
Mauro Carvalho Chehab wrote:
And I think it would be wrong to delay DVB-S2 support until you
have all of DVB-H, DVB-T2, etc. properly hammered out.
>
> I have to agree with Johannes. The current 2.6 development model is
> based on "Commit earlier and commit often", as stated by Linus.
>
Felix Domke wrote:
> Manu Abraham wrote:
>> Felix Domke wrote:
>>> And now you try to complicate not only the API but also the device
>>> driver layer again, justified by a few percent CPU saving in a highly
>>> theoretical scenario? (And I doubt that a zero-copy mmap of DMA buffers
>>> fits well t
> > > And I think it would be wrong to delay DVB-S2 support until you
> > > have all of DVB-H, DVB-T2, etc. properly hammered out.
I have to agree with Johannes. The current 2.6 development model is
based on "Commit earlier and commit often", as stated by Linus.
This means that a big trouble can
Manu Abraham wrote:
> Felix Domke wrote:
>> And now you try to complicate not only the API but also the device
>> driver layer again, justified by a few percent CPU saving in a highly
>> theoretical scenario? (And I doubt that a zero-copy mmap of DMA buffers
>> fits well together with hardware demu
Georg Acher wrote:
> On Tue, Sep 18, 2007 at 03:33:25PM +0400, Manu Abraham wrote:
>
>>> I have h.264 playback running on a really slow Geode with 300MHz. For a
>>> 15Mbit/s stream, the TS path from the DMA buffers into user space needs
>>> about 5% CPU with traditional memcpy(). I wouldn't call
On Tue, Sep 18, 2007 at 02:26:13PM +0200, Georg Acher wrote:
> The Reelbox (with the 300MHz) has up to 4 tuners, the NetCeiver can have up
> to 6 tuners (max 40Mbyte/s input rate). I did a lot of profiling
> (oprofile/gprof) on the Geode, so I think I know what multi demods can "do"
> with the syst
Felix Domke wrote:
> Sorry to give my two cents, but...
>
> Manu Abraham wrote:
>> The case of a 20Mbps stream getting recorded is not a great thing. when
>> you have a TS with symbol rate 27.5Msps, (capturing the complete TS) the
>> normal TS itself is about 27Mbps (in a very crude rounded off ca
On Tue, Sep 18, 2007 at 03:33:25PM +0400, Manu Abraham wrote:
> > I have h.264 playback running on a really slow Geode with 300MHz. For a
> > 15Mbit/s stream, the TS path from the DMA buffers into user space needs
> > about 5% CPU with traditional memcpy(). I wouldn't call that optimization
> > w
On Mon, Sep 17, 2007 at 11:17:19PM +0200, Johannes Stezenbach wrote:
> On Mon, Sep 17, 2007, Manu Abraham wrote:
> >
> > If you would like to fix that in V3, i would much appreciate. If you
> > would just like to keep talking only, maybe lets then not talk too much
> > about it.
>
> The recording
Sorry to give my two cents, but...
Manu Abraham wrote:
> The case of a 20Mbps stream getting recorded is not a great thing. when
> you have a TS with symbol rate 27.5Msps, (capturing the complete TS) the
> normal TS itself is about 27Mbps (in a very crude rounded off case)
> So, the situation that
Rudy Zijlstra wrote:
> Manu Abraham wrote:
>> Georg Acher wrote:
>>
>>> On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
>>>
>>>
> The recording filters are exactly the piece from V4 which has the
> "mmap DMA buffers" zero copy API. But to be honest, I don't think
>
Manu Abraham wrote:
> Georg Acher wrote:
>
>> On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
>>
>>
The recording filters are exactly the piece from V4 which has the
"mmap DMA buffers" zero copy API. But to be honest, I don't think
it's important on a PC which
Manu Abraham wrote:
> Janne Grunau wrote:
>
>> On Tuesday 18 September 2007 01:41:04 Manu Abraham wrote:
>>
>>> Johannes Stezenbach wrote:
>>>
On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
> Johannes Stezenbach wrote:
>
>> The
Janne Grunau wrote:
> On Tuesday 18 September 2007 01:41:04 Manu Abraham wrote:
>> Johannes Stezenbach wrote:
>>> On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
Johannes Stezenbach wrote:
> The recording filters are exactly the piece from V4 which has the
> "mmap DMA buf
Georg Acher wrote:
> On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
>
>>> The recording filters are exactly the piece from V4 which has the
>>> "mmap DMA buffers" zero copy API. But to be honest, I don't think
>>> it's important on a PC which can copy > 1GByte/s in RAM. More
>>> in
On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
> > The recording filters are exactly the piece from V4 which has the
> > "mmap DMA buffers" zero copy API. But to be honest, I don't think
> > it's important on a PC which can copy > 1GByte/s in RAM. More
> > interesting would be the
did any of u guys worked on a project called DM100-B for
caribbeandreambox.com?
On 9/17/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>
> Johannes Stezenbach wrote:
> > On Mon, Sep 17, 2007, Steven Toth wrote:
> >> Johannes Stezenbach wrote:
> >>> But after all the discussions, and you and Steve hav
Johannes Stezenbach wrote:
> On Mon, Sep 17, 2007, Steven Toth wrote:
>> Johannes Stezenbach wrote:
>>> But after all the discussions, and you and Steve have written
>>> drivers which I hope prove the API as working, why do you
>>> still think it is experimental? What would it take to make
>>> it n
Johannes Stezenbach wrote:
> On Sat, Sep 15, 2007, Wolfgang Wegner wrote:
>> - dvb_fe_type: DVB-S2 is missing and I personally would also like
>> to see ASI here...
>
> See my other mail, IMHO we should add the ASI defines at
> the same time we merge a driver which uses it.
>
>> - frontend stat
Johannes Stezenbach wrote:
> On Mon, Sep 17, 2007, Manu Abraham wrote:
>> The problem is that, after making something experimental, throwing it
>> out to application authors stating here it is: the API update, again a
>> fix to the API will make anyone furious, nobody wants to keep tinkering
>> for
On Tuesday 18 September 2007 01:41:04 Manu Abraham wrote:
> Johannes Stezenbach wrote:
> > On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
> >> Johannes Stezenbach wrote:
> >>>
> >>> The recording filters are exactly the piece from V4 which has the
> >>> "mmap DMA buffers" zero copy A
Johannes Stezenbach wrote:
> Given that there already is well-discussed API enhancement
> proposal for DVB-S2, affectionately but wrongly called
> "multiproto" (MPE?), I don't know why you don't get this
> merged first instead of making that task bigger and have
> everyone wait longer for the end
Johannes Stezenbach wrote:
> On Tue, Sep 18, 2007, Manu Abraham wrote:
>> Johannes Stezenbach wrote:
>>
>>> I really don't think there is any problem in releasing API version 3.3
>>> with DVB-S2 support now, then 3.4 with DVB-H, then 3.5 with DVB-T2 etc.
>>>
>>> And I think it would be wrong to del
Johannes Stezenbach wrote:
> On Tue, Sep 18, 2007, Manu Abraham wrote:
>> Of course linuxtv.org being your private server (which you indirectly
>> said in one of the mails) doesn't mean that you can just talk whatever
>> you want
>
> ???
>
>> I do feel so upset talking about such things. It is su
Johannes Stezenbach wrote:
> On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
>> Johannes Stezenbach wrote:
>>
If you would like to fix that in V3, i would much appreciate. If you
would just like to keep talking only, maybe lets then not talk too much
about it.
>>> The r
On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
> Johannes Stezenbach wrote:
>
> >> If you would like to fix that in V3, i would much appreciate. If you
> >> would just like to keep talking only, maybe lets then not talk too much
> >> about it.
> >
> > The recording filters are exac
On Tue, Sep 18, 2007, Manu Abraham wrote:
>
> Of course linuxtv.org being your private server (which you indirectly
> said in one of the mails) doesn't mean that you can just talk whatever
> you want
???
> I do feel so upset talking about such things. It is such a pathetic
> state, that the so c
On Tue, Sep 18, 2007, Manu Abraham wrote:
> Johannes Stezenbach wrote:
>
> > I really don't think there is any problem in releasing API version 3.3
> > with DVB-S2 support now, then 3.4 with DVB-H, then 3.5 with DVB-T2 etc.
> >
> > And I think it would be wrong to delay DVB-S2 support until you
>
On Mon, Sep 17, 2007, Steven Toth wrote:
> Johannes Stezenbach wrote:
>>
>> But after all the discussions, and you and Steve have written
>> drivers which I hope prove the API as working, why do you
>> still think it is experimental? What would it take to make
>> it non-experimental?
>
> My take on
Johannes Stezenbach wrote:
> On Mon, Sep 17, 2007, Manu Abraham wrote:
>> The problem is that, after making something experimental, throwing it
>> out to application authors stating here it is: the API update, again a
>> fix to the API will make anyone furious, nobody wants to keep tinkering
>> for
Johannes Stezenbach wrote:
>> If you would like to fix that in V3, i would much appreciate. If you
>> would just like to keep talking only, maybe lets then not talk too much
>> about it.
>
> The recording filters are exactly the piece from V4 which has the
> "mmap DMA buffers" zero copy API. But
Johannes Stezenbach wrote:
* ARIB extensions
>>> I don't see anyone writing a driver using that, so why bother?
>>>
>> Someone asked me over IRC a few weeks back on a demod, moreover i have a
>> 13 seg tuner. (You have the sources for that driver from me, currently)
>
> Last time I looked th
Johannes Stezenbach wrote:
>>> See? Keep it simple. Do just one thing at a time.
>> I don't see it.
>
> I hope my explanations made it easier to see.
> Do you see it now?
I still don't see it. Did you not read my first reply to you ?
Manu
___
linux-
Johannes Stezenbach wrote:
>> As i said, will you take charge in fixing the demuxer
>> for complete S2 as well as other protocols ?
>> (Since you had a larger hand in the whole mess created, what i mean here
>> is that you maintained DVB for a long while)
>
> Nice try. :-) No I won't implement an
Johannes Stezenbach wrote:
> I really don't think there is any problem in releasing API version 3.3
> with DVB-S2 support now, then 3.4 with DVB-H, then 3.5 with DVB-T2 etc.
>
> And I think it would be wrong to delay DVB-S2 support until you
> have all of DVB-H, DVB-T2, etc. properly hammered out
Johannes Stezenbach wrote:
> On Mon, Sep 17, 2007, Manu Abraham wrote:
>
>> The problem is that, after making something experimental, throwing it
>> out to application authors stating here it is: the API update, again a
>> fix to the API will make anyone furious, nobody wants to keep tinkering
>
On Mon, Sep 17, 2007, Manu Abraham wrote:
>
> The problem is that, after making something experimental, throwing it
> out to application authors stating here it is: the API update, again a
> fix to the API will make anyone furious, nobody wants to keep tinkering
> forever on the same thing.
Exact
On Mon, Sep 17, 2007 at 06:02:50PM +0200, Johannes Stezenbach wrote:
> On Sat, Sep 15, 2007, Wolfgang Wegner wrote:
> >
> > - dvb_fe_type: DVB-S2 is missing and I personally would also like
> > to see ASI here...
>
> See my other mail, IMHO we should add the ASI defines at
> the same time we me
Johannes Stezenbach wrote:
> I think this API sucks. DVB API V1 had a "read/write demod register"
> ioctl for debugging, which was removed because you could also use
> i2c-dev. It would be better to find a way to use i2c-dev with
> proper locking wrt fe->sem than to cram arbitrary and probably
> u
Johannes Stezenbach wrote:
> On Sun, Sep 16, 2007, Rainer.scherg wrote:
>> - A runtime version check of the API is needed. Currently the API
>> version is determined at compile time, which is useless, when
>
> It is necessary in the same way as you have KERNEL_VERSION
> or GLIB_MAJOR_VERSION
Johannes Stezenbach wrote:
>
> Someone once told me: Marketing requirement is that the
> signal quality bar is in the upper third when the picture
> is good, and in the lower third when the picture is bad.
> Everthing else is irrelevant and the numbers can be pure fantasy.
> And that's what I bel
Johannes Stezenbach wrote:
> Hi Manu,
>
> On Sat, Sep 15, 2007, Manu Abraham wrote:
>> While being on the V3 frontend API overhaul, i found to much dismay that
>> it would be much better to revamp V4 into a newer API version such as
>> V5, rather than scratching with V3 for ages together, resultin
On Sat, Sep 15, 2007, Wolfgang Wegner wrote:
>
> - dvb_fe_type: DVB-S2 is missing and I personally would also like
> to see ASI here...
See my other mail, IMHO we should add the ASI defines at
the same time we merge a driver which uses it.
> - frontend status:
> - BER is lacking a proper def
On Sun, Sep 16, 2007, Rainer.scherg wrote:
>
> - A runtime version check of the API is needed. Currently the API
> version is determined at compile time, which is useless, when
It is necessary in the same way as you have KERNEL_VERSION
or GLIB_MAJOR_VERSION etc.
> distributing binaries
Hi Manu,
On Sat, Sep 15, 2007, Manu Abraham wrote:
>
> While being on the V3 frontend API overhaul, i found to much dismay that
> it would be much better to revamp V4 into a newer API version such as
> V5, rather than scratching with V3 for ages together, resulting in just
> unnecessary talks and
Wolfgang Wegner wrote:
> On Mon, Sep 17, 2007 at 03:38:12PM +0400, Manu Abraham wrote:
>> Right.
>>
>> Do you think we can generalize it to a DUMMY frontend where some fields
>> are just queried ?
>>
>> If so it would be a matter of just defining a "dummy name" for the
>> general category of headle
On Mon, Sep 17, 2007 at 03:38:12PM +0400, Manu Abraham wrote:
>
> Right.
>
> Do you think we can generalize it to a DUMMY frontend where some fields
> are just queried ?
>
> If so it would be a matter of just defining a "dummy name" for the
> general category of headless devices where some stati
Wolfgang Wegner wrote:
> On Mon, Sep 17, 2007 at 02:57:32PM +0400, Manu Abraham wrote:
>> CityK wrote:
>>> Its described in:
>>>
>>> "/EN 50083-9:2002 : //Cable networks for television signals, sound
>>> signals and interactive services. Part 9: Interfaces for CATV/SMATV
>>> head-ends and similar
Hi Wolfgang,
Wolfgang Wegner wrote:
> Hi Manu,
>
> On Sun, Sep 16, 2007 at 02:17:55AM +0400, Manu Abraham wrote:
>> Please don't remove the CC's. The CC'd people generally don't bother
>> about mails from the ML, probably.
>
> sorry, it was definitely not my intention and I hope to include
> all
On Mon, Sep 17, 2007 at 02:57:32PM +0400, Manu Abraham wrote:
> CityK wrote:
> > Its described in:
> >
> > "/EN 50083-9:2002 : //Cable networks for television signals, sound
> > signals and interactive services. Part 9: Interfaces for CATV/SMATV
> > head-ends and similar professional equipment fo
CityK wrote:
> Wolfgang Wegner wrote:
>
>> - dvb_fe_type: DVB-S2 is missing and I personally would also like
>> to see ASI here...
>>
> Its described in:
>
> "/EN 50083-9:2002 : //Cable networks for television signals, sound
> signals and interactive services. Part 9: Interfaces for CATV/SM
CityK wrote:
> Its described in:
>
> "/EN 50083-9:2002 : //Cable networks for television signals, sound
> signals and interactive services. Part 9: Interfaces for CATV/SMATV
> head-ends and similar professional equipment for DVB/MPEG2 transport
> streams. "
> /
>
> //which is available (if you're
Wolfgang Wegner wrote:
> - dvb_fe_type: DVB-S2 is missing and I personally would also like
> to see ASI here...
>
Manu Abraham wrote:
> Can you please point me to some ASI specs if you don't mind ? I was
> once supposed to work on such a device, but then that company itself got
> scrapped,
Hi Wolfgang,
Wolfgang Wegner wrote:
> Hi Manu,
>
> On Sun, Sep 16, 2007 at 02:17:55AM +0400, Manu Abraham wrote:
>> Please don't remove the CC's. The CC'd people generally don't bother
>> about mails from the ML, probably.
>
> sorry, it was definitely not my intention and I hope to include
> all
Rainer.scherg wrote:
> Manu Abraham schrieb:
>
>>> - a "user structure" for hardware specific data (e.g. retrieve
>>> special data from a special frontend chip would be nice.
>>> this should be optional (*NULL = not used or not implemented).
>>> otherwise something like:
>>>s
Marcel Siegert schrieb:
>>> Is that what you meant, guess i didn't follow you correctly.
>> Following scenario (SAT):
>>Application 1 tunes device 2:
>> to freq 1234.567 MHz, V, HiBand, SAT "2", etc..
>>Application 2 tunes device 2:
>> to freq 1000.123 MHz, H, LoBand, SAT "1"
Manu Abraham schrieb:
>
>> - a "user structure" for hardware specific data (e.g. retrieve
>> special data from a special frontend chip would be nice.
>> this should be optional (*NULL = not used or not implemented).
>> otherwise something like:
>>struct { char[xx] hw_info;
Hi Manu,
On Sun, Sep 16, 2007 at 02:17:55AM +0400, Manu Abraham wrote:
> Please don't remove the CC's. The CC'd people generally don't bother
> about mails from the ML, probably.
sorry, it was definitely not my intention and I hope to include
all previous CC here.
[have to read about the multipr
On Sunday 16 September 2007, Rainer.scherg wrote:
hi rainer,
> Manu Abraham schrieb:
>
> >
> >> - a "user structure" for hardware specific data (e.g. retrieve
> >> special data from a special frontend chip would be nice.
> >> this should be optional (*NULL = not used or not implemente
Hi,
Rainer.scherg wrote:
> Some quick thoughts:
>
> - the new API should support the DVB API v3.x as an "API layer".
> Otherwise it will take a long time, to get most dvb applications
> running on the new API, which would make it hard to replace the
> current API.
>
We can have com
Some quick thoughts:
- the new API should support the DVB API v3.x as an "API layer".
Otherwise it will take a long time, to get most dvb applications
running on the new API, which would make it hard to replace the
current API.
- A runtime version check of the API is needed. Curre
Hi,
Wolfgang Wegner wrote:
> Hi,
>
> how should this discussion take place?
>
Your valuable comments, whatever it is in a positive way can lead to a
good discussion. :)
Please don't remove the CC's. The CC'd people generally don't bother
about mails from the ML, probably.
> Up to now, my pers
Hi,
how should this discussion take place?
Up to now, my personal experience showed only some drawbacks in the
frontend API, and reading the current proposal v4_0.3 I have some
comments/questions concerning this part:
- dvb_fe_type: DVB-S2 is missing and I personally would also like
to see ASI
1 - 100 of 102 matches
Mail list logo
