Steve,<br>Does this mean you will be working on an alternative to MultiProto? <br>As an HVR4000 user I am following this thread closely as you might imagine.<br><br>Ian<br><br><br><div><span class="gmail_quote">On 11/1/07, 
<b class="gmail_sendername">Steven Toth</b> &lt;<a href="mailto:stoth@linuxtv.org">stoth@linuxtv.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Manu Abraham wrote:<br>&gt; Steven Toth wrote:<br>&gt;&gt; Johannes Stezenbach wrote:<br>&gt;&gt;&gt; Hi,<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; On Tue, Oct 30, 2007, Manu Abraham wrote:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; Johannes Stezenbach wrote:
<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; three weeks have passed since Steve expressed his<br>&gt;&gt;&gt;&gt;&gt; discomfort with the HVR4000 merge being blocked<br>&gt;&gt;&gt;&gt;&gt; waiting for multiproto.<br>&gt;&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt; Before i state anything, Current DVB-S2 API status:<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt; [snip]<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Thanks, that&#39;s useful.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt; Yes.
<br>&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; Can you give us a time frame for when the multiproto<br>&gt;&gt;&gt;&gt;&gt; merge will happen?<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; Or, alternatively, can we split multiproto into
<br>&gt;&gt;&gt;&gt;&gt; two repositories, one with API + dvb-core changes<br>&gt;&gt;&gt;&gt;&gt; and one (on top of it) with the STB0899 driver?<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; It can be either way, which one of the following do you think is
<br>&gt;&gt;&gt;&gt; better in your view ?<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; (1) DVB-S2 API partly merged now and the rest of the S2 API later.<br>&gt;&gt;&gt;&gt; (2) Complete event list update and VCM and merge that also alongwith.
<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; in either case it can be with or without the STB0899 driver.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; What do you think ?<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt; I&#39;d prefer to address the remaining API issues first, however
<br>&gt;&gt;&gt; what I primarily want to avoid is that Steve rewrites the<br>&gt;&gt;&gt; HVR4000 driver to a competing API proposal due to<br>&gt;&gt;&gt; frustration with the lack of progress.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;
<br>&gt;&gt; Agreed.<br>&gt;&gt;<br>&gt;&gt;&gt; IMHO there should be a clear path of actions for Steve<br>&gt;&gt;&gt; (or whoever else wants to help) to do that would allow merging<br>&gt;&gt;&gt; the HVR4000 driver. I.e
. instead of having to wait for some<br>&gt;&gt;&gt; event beyond his control there should be a checklist, and<br>&gt;&gt;&gt; the merge can happen when all items are resolved.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Or something like that. Preferably Steve would comment
<br>&gt;&gt;&gt; how he&#39;d like to go forward.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt; If these are new API&#39;s then I suspect the HVR4000 doesn&#39;t use them. I<br>&gt;&gt; would agree it makes sense to define them, but depending on their focus
<br>&gt;&gt; they may not need to be implemented and should not be considered a<br>&gt;&gt; roadblock to an alpha release.<br>&gt;&gt;<br>&gt;&gt; If they don&#39;t impact core functionality then I see no reason why this<br>
&gt;&gt; cannot be defined now, but implement (and refined) later during the test<br>&gt;&gt; cycle. (I&#39;m expecting testing to be a very long process, because we&#39;ll<br>&gt;&gt; need to encourage the VDR/MythTV/Other applications groups to begin
<br>&gt;&gt; integration).<br>&gt;&gt;<br>&gt;&gt; I am a realist. I don&#39;t expect the first tree will be perfect. I am<br>&gt;&gt; expecting some change. I am expecting apps devs/testers to find bugs and<br>&gt;&gt; problems which will cause us to rethink some parts of the multiproto
<br>&gt;&gt; core and it&#39;s S2 drivers.<br>&gt;&gt;<br>&gt;&gt; No doubt the VDR and MythTV folks will also have something to say and<br>&gt;&gt; that may impact the API also. We need to pay respect to the opinions of<br>
&gt;&gt; the applications developers.<br>&gt;&gt;<br>&gt;&gt; I don&#39;t think the first release needs to be perfect.<br>&gt;&gt;<br>&gt;&gt; I think if the current API is good enough to support the needs of<br>&gt;&gt; Myth/VDR then that&#39;s something we can start with. Release early, release
<br>&gt;&gt; often.<br>&gt;<br>&gt;<br>&gt; It is not how the APi is good enough to support the needs of MythTV or VDR,<br>&gt; but how the API can be considered as a guide for the application developers<br>&gt; to understand how to talk to a DVB-S2 device
<br>&gt;<br>&gt;<br>&gt;&gt; Manu, this is your patch and I respect your work, how would you suggest<br>&gt;&gt; we proceed?<br>&gt;&gt;<br>&gt;<br>&gt; There does exist a ported version of VDR to the new API. The current situation
<br>&gt; is that the S2 devices cannot be tuned to certain frequencies because of the<br>&gt; use of Backward compatible modes, ie the API, nor the drivers currently do<br>&gt; support them.<br>&gt;<br>&gt; Give application developers a chance to mess up stating that the API is out,
<br>&gt; eventually what will happen is: example look at people crying out on<br>&gt; mythtv issues with regards to DVB devices. I have had quite some experiences<br>&gt; trying to make application developers understand what they do wrong.
<br>&gt;<br>&gt; I am waiting to hear from other developers as well, whether they would like to<br>&gt; do whether to do<br>&gt;<br>&gt; (1) partial DVB-S2 API support now and the rest of the DVB-S2 API later.<br>&gt; (2) DVB-S2 API what it needs to tune to all the transponders at least
<br>&gt;<br>&gt; Look, this is not the question of the HVR4000 or the STB0899 alone, it will affect<br>&gt; all future devices. As Johannes said, what goes into the API (user ABI) is permanent,<br>&gt; it won&#39;t change. It is something that will be set in stone as opposed to the driver
<br>&gt; internal API. (The driver API we can change, but not the ABI) What we are looking at<br>&gt; is the API-ABI<br>&gt;<br>&gt; Let me cite certain examples of such large scale screwups where people are stuck:<br>&gt;
<br>&gt;<br><br>You&#39;ve miss-interpreted my comments.<br><br>I suggested that the API should be defined, but not necessarily<br>implemented. I was suggesting that we define enough API to generate a<br>test tree and make some progress. Supporting your earlier statement, I
<br>suggested that the small amount of unimplemented API (which you<br>suggested was inconsequential) could be implemented while other<br>developers were testing the core TV functionality.<br><br>I.e. This becomes a group effort, not a Manu effort.
<br><br>I never suggested the test tree would get merged, in fact I went out of<br>my way to suggest that the process of testing would likely raise various<br>design issues and/or bugs. I clearly outlined that I&#39;m a realist and I
<br>expected this testing phase to cause change.<br><br>I thought I&#39;d made myself clear.<br><br>I ended my previous email respectfully and repeated Linus&#39;s mantra. I<br>was assuming your response would be positive.
<br><br>Instead you&#39;ve launched into a patronizing tirade and none of this<br>ingratiates you with the other developers, it only stands in the way of<br>progress and demonstrates the attitude we&#39;ve witnessed over the last
<br>12-18 months re: multiproto.<br><br>I don&#39;t think I have anything else to say on the subject of multiproto,<br>until you see fit to deliver publically your &#39;marvelous multiproto<br>invention - all things under one roof&#39;, no doubt to the sound of
<br>trumpets, gasps and country wide applause.<br><br>I&#39;m wasting my time here.<br><br>- Steve<br><br><br><br><br>_______________________________________________<br>linux-dvb mailing list<br><a href="mailto:linux-dvb@linuxtv.org">
linux-dvb@linuxtv.org</a><br><a href="http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb">http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb</a><br></blockquote></div><br>