Mailing List Archive

On Thu, 23 Mar 2023 16:01:30 +1300, you wrote:

>I am using TBS6909 and TBS6209 DVB-S2 and DVB-T2 cards in my MythTV
>box. These require compiling the TBS drivers with each kernel update,
>and recently the drivers have not been able to be compiled against the
>latest kernels, although the current Ubuntu LTS kernels were still OK.
>This was caused by the withdrawal of support for the upstream media
>build tree. It looks like support is back again, and the TBS drivers
>are now supposed to compile up to 6.2 kernels:
>
>https://github.com/tbsdtv/linux_media/issues/286
>
>I have not tested this yet as I am still on 5.15.

The build instructions have also been updated - there are two new
lines:

sed -i -r 's/(^CONFIG.*_RC.*=)./\1n/g' v4l/.config
sed -i -r 's/(^CONFIG.*_IR.*=)./\1n/g' v4l/.config

which go after the "make allyesconfig" line and look like they disable
building the remote control code. See:

https://github.com/tbsdtv/linux_media/wiki
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Thu, 23 Mar 2023 18:15:01 +1300, you wrote:

>On Thu, 23 Mar 2023 16:01:30 +1300, you wrote:
>
>>I am using TBS6909 and TBS6209 DVB-S2 and DVB-T2 cards in my MythTV
>>box. These require compiling the TBS drivers with each kernel update,
>>and recently the drivers have not been able to be compiled against the
>>latest kernels, although the current Ubuntu LTS kernels were still OK.
>>This was caused by the withdrawal of support for the upstream media
>>build tree. It looks like support is back again, and the TBS drivers
>>are now supposed to compile up to 6.2 kernels:
>>
>>https://github.com/tbsdtv/linux_media/issues/286
>>
>>I have not tested this yet as I am still on 5.15.
>
>The build instructions have also been updated - there are two new
>lines:
>
>sed -i -r 's/(^CONFIG.*_RC.*=)./\1n/g' v4l/.config
>sed -i -r 's/(^CONFIG.*_IR.*=)./\1n/g' v4l/.config
>
>which go after the "make allyesconfig" line and look like they disable
>building the remote control code. See:
>
>https://github.com/tbsdtv/linux_media/wiki

I have now had my first kernel update since the TBS drivers were
updated, and it seems that the two new sed lines in the build script
are wrong. When I compiled with them, the drivers did not load
against my new kernel - there were messages about rc_* names not being
found. Removing the two sed lines again made the drivers work as
normal.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, Mar 28, 2023 at 4:30?AM Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:

> I have now had my first kernel update since the TBS drivers were
> updated, and it seems that the two new sed lines in the build script
> are wrong. When I compiled with them, the drivers did not load
> against my new kernel - there were messages about rc_* names not being
> found. Removing the two sed lines again made the drivers work as
> normal.

TBS really needs to upstream their current
driver. I believe Hauppauge has done so,
leaving TBS as the last major TV tuner
manufacturer who forces their Linux users
to compile their own kernel driver (with
all the resulting failure modes).

Since the code is GPLv2, perhaps someone
who uses those cards might upstream the
code.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, 28 Mar 2023 15:14:40 +0000, you wrote:

>On Tue, Mar 28, 2023 at 4:30?AM Stephen Worthington
><stephen_agent@jsw.gen.nz> wrote:
>
>> I have now had my first kernel update since the TBS drivers were
>> updated, and it seems that the two new sed lines in the build script
>> are wrong. When I compiled with them, the drivers did not load
>> against my new kernel - there were messages about rc_* names not being
>> found. Removing the two sed lines again made the drivers work as
>> normal.
>
>TBS really needs to upstream their current
>driver. I believe Hauppauge has done so,
>leaving TBS as the last major TV tuner
>manufacturer who forces their Linux users
>to compile their own kernel driver (with
>all the resulting failure modes).
>
>Since the code is GPLv2, perhaps someone
>who uses those cards might upstream the
>code.

Yes, that would be great. I have never been sure why they do not do
this themselves.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 28/03/2023 17:05, Stephen Worthington wrote:

> On Tue, 28 Mar 2023 15:14:40 +0000, you wrote:
>
>> On Tue, Mar 28, 2023 at 4:30?AM Stephen Worthington
>> <stephen_agent@jsw.gen.nz> wrote:
>>
>>> I have now had my first kernel update since the TBS drivers were
>>> updated, and it seems that the two new sed lines in the build script
>>> are wrong. When I compiled with them, the drivers did not load
>>> against my new kernel - there were messages about rc_* names not being
>>> found. Removing the two sed lines again made the drivers work as
>>> normal.
>> TBS really needs to upstream their current
>> driver. I believe Hauppauge has done so,
>> leaving TBS as the last major TV tuner
>> manufacturer who forces their Linux users
>> to compile their own kernel driver (with
>> all the resulting failure modes).
>>
>> Since the code is GPLv2, perhaps someone
>> who uses those cards might upstream the
>> code.
> Yes, that would be great. I have never been sure why they do not do
> this themselves.


I was told it's something to do with supporting there clients who wish
to embed there devices in there products who typically use older kernels
or something like that.


Paul H.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, Mar 28, 2023 at 7:19?PM Paul Harrison <mythtv@mythqml.net> wrote:

> I was told it's something to do with supporting there clients who wish
> to embed there devices in there products who typically use older kernels
> or something like that.

That is no doubt true for past revisions
(and old kernels), but does not prevent
them getting the current driver revision
upstreamed so eventually they do not
have to deal with all the out-of-tree
issues, and if some paying (for support)
customer has an issue with a specific older
kernel version driver, would not prevent
them from providing an out of tree patch
(just as many companies do for their
paying clients today to support kernel
3.10, or, whatever).

I expect it is more about not wanting
to pay (their staff, or a contractor) to
change the drivers to meet current
kernel standards (structure, naming,
etc.) as their paying (for ongoing
support) customers don't care, and
their non-paying (for support)
customers on linux do not generate
enough revenue to justify the
expenses.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Wed, 29 Mar 2023 00:08:51 +0000, you wrote:

>On Tue, Mar 28, 2023 at 7:19?PM Paul Harrison <mythtv@mythqml.net> wrote:
>
>> I was told it's something to do with supporting there clients who wish
>> to embed there devices in there products who typically use older kernels
>> or something like that.
>
>That is no doubt true for past revisions
>(and old kernels), but does not prevent
>them getting the current driver revision
>upstreamed so eventually they do not
>have to deal with all the out-of-tree
>issues, and if some paying (for support)
>customer has an issue with a specific older
>kernel version driver, would not prevent
>them from providing an out of tree patch
>(just as many companies do for their
>paying clients today to support kernel
>3.10, or, whatever).
>
>I expect it is more about not wanting
>to pay (their staff, or a contractor) to
>change the drivers to meet current
>kernel standards (structure, naming,
>etc.) as their paying (for ongoing
>support) customers don't care, and
>their non-paying (for support)
>customers on linux do not generate
>enough revenue to justify the
>expenses.

TBS produce Linux based boxes that use their own cards, so a good
chunk of their revenue is from Linux. So they are not like the normal
suppliers where Linux is of distinctly secondary importance to them.

The problem seems to be the one of having to conform to the kernel
standards, more than anything else. And with new chips, they do need
to be able to publish updates rapidly until the drivers become stable.

The drivers I use seem to be produced by a single Ukrainian guy, who
is pretty good at creating drivers and fixing any problems that come
along, but there is only one of him and I suspect TBS does not pay him
as a full time employee.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org