Marcel Siegert writes: > On Sunday 26 February 2006 17:56, Alan Nisota wrote: [...] > > 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. The API changes are not an argument. The user space library will also have an API. You will have exactly the same problems with API changes. > > 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 See above. Same in user space. > 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. dvb-core also used to be completely LGPL for that reason. Some parts now seem not to be? Considering what kind of discussion is going on regarding the new GPL version and the mixing of different versions, what license exactly is dvb-core using right now? Easier support for binary tuner modules was, at the time, also one argument for moving away from kernel I2C to the current demod/pll support model. I am not completely against a move to user space. But first I want to see how a few of the possible issues with some cards will be handled. As I understand it, Manu is still working on the details. In the meantime, I'll stick to kernel space, also for DVB-S2 frontends. Ralph _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
