[linux-dvb] DVB-S2 / Multiproto and future modulation support
stoth at linuxtv.org
Thu Sep 4 16:25:34 CEST 2008
Hans Verkuil wrote:
> 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
>> as a joke and a bunch in-fighting people. Multiproto is a great
>> demonstration of this.  The multiproto project has gone too far,
>> 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"
>> "it's time to take a new direction", for these developers the
>> political and personal cost of multiproto is too high. These
>> 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
>> different and simpler API.
>> Basic patches and demo code for this API is currently available here.
>> 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
>> 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
>> 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:
> It might be useful to compare the two.
yes, another developer also suggested this. It would be good to
implement simmilar ideas - especially then they are already well
> 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?
I've been thinking about this a lot and I'm leaning away from making the
sequence atomic, partly for the issue you raised and partly because
when I tried to find concrete use cases where this was required I only
came up with a few.
I want to explore this more, after I've published all of the feedback.
> 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.
The 16 limit is going to be removed in favor of a more flexible (and
traditional approach). A complete set of set's or get's is interesting.
Let me see if I can find a use-case where we'd mix the two... if not
then I agree with this, and it would simplify things even further.
We'll explore this more.
> 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
>> 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
>> 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
>> acking this email.
>> Regards - Steve, Mike, Patrick and Mauro.
>> Acked-by: Patrick Boettcher <pb at linuxtv.org>
>> Acked-by: Michael Krufky <mkrufky at linuxtv.org>
>> Acked-by: Steven Toth <stoth at linuxtv.org>
>> Acked-by: Mauro Carvalho Chehab <mchehab at infradead.org>
>> * . 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 at xs4all.nl>
Hans, thanks for your support and feedback.
More information about the linux-dvb