On 9/13/07, Manu Abraham <abraham.manu@xxxxxxxxx> wrote: > > > It's only a step in development, I do not intend to keep the kernel > > stub in the end, but I do intend to keep and use the userspace drivers > > with i2c-dev in the long run, this requires a v4l/dvb library at the front > > of everything. > > Well, this was what adq and myself did with libdvbapi and mti, (much > before UIO was announced at LK.) It is not tied to I2C either. > I2C is the main communication path for it, although there are callback mechanisms available which add the possibility for different configuration paths. > But, according to your statements (with regards to i2c-dev) you can > handle only some I2C based devices, which is in fact a subset of a > subset. Also not to forget that hardly a few I2C devices are in fact > "truly" I2C compatible. In fact many variables to be considered. > The analogue tuner core is also only for i2c only devices which most devices rely on. > Also there is to consider a non technical aspect, whether vendors will > misuse this interface for binary only, undermining the efforts put in > for OSS drivers. > What holds companies for using the current available code putting it into an rpm or deb package and releasing such code now? The Avermedia example I pointed out to is a good example already. As from my side I won't release binary drivers. Although on the other side: * are drivers from vendors which work through several kernel versions that bad? * Why did someone duallicense videodev2 with BSD/GPL? I would appreciate if someone else on the list could also comment the reason that drivers should all be included in the linuxkernel just because forcing the companies to release binary drivers because of that. My opinion about that is if a company wants to go opensource they will do so, if not they will either not release a driver or release nothing. Markus _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
