On 6/28/07, Sascha Sommer <saschasommer@xxxxxxxxxx> wrote: > Hi, > > On Thursday 14 June 2007 23:05, Markus Rechberger wrote: > > Hi, > > > > since I officially take care about the latest Empia em28xx code I want > > to get that project removed from linuxtv.org. > > Mauro already broke some parts in the incomplete inkernel linux driver. > > Since the few developers here who cannot just shut their mouth and > > accept others work I don't see another way out. > > I will rebase the code a last time and add a binary module interface > > to the em28xx driver to allow the usage of proprietary dvb-t demod and > > tuner code from userspace. Mauro is probably aware of wasting my time, > > and the 3-4 other people who are against 1 1/2 years of work which has > > been done are probably aware either of it. > > > > I will stop any further cooperation with that project since I simply > > don't have the time for all these useless flamewars with people who > > don't know it better. > > > > If opensource isn't entirely possible because of a flawed community > > it's better to go binary. > > > > Can someone please summarize these flamewars and especially the remaining > problems? > Why can you people spend hours reverseegineering all kinds of obfuscated > hardware while not being able to work out a plan to resolve this issue? > This is really a shame. > No, it wasn't very nice to see the em28xx driver (that is based on the > Cinergy > 200 USB driver that I started in 2004) in video4linux cvs without support > for > the cards that were originally supported by the Cinergy driver. However > instead of whining I sent a patch to readd these devices. > I don't see how a em28xx driver that is seperated from video4linux is an > improvement in any way. It's definitelly an improvement to stay out of all these stupid flamewars and any further discussions about improving that framework. > It should have never gotten into this state. > Markus, what will happen with your code? It's intended to go into 2.6.23. > Do you intend to merge it into the > kernel someday later? Won't there be more conflicts? > Why do we suddenly need a binary module interface? there are several advantages: *) easy use of floating point operations *) moving code from kernelspace to userspace, so development of newer drivers can be more relaxed without having to fear to hit kernel null pointers or other similar bugs. *) it will also allow binary userspace modules (eg. for tuners), it's better to provide a proper driver instead of having nothing sometimes. *) some devices require a firmware, so there's no advantage over a kernelspace driver which requires a firmware to work which is not compiled into the driver. *) portability the drivers can be reused with BSD, OSX, etc. > Working 1 1/2 years on your own tree and then expecting everything to be > merged in one big hunk is not fair. don't worry I made alot attempts to get it merged but some guys treat the linuxtv code as their property here. > During this time I also sent you patches > for the em2800 cards that were never added to the mainline kernel because > you > wanted to merge your changes first. What will happen with my patches? they will get in with 2.6.23 > Can't we just get through your patchset and apply the codefixes and work out > the tuner problems afterwards? I already reworked it a 4th time I plan to release the code around next week, this time without a dependency on internal linuxtv API changes; The last options I pointed out to were either they accept my changes and start to test that code including several bugfixes in other files or I will split it off and not submit any fixes to the mainline project anymore. Some guys of that community are just very unfriendly and closed minded, it's better to not rely on anyone here. If a company would have been behind all that they would just have dropped everything or released binary drivers since it makes much more sense at the current situation. The whole driver could have been supported for a year already with the right people. > Your code is not useless. During my tests your version of the em2800 driver > worked much better than the current kernel code. I want that the codebases > get unified again and promise to help during my semester break in august. > I'm afraid if this problem cannot get solved now, solving it in the future > will not be possible either. > You're welcome to join the userspace interface development, for now I only ported the xc3028 (DVB-T/analogue) and mt2060 to userspace. thanks, Markus _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
