Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
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?
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?
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?
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?
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?
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?
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?
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?
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 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 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?
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 automatically). This doesn't impact the
ABI, but mechanisms like this (for future devices) show how
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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 way. There are couple of ways the same thing is done for example. You apply a wrong one and the API is screwed
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
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?
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?
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?
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 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?
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?
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 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 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?
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?
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?
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-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.e. This
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
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?
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?
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?
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?
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 probably a broken device or lack of understanding, for the device that was considered as a reference for the whole API to be based on it. c) V4L devices used to do probing,
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
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 functionality. I.e. This becomes a group effort, not a Manu effort. I never suggested the test tree would get merged, in fact I went out of my way to suggest that the process of testing would likely raise various design issues and/or bugs. I clearly outlined that I'm a realist and I expected
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
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?
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?
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?
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
