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
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
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
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
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
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
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
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
Ian Bonham wrote:
On 06/11/2007, *Steven Toth* [EMAIL PROTECTED]
mailto:[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
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
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
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
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
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,
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
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 }
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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.
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
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
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
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
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
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]
52 matches
Mail list logo
