TBSDTV Community Forum

Why you SHOULD NOT want a device with 3rd party drivers:

In the end, you should (sadly) generally not buy these.

http://www.linuxtv.org/wiki/index.php/DVB-S2_USB_Devices#Supported_by_3rd_Party_Drivers

So The LinuxTV wiki discourages buying your products? I wonder if it would do you any harm if the Linux community strongly encouraged buying your products. I also doubt there is anything too valuable in your code to be openly published.

Please consider collaborating even more with the community. People would have less problems with your products.
Personally I never got my TBS5980 to work. On Linux or Windows.

Although I dont 100% agree or disagree with the wiki entry, its personal opinion.

I myself am in that boat with my kernel module tree, its 100% open source with no precompiled binaries at all. I fully support the open source community and have no interest in precompiled binaries as they severely limit my choice of kernel as well as what I can change within the kernel.

I do understand though why some companies cant release everything under open source, its quite often but not always the chip manufacturers. Sometimes its the fact they wont allow any code to be public based off their datasheets / sdk's Other times its just a licensing issue. This is where Im stuck in,

the saa716x code wasnt writen by me, the original authors dont seem to have much interest in pushing it to v4l, NXP has no interest in even talking to me, the product is discontinued and the IP is sold to a now bankrupt company, their lawyers obv have no interest in me as they cant make any money off me. So how does someone like me get the saa716x code pushed to v4l ? alot of my patch's are based off that driver, without that the cards wont work.

next issue is alot of v4l's api's are bloody old and nasty. So instead of dealing with alot of the crap the v4l wants me to use, I just changed things to make more sense and functional. Problem is this breaks userland applications until they are recompiled against my tree. Linux kernel maintainers are so anti break userland that they resist core changes to the extreme and the api stays crap forever.

want examples?

- dvb_demux has fixed 188 packet sizes hardcoded in, with no way to easily change them on the fly based on system
- fe_caps hold every bloody possible thing you could think of with a max of 32 items? thats retarded
- why was there a delsys but not delmod or delfec?
- why is there a FEC_NONE and SYS_UNDEFINED but not one for modulation?

Id love to get some of my patch's upstream, but its not a friendly road.

UDL

nilux Wrote:Please consider collaborating even more with the community. People would have less problems with your products.
Personally I never got my TBS5980 to work. On Linux or Windows.

5980 work with Windows and Linux Linux driver 100% open-source, use stb6100/stv090x v4l drivers.

I think this proper signal to TBS - submit patches to official V4L for stable and open-source drivers. TBS 5920, 5928, 5980, 5925, 5880, 5280.

And i agree - very bad practice with 'fake' binaries like for 6925/5925 - just some chip init (TS mode) and LNB-voltage control. For CXD2820r-based also can be used open-source tda18212/cxd2820r drivers.