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

Manu Abraham abraham.manu at gmail.com
Wed Oct 31 20:32:18 CET 2007

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, it was initiated by someone as a quick method for 
being lazy. See how much issues we had because of that.

many more examples, but the quick ones that came to my mind.

Why/what i mean partial as in (1) there are different ways, how backward compatibility is 
achieved. The specs don't specify it is just one method. There are more than one 
possible method by which this is possible. One might argue this is a thing for the future.
No, it is not, we already have those transmissions and currently we can't tune to them.
(this is one of the aspects that i mentioned in the previous mail)

Maybe, for the HVR4000 this might not be useful, but for DVB-S2 devices these are valid
features that are in use. Once you get application developers to go on things based on
certain facts, later it will be hard to change them (there are lot of examples around)
(Such things lead to broken implementations)

I would like people to really think about this, and give a feedback based on the same and
rather not jump into quick conclusions which might help a vendor or so, but eventually it is
a large damage to the Linux devices for the future too. At least, we should learn from the
past mistakes as valuable learning lessons, rather than thinking that let's do something
quick. I am really open to (1) or (2) But let's not jump into wrong things because it benefits 
a vendor in the short period, thereby a repeat of history. This eventually leads to people
"commenting that it works in Windows, it doesn't work in Lunix ?"

With regards to your workflow, to get you going, If you see the tree, many people have been 
sending me changesets, where i apply them as it is, or cherry pick from it but if you aren't 
comfortable with that, you can work on a branch where eventually it can merged back and 


More information about the linux-dvb mailing list