On Sunday 26 February 2006 17:56, Alan Nisota wrote: > I'm willing to buy this. I'm not sure I agree, but I guess it depends > on how long until v4 is released (after all, it is just a question of > how many additional features are needed before then). that may depend on how many frontends will be adapted. iirc there is a vdr version with v4 already exististing - correct me if i am wrong. > But the > dsicussion seems to have branched off toward implementing more and > more stuff into user space. I think this would be a bad way to go at > the moment (just put this stuff into the v4 API instead). > Doing so > raises the bar substatially for dvb apps, and I wouldn't be surprised > if they just ignore DVB-S2 claiming not enough kernels support it, and > not enough people have the cards, rather than needing to change all > their code to support a user-space library (assuming I understand what > is being proposed) i think you missed the point a bit. if we get a appropiate system to have tuner details in userspace, the applications using the userspace lib will just be able to use new frontend drivers a.s.a.p without changing final kernel versions, or even to patch kernel with the hg repository. so imho the development and the spreading will be much faster for the community as it will be (in most cases) a relink of the client application. the next argument is that nobody has to care about the kernel support of e.g. dvb-s2. and, the rework within the application for all the frontend stuff ported to a userspace lib, would be nothin more than having an additional header included and change the frontend capabilities query and tuning functions to a definately easier to understand interface. > Instead, why not patch in the support we need, and work on a grand > consistant plan for the v4 API, which will give user apps a clean > place to do restructuring? if we would apply dvb-s2 support a.s.a.p without discussions about other solutions, we will completely surely run into big trouble. having additional dvb-s2 modulations and therefore also the capabilities (FE_CAN_XXX) values, is not realiseable within current enumeration scheme. that's why i just re-enforced this discussion. after talking about my solutions on irc, i came to the conclusion that if we just add dvb-s2, next change will break backwards compatibility for sure. that caused me to rethink about the userspace lib idea to prevent all these discussions on further development. and - as mentioned for more than two times now - changing to a new api or break backwards compatibility makes a lot people cry more than changing _just_ the frontend stuff for now, and then have the ability to do a slightly change to next api version. although the userspace idea is NOT to cancel all the given kernel stuff, but do a slightly migration. all current methods(ioctls) would be kept. it is just a thinkin of freedom and real freedom of any regressions that may occur in this fast evolving business. although we did not talk about advantages that a userspace library will give for hw manufacturers, e.g. they could legally provide a frontend driver as a binary release, if we would perfom a LGPL license. regards marcel _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
