TBS in mainline?

[rubdos]

Hi!

Since TBS now has a GPL'd driver for some of the cards (and e.g., for 6902 it is the official one too): https://github.com/tbsdtv/linux_media , is TBS working on getting the drivers in mainline Linux? I think this would be interesting for both TBS and their users, since TBS doesn't have to to all update work themselves anymore, and since the users don't have to compile their drivers anymore.

Greetings,

Ruben

[steven]

Hi rubdos

We are on working with this and if you know any one who have the experience merge the driver to Mainline you can share with us : )

Thanks

Kind Regards

steven

[rubdos]

Hi Steven!

That's *awesome*! Thanks!

I suppose you could ask some people at v4l about this, they'll for sure want to help here and there.

Ruben

[rubdos]

Could you perhaps already indicate what your target kernel will be for initial mainline? 4.14 would be cool, since it'll be LTS

[jonas]

Hi!

Since TBS now has a GPL'd driver for some of the cards (and e.g., for 6902 it is the official one too): https://github.com/tbsdtv/linux_media , is TBS working on getting the drivers in mainline Linux? I think this would be interesting for both TBS and their users, since TBS doesn't have to to all update work themselves anymore, and since the users don't have to compile their drivers anymore.

Greetings,

Ruben

I don't know if you made progress in this direction meanwhile.

From a customer perspective: With many cards you need to compile v4l anyway, so in order to have you driver work with other hardware, this would be the first important thing. You found the v4l maintainers already. They need to accept your code anyway I think, because you have changes there for hardware that is maintained by others (tuners for example).

Another great thing would be to have it working out of the box. For this you would need to commit to maintain the drivers according to all changes propagated to the Linus development kernel. If you do that, you could look for people to have a look at you patches on the Linux Kernel Mailing list. There might implicit design rules and stuff come up, so it would be good to find somebody to do some QS in ways of the thinking of kernel developers. This could be beyond of just "it's working".

This way you will also find out who is responsible for patches in this area, and be able to provide the patches. I say "patches", because i think it makes sense to divide your new device driver from changes done in other people's code.

This maybe sounds more complicated as it really is, but sure it will need some time on your side.

Anyway, just got to LKML mailing list and get in contact with these people. I did this before like two times with some totally non-explainable problem and got prompt help. With patches, however, this is obviosly much more restricted and you need to make the chunk to be easily swallowed.

I hope this helps

[rubdos]

Hi! I wanted to get my two cents out there, again. I, personally, decided that I'm not buying TBS again until it's mainlined. It's simply too much of a hassle to maintain and debug. TeVii works out of the box, for example; although those cards are more difficult to acquire for me.

[jonas]

For me it will sufficient if I could create a script that would (download and) build the drivers after a kernel upgrade automatically. That should be possible now.

The hardware I used before TBS also would only work with the newest v4l sources, not even the "stable" v4l branch, let alone the base line kernel. For years.

[updatelee]

I sympathize with TBS. It's not easy to get the v4l guys to accept code changes. It's much easier to just release your own git repo. Just look at the attempts to get the saa716x driver included in mainline. People have been trying since 2009! And it's still not in there. It's crazy.

I personally tried too to get different small changes included. V4l does what they want and they don't include drivers or patches from outsiders. There defenition of an outsider is someone that is not employed by a silicon manufacturer. TBS uses ST demodulators and montage demodulators but TBS is not ST or montage, they purchase their chips and use them. They are considered an outsider.

I feel for TBS and honestly I think they've done an outstanding job of maintaining a compatible source tree considering the numerous kernel versions out there. They truly support their customers and the satellite community.

No it's not a perfect system but they've done their best considering the imperfect system we've been given.

Don't believe me? Try getting a change mainlined. Pick anything. There is a ton of small errors you could try.

UDL

[Scritch]

My setup is an Odroid C1 with a few DVB cards attached.
Odroid is essentially pure Amlogic hardware.

Getting the combination to work was a nightmare. Amlogic initially went "the TBS way". Meaning: Release an Open source kernel for their boards, all drivers on top of the regular kernel. This kernel (3.10) has several shortcomings (which is the reason why it will not be accepted for the mainline kernel as-is). One of them was the the media kernel parts are statically linked into the kernel.
So my task was to: Get the hardkernel/amlog kernel, change its build, compile&deploy, get the TBS OS drivers, fix the automated downmerge (god thank it exists!) to 3.10, compile & deploy.

You see where this leads to? Two vendors considering that they are obviously doing "a good thing", but the outcome for me as a customer is a hardly usable setup.

Since 1-2 years, amlogic pushes for mainline: http://linux-meson.com/doku.php.

This graphics tells you: It is possible: . Of course, it is tough work. But in case a company wants and acknowledges the customer value, it is possible.

And don't forget one thing: These guys aim for support of a self-made SOC.
A task not comparable to TBS cards which "just" combine existing hardware pieces to DVB cards.

I am not saying its trivial. I could not as I obviously have no clue what it really means. I just say: Where is a will there's a way into mainline.

[iridium]

I sympathize with TBS. It's not easy to get the v4l guys to accept code changes. It's much easier to just release your own git repo. Just look at the attempts to get the saa716x driver included in mainline. People have been trying since 2009! And it's still not in there. It's crazy.

The saa716x driver also has support for full-featured DVB-S2 cards (i.e. cards having a hardware MPEG-4 AVC decoder), and there is some discussion about whether the old API for full-featured cards is actually obsolete and whether drivers using this API should be merged.

For the TBS cards using saa716x, saa716x-budget support would be totally sufficient. In case there is some maintainer for the code who is willing to polish a bit and cooperate with upstream to get it merged, I don't see any reason for that not being possible. Communication with Manu Abraham, who initially wrote the saa716x driver, would most probably be polite before pushing it upstream.

If you dig through the mailing list archives, saa716x not being upstream seems to be more an issue of lacking manpower and motivation among the stakeholders and not some problem in the general process of upstreaming changes to the linux media subsystem.

I feel for TBS and honestly I think they've done an outstanding job of maintaining a compatible source tree considering the numerous kernel versions out there.

The TBS source tree is actually a complete fork of the media subsystem of the linux kernel, making it painful to use for end-users. Being compatible to numerous kernel versions is not too big of an achievement in this setting.

Don't believe me? Try getting a change mainlined. Pick anything. There is a ton of small errors you could try.

Been there. Done that. What's your point?