login
Search
they're heavy into moving the whole framework over as far as I've seen those are pullable now against the current tree? Markus --
Using the same interface, the same applications will work there as well which is a bonus, but isn't the existing user interface GPL ? (A bit These devices, depend upon the DVB API update without which it wouldn't work as they depend heavily on the DVB API framework. Without the updated framework, it doesn't make any sense to pull them: they won't even compile. The last but not least reason is that, the stb0899 driver is a DVB-S2 multistandard device which requires DVB-S2/DSS support additionally. Regards, Manu --
I think it's good to have something that competes with Linux, I talked to some guys at that front too, and they seem to work close with application developers too As for the em28xx driver I agreed with pushing all my code (in case of linux, which includes unmerged independent drivercode from manufacturers) into their system as far as I understood here it's that alot code is already available and has been tested for a couple of years, a few guys are trying to run their own game since they already have "some" code, and the problem is that people would have to port your drivers to the other system without your support. We've seen the same issue with the em28xx a year ago, although this one is participating at the BSD and OSX project now too (which takes the same source and makes alot more sence in terms of contributions). As soon as the em28xx code supports the mt2060 and saa7114 devices it would be ready to go into the kernel again separated from linuxtv... Markus --
Something that competes with Linux, absolutely, I could not agree more - especially if the licenses are compatible and cross O/S pollination of ideas/code can occur. Everyone benefits from this. Hauppauge had a guy from the BSD community contact us and ask for datasheets for certain parts. Part of the problem, as I understand it, is that the BSD folks can't port the GPL license into BSD because it's not compatible. I owe it to myself to spend somehime reading the BSD licencing. Maybe the GPL is compatible with BSD. Just my 2 cents. - Steve --
so the framework is available, and the drivers could be pushed in right afterwards, I wonder who is willing to port those drivers to the other API (including testing). It's not going to happen any time soon I guess, if there's not an agreement with Manu's work. Dumping this code would show another step of ignorance and selfishness against the people who worked on it. Markus --
Me. I'll port the 3200 cards and their derivatives, including the 6100 and the 0899. I've already said I'd do that.... but it's manu's code and The demod/tuners drivers would be merged with S2API within a few days. I have a TT-3200 here. I'd have to re-write various things, and change the demod API a little. but I'm prepared to do that. Judging by the positive response we're having to the S2API tree, I suspect a number of people will be willing to offer patches, test time and support. - Steve --
The STB0899 based devices are much different from the crappy handicapped Hauppauge S2 cards and hence the API that you work upon is quite limited to what you see with regards to the Hauppauge (CX24116 based) cards. Even the bare specifications from Conexant point to a handicapped DVB-S2 demodulator. Attempts to do so, will break those devices at least for most of the features and more yet to come. The DVB-S2 transport is a bit more advanced delivery system than what your API based on the CX24116 demodulator. At least it will be great for Hauppauge as you can point to people that Hauppauge hardware is much better, for the marketing aspects as you have done in the past on IRC lists. Very good marketing strategy, Steven keep it up, you have earned more sales for the Hauppauge cards ... Just having a TT 3200 won't help working on the STB0899. Almost everyone who has a STB0899 based knows that, except you. No need for you to break the compliant devices in favour of your mediocre cards. As i wrote just above, the STB0899 is not the only one device using the said features. Also i can guarantee that the CX24116 (HVR4000) is the most handicapped DVB-S2 device that you are basing the DVB-S2 API on: and i can guarantee that what you do will be just be broken as you have done for other devices in the past. Also i do not understand, why you have to make a lot of noise to port the STB0899 drivers to your crap, when all your cards work as expected by you with the multiproto tree. I don't see any reason why the STB0899 has to be ported to the handicapped API of yours, handicapping the STB0899 based devices. HTH Manu --
Manu, Though I can't read much German, after looking at the jusst.de website I can't help but think that you as well have financial interests driving your actions. If so, then your statements display quite a bit of hypocrisy. Manipulating (i.e. stalling) the timing of Multiproto being merged into the v4l-dvb tree or kernel, for you or your employer's gain, would be little different from the motivations you allege Steve of having. Since the major gripe I'm reading on the list "is that multiproto has taken too long" and since it seems to me the only thing that shook it loose was a competing proposal, please save the venom for when you actually have some clear moral high-ground to stand on. I don't see it from here. As for the technical superiority of either API proposal; that probably just doesn't matter. I've seen policy/political decisions force suboptimal technical solutions at work time and time again. If you really believe you have a superior product technically; then perhaps you should work to make it superior politically as well. Mud-slinging can't be a good long term strategy toward that end. Regards, Andy --
Andy, To your utter disappointment as i should say, i am not working for any vendor, but just get device support out to the community. The jusst.de domain is owned by Julian Scheel who runs Jusst Technologies, just happened to offer me hosting for me repositories for my work, using full ssh access, so that my workflow is easier. Not that i have anything to do with jusst.de otherwise. OTOH, i do have the patches at kernel.org Maybe Julian can comment on this to make things more clearer on the I am not manipulating any timing of multiproto being merged. In fact i had been away, for a few months due to certain reasons, that you are perfectly aware by now as far as i can understand. So the points that I don't have to do any mud-slinging, just wrote the exact facts out here. Regards, Manu --
Conexant themselves mentions what their demodulators can do. (In fact, they stopped their satellite demodulator businesses and sold it to NXP, AFAIK) I don't know what you want to add more into it, what Conexant hasn't. Only basic 8PSK NBC mode of operation. The DVB-S2 specification True it is. Regards, Manu --
Andy, you are straight into it, at the point. Don't believe any other, or say it was me, giving you a bad hint. Hermann --
Andy, A piece that i forgot to write. Just like what you said, i too can't read German that much what you can even. Regards, Manu --
Andy, just to clarify things a bit I'll give a short statement now. The role of jusst technologies in the whole multiproto story is as following: The time when DVB-S2 came up this was of course of major interest for jusst technologies, so we searched for people working on drivers. At that not many people did seem to care about this stuff - but Manu did. So we got in contact and tried to help him as much as we can, which included making up connections to KNC1 for technical questions and datasheets, provide a KNC1 testing board and later then give free web/codespace to Manu. Furthermore we of course did lots of testing of multiproto. But never we did pay Manu for any of this work. Reading that you should recognize that there can't be much financial interests for Manu. Seeing that you impute hyprocrisy to Manu due to "facts" you don't have proven in any way makes me a bit contemplative. I don't like being political when talking about technical terms (which linuxtv in first place should be about imho) - anyway this one time I will give a somewhat political statement, too. All you guys who are blaming Manu to do some wrong or bad stuff, what is your point? - I see you searching quote where Manu did talk in a somewhat unpolite manner just to blame him of being the wrong person introducing a new API? - I have no interest in doing the same quoting with your postings or the so called competitors postings, but I'd bed I could quote almost any of you in a not less distracting manner than you Using "taking too long" as an argument against an API proposal is really interesting. What did you expect? - A quick shot which is not well thought about wouldn't have be a good thing for anyone. I'm absolutely fine if anyone would came up with real technical arguments, but reading many postings so far I couldn't find much of such To be political again: Thank you for blaming jusst being not interested in proper technical solutions. What makes you thinking of this? - Just ...
Julien, In summary, the bottom line is this: Manu did a great job with the multiproto API, people were happy using it, and all of the LinuxDVB developer community was happy with the work that was done, and we all wanted to merge it ~ two years ago. Back then, Manu said that it wasnt ready, so for some time we waited for him in hopes that he would agree that it was ready for merge. As more months went by, Manu was asked if he would be merging his changes, and he kept answering to the effect of "it's not ready yet, but should be in a few weeks" Months and months and months went by since then, with an occasional ping to Manu, with the reply "not ready yet" ... Two years is a very long time to wait for a new API, especially considering that it was functional from the start. It was looking like Manu may not have had any intention at all to merge his work into the master v4l/dvb development repository -- It should be not be surprising at all that Steven Toth felt the need to come up with his own solution. Steven posted a proposal for his API expansion solution, and he received positive feedback. Immediately, Manu broke out of his silence and sent in a pull request. Is there malice here?? No. There is development, and developers looking to move forward. Nobody is at fault. I have posted the above just to clarify what the "politics" actually are, here. The only real politics going around are those that are accusing others of politics themselves. Had Manu been willing to merge his work earlier, this would have all been a non-issue. However, now there is an alternative proposal on the table, which appears to be more robust and may have more potential that the multiproto proposal. Does that mean multiproto is disqualified? Absolutely not. Does the fact that multiproto was there first mean that it will be merged without question now that it is suddenly available? No, not necessarily. What does it mean? It means that now there are two ...
Michael, Thanks for your version of the history. I just have to say I can't really agree with the way you describe the history. To point this out I looked up some of the old threads... So everything started in 2005 with initial proposals for a DVB-S2 extension of the API by Marcel. In early 2006 there were some discussions about it on the lists: http://thread.gmane.org/gmane.linux.drivers.dvb/23914/focus=24030 http://thread.gmane.org/gmane.linux.drivers.dvb/24239 At that thought not much (if any) capable hardware was available, so the idea was put off for the moment. Then in April 2006 Manu started to work at the things and provided a first draft based on the changes from Marcel: http://thread.gmane.org/gmane.linux.drivers.dvb/25401 An initial driver for KNC cards was provided by Manu based on this API proposal. After some discussions on 05 May 2006 Manu requested for a pull of the API: http://www.linuxtv.org/pipermail/v4l-dvb-maintainer/2006-May/001006.html Immediately followed by Johannes stating that he is not satisfied with the API yet and suggested a rework: http://www.linuxtv.org/pipermail/v4l-dvb-maintainer/2006-May/001007.html At that time rework began while in parallel some people (including jusst technologies) started testing the first drivers. As expected they were still far away from running perfect. So it took a while to come to obvious progress. In January 2007 Manu announced the mp-stb0899-c5 tree - not even the current multiproto tree - which included the results of the rework. Some testing was done on that by more people. http://thread.gmane.org/gmane.linux.drivers.dvb/31146/focus=31159 In February Steven came up with initial support for HVR 4000 in the multiproto tree. http://thread.gmane.org/gmane.linux.drivers.dvb/31605/focus=31644 Furthermore at this time the dvb-apps (at least parts of) were started to be extended by multiproto support, so that more people (which do not write their own applications...) could start ...
Julian, thanks for taking the time to dig into the history deeper! As I've stated before, there is much more to the story (both in terms of technical and personal) and it's obvious that certain people are trying to shape the users perception (even if it means misleading them) in order to gain their support. Dirty tactics in my opinion but I guess when you want to win that bad, you will do whatever it takes @ any cost. Best regards. (I apologize if this was posted twice to the ml.) --
Thanks for the detailed (and imho correct) description of the history. CU Oliver -- ---------------------------------------------------------------- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ---------------------------------------------------------------- --
Julian First let me acknowledge jusst technologies contribution. It seems This is where you misrepresent my words: "I can't help but think..." is phrase that doesn't not imply certainty but indicates my *perception*. I did not assert this as fact, as the following statement started "If so, ..." which is a conditional clause. No. It was my ill researched, emotive response to Manu attacking My point was to suggest to Manu that there were more productive ways to further his cause than to throw stones at people. Manu, who you support, BTW, was the one who initially introduced There was no searching involved. That quote was text I cut out in my Let me help you. Please read these postings of mine and give me your honest feedback: http://linuxtv.org/pipermail/linux-dvb/2008-September/028651.html http://linuxtv.org/pipermail/linux-dvb/2008-September/028727.html Are these the emails of someone who doesn't care about the technical aspects? I didn't post them to the LKML because I didn't think the issue needed I said no such thing. The implication was that politics often (tragically IMO) often weigh heavier than technical merit in making decision. This was my recommendation to Manu not to neglect that aspect, lest he get shortchanged. I was trying to help/advise. Maybe Then tell Manu not to initiate with unkind allegations, and he won't evoke the same in return. Again, the horror of the whole mess is what moved me to respond. I couldn't give $0.02 about the new API. I don't think I'll ever need it myself. That's a selfish US user's perspective, but it also I'm sorry if you feel I've somehow injured the name of jusst technologies. That certainly wasn't any intention of mine. Regards, --
I don't doubt it. But holding the members of a whole community as captives over several years is a even much more severe issue. Alone for reading the thousands of mails, how can I build the f*, there is no compensation and that alone is a reason to have serious doubts about such kind of support or keep that out of linuxtv too. To accuse Steve now, his major captive, of something, Manu is far away to even come close to be allowed to do such, if you look at it in whole, is a further proof, that it will never end until he has v4l-dvb :) This would cure him immediately in that direction and I seriously suggested it. The underlying problem is deeper, you can't allow something important, like S2 HDTV support on GNU/Linux, to be in the hand of a single developer and related NDAs. The guy might be as fine like Manu, but what comes down to him from all sides behind the scenes will make even the best soon uncomfortable and others scratch their had, damned, why he always bites and would this ever end? In between others spend their time tracking down some old issue someone is coming back with after years, but on that shiny new driver this will of course never happen again ... Cheers, Hermann --
