On Tue, Nov 25, 2008 at 5:44 PM, Jelle de Jong <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mauro Carvalho Chehab wrote: >> On Sat, 1 Nov 2008 18:46:40 +0100 >> "Markus Rechberger" <[EMAIL PROTECTED]> wrote: >> >>>> The last attempt was rejected because the patches were adding duplicate >>>> drivers rather than improving the existing ones. >>>> In the same project, 2 drivers managing the same hardware is not correct. >>>> Markus (or another people, why Markus may be the only person to do that?) >>>> should propose patches of the existing drivers, without breaking the >>>> v4l-dvb APIs. >>>> - First, the tuners and video decoders modifications shall be merged since >>>> they are used by several existing drivers. >>>> - Then the em28xx driver shall be improved. >>>> And this is what Markus started (thanks for this initiative) but this is >>>> hard to spend time on these minor things while supporting problems because >>>> of being out-of-kernel. >>>> >>> In case of the cx25843 I discussed it with Hans Verkuil, there's more >>> or less no option since it collides with the existing inkernel driver >>> and disables support for other >>> cx25843 drivers, so as for the kernel it should be merged to the >>> existing one yes. >> >> The same kind of collision exists if we keep both the upstream and your >> version >> of the em28xx driver. This is also true for xc5000 and xc3028 drivers. >> >>> The em28xx driver, the one in the kernel has taken a few patches from >>> my repository, and it has some additional custom patches, it would >>> make more sense to work those >>> few patches into the new em28xx driver which is tested with most devices >>> >>> (compared with the driver which is in the kernel which is likely >>> tested with 5-10% of the devices which are in the cardlist). >> >> The patches should be generated against the upstream driver, not against the >> out-of-tree. >> >> You might use an strategy of first patching the out-of-tree, then patching >> back the >> upstream. This may eventually be used as an intermediate step, but I suspect >> it >> will just make things harder. >> >> Anyway, no matter what process used to generate the patchset, it should be >> generated in a way that it won't cause regressions upstream, and submitted as >> incremental patches properly describing what each patch of the series is >> doing >> (and not just a diff <version a> <version b>). >> >>> As for some reasons why not to merge it back then: >>> * the driver relied on reverse engineered code, which made some >>> devices extremly hot (not even xc3028/xc3028L related). Wrong gpio >>> settings also enable the device to draw more power and affect the >>> signal strength for analog TV/dvb-t, those settings can be custom for >>> every designed device. I have had one pinnacle device which had a >>> slightly melted package because of that mess. >> >> The gpio logic is just a very few lines of code. A simple patch probably can >> fix the issues. >> >>> There are additional em28xx based chipdrivers which only work with >>> em28xx based devices (eg. videology cam). >> >> A patch adding videology cam support would add this functionality upstream. >> >>> The input layer actually fully works although I disabled it because it >>> needs a redesign and shouldn't be exposed to userland like this, also >>> the polling code shouldn't be used (linux timing causes >>> alot trouble at low intervals - especially the deinitialization of >>> such timers, I sent an email to the ML about a possible race condition >>> in ir-kbd-i2c a couple of months ago. >>> netBSD developers discovered that interrupt polling works fine even >>> for remote controls. Practically since I worked alot with remote >>> controls during the last half year returning keyboard input keys >>> to userland is a mess, there was a discussion also with netbsd people >>> about a more generic interface because the IR support of the device >>> should be seen as RC5/RC6/NEC/.. protocol support >>> and not as one interface where the device is bound to a certain remote >>> and only supporting that remote control. >>> (that's just the reason why IR support is disabled :) >> >> Since it is disabled, there's no sense on currently trying to merge your IR >> code. This would be a regression. >> >>>> v4l-dvb people and Markus would be glad to see his drivers in the >>>> mainstream kernel. >>>> >>>>> I am going to ask for understanding of both the side of Markus that >>>>> worked very hard on his code, and that of the upstream developers. There >>>>> are both valid reasons on how they did there things. >>>>> >>>>> But we need a solution to get all the code back into the upstream >>>>> project so it can go into the kernel project and eventually be delivered >>>>> at the Linux distributions and all there users, so no custom compiling, >>>>> custom package install are required and non transparent bug reports can >>>>> be stopped. >>>>> >>>>> Is it possible for an upstream developer to step forward and take on the >>>>> task of merging the code of Markus back into mainstream, all questions >>>>> on the code can be discuses on several mailing-list [2] of choice. >>>>> >>>> Well, I would say: "Make it so!" ;) >>>> >>>>> Current the situation is kind of a hold-of, the issues are not being >>>>> discussed, the problem is not addressed, so no process is made and >>>>> during this time users are suffering from non working nor good supported >>>>> devices for there hybrid dvb-t/analog broadcast experiences under Linux. >>>>> >>>>> I hope this lead to a productive discussion that will get the code to >>>>> the end users through there main distribution systems. >>>>> >>>> I hope so, just to stop these useless discussions that do not discuss on >>>> patches. >>>> >>> the code is there :-) >> >> If you are comfortable of having people converting your code on incremental >> patches and submitting upstream, please stop making personal attacks to the >> ones that are actually doing that ;) >> >> Cheers, >> Mauro > > Time has past since my first mail on this subject, and some small steps > have been made towards integrating the em28xx into the mainstream kernel. > > I first want to state that I have not taken any side in the underneath > issue. I strongly advice to resolve the issues as soon as possible and > maybe take a closer look at the action of the key persons involved. > > I have reasons to be very very concerned! I regularly talk with Markus > through IRC. And I got the feeling he is frustrated about the way things > have gone in the past. If I understand correctly Mauro the current > maintainer started working on linux-tv project around the same time > Markus did and is now kind of dictating what goes into mainstream code. > > Also Markus indicated Mauro took code that Markus developed and did not > follow the GPL rules of providing the copyright and credits to Markus. > So Mauro is "stealing" Markus work, this has made Markus slowly turn > against gpl licensing and Linux development policies. >
this is no issue at all, as already mentioned. > It may have gotten so worse, that Markus currently development is going > to be closed source! Markus is working on an analog and dvb GTK+ viewer > for Linux that will now be mostly released close source. Because Markus > is sick of his code being taken and not getting the credits for his hard > work, so he decided close source development will be an solution that > works for him. > > I am not going into an ethical discussion about the actions made. But I > will say I would hate to see this escalating further and result in a > rejection of a possible productive and vendor supported software > developer that would have been able to release his work under gpl and > contribute to the free software community. > > I personally not use non free sofware, so if this continues the current > patch I will be unable to use the future work of Markus, and there are > still a lot of issues with using dvb and analog systems under linux.... > > Hope this reopens the discussion and helps to resolve the above issues > in a civilized way without hurting the free software community or > creating poisonous people in the community. > I'm too busy especially right now to deal with anything beside my work... Markus _______________________________________________ Em28xx mailing list [email protected] http://mcentral.de/mailman/listinfo/em28xx
