Hi Steve, On Friday 29 August 2008 20:29:30 Steven Toth wrote: > Regarding the multiproto situation: > > A number of developers, maintainers and users are unhappy with the > multiproto situation, actually they've been unhappy for a considerable > amount of time. The linuxtv developer community (to some degree) is seen > as a joke and a bunch in-fighting people. Multiproto is a great > demonstration of this. [1] The multiproto project has gone too far, for > too long and no longer has any credibility in the eyes of many people. > > In response, a number developers have agreed that "enough is enough" and > "it's time to take a new direction", for these developers the technical, > political and personal cost of multiproto is too high. These developers > have decided to make an announcement. > > Mauro Chehab, Michael Krufky, Patrick Boettcher and myself are hereby > announcing that we no longer support multiproto and are forming a > smaller dedicated project group which is focusing on adding next > generation S2/ISDB-T/DVB-H/DVB-T2/DVB-SH support to the kernel through a > different and simpler API. > > Basic patches and demo code for this API is currently available here. > > http://www.steventoth.net/linux/s2 > > Does it even work? Yes > Is this new API complete? No > Is it perfect? No, we've already had feedback on structural and > namingspace changes that people would like to see. > Does it have bugs? Of course, we have a list of things we already know > we want to fix. > > but ... > > Is the new approach flexible? Yes, we're moving away from passing fixed > modulation structures into the kernel. > Can we add to it without breaking the future ABI when unforseen > modulations types occur? Yes > Does it preserve backwards compatibility? Yes > Importantly, is the overall direction correct? Yes > Does it impact existing frontend drivers? No. > What's the impact to dvb-core? Small. > What's the impact to application developers? None, unless an application > developer wants to support the new standards - binary compatibility! > > We want feedback and we want progress, we aim to achieve it. Feedback is no problem :-) I noticed that the properties work very similar as to how extended controls work in v4l: http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html#VIDIOC-G-EXT-CTRLS It might be useful to compare the two. I would recommend adding a few reserved fields, since that has proven to be very useful in v4l to make the API more future proof. Also: is setting multiple properties an atomic action? E.g. if one fails, are all other changes rolled back as well? And how do you give the caller feedback on which property in the list failed? Will there also be a TRY_PROPERTIES variant which just checks for correctness without actually setting it? How do you query/test whether a device has certain properties? Do you need separate get and set commands? Why not either set or get a list of properties, and setting them implies an automatic SEQ_COMPLETE at the end. By having a variable length array of properties you do not need to set the properties in multiple blocks of 16, so that simplifies the API as well. As I said, extended controls in v4l do something very similar. I thought about the extended controls a great deal at the time, so it might provide a handy comparison for you. > Importantly, this project group seeks your support. > > If you also feel frustrated by the multiproto situation and agree in > principle with this new approach, and the overall direction of the API > changes, then we welcome you and ask you to help us. > > Growing the list of supporting names by 100%, and allowing us to publish > your name on the public mailing list, would show the non-maintainer > development community that we recognize the problem and we're taking > steps to correct the problem. We want to make LinuxTV a perfect platform > for S2, ISDB-T and other advanced modulation types, without using the > multiproto patches. > > We're not asking you for technical help, although we'd like that :) , > we're just asking for your encouragement to move away from multiproto. > > If you feel that you want to support our movement then please help us by > acking this email. > > Regards - Steve, Mike, Patrick and Mauro. > > Acked-by: Patrick Boettcher <pb@xxxxxxxxxxx> > Acked-by: Michael Krufky <mkrufky@xxxxxxxxxxx> > Acked-by: Steven Toth <stoth@xxxxxxxxxxx> > Acked-by: Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> > > * [1]. Rather than point out the issues with multiproto here, take a > look at the patches and/or read the comments on the mailing lists. While I am no dvb expert I do think that this is a good and simple approach that should be reasonably future proof. It needs some work to hammer out the details, but I like it. Acked-by: Hans Verkuil <hverkuil@xxxxxxxxx> Regards, Hans _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
