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 applied. Regards, Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
