Update: Upstream updated, now works with kernel 5.1. @Tom_B You need to wait for upstream to update drivers to the 5.1 kernel. LTS kernel might work in the meantime but I have not tested.
Search Criteria
Package Details: tbs-linux_media-git r1580.420e143_bfcdb6f_6.5.5_arch1_1-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/tbs-linux_media-git.git (read-only, click to copy) |
---|---|
Package Base: | tbs-linux_media-git |
Description: | TBS linux open source drivers |
Upstream URL: | https://github.com/tbsdtv/linux_media |
Licenses: | GPL2 |
Conflicts: | tbs-dvb-drivers |
Provides: | linux_media |
Submitter: | swearchnick |
Maintainer: | swearchnick |
Last Packager: | swearchnick |
Votes: | 6 |
Popularity: | 0.034866 |
First Submitted: | 2017-06-17 08:49 (UTC) |
Last Updated: | 2023-09-27 15:16 (UTC) |
Dependencies (5)
- tbs-firmwareAUR
- git (git-gitAUR, git-glAUR) (make)
- linux-headers (make)
- patchutils (make)
- perl-proc-processtable (make)
Required by (0)
Sources (0)
swearchnick commented on 2019-05-25 15:38 (UTC) (edited on 2019-05-28 13:32 (UTC) by swearchnick)
Tom_B commented on 2019-05-25 10:19 (UTC)
I'm getting an error in build. Is this not updated for recent kernels? There are 5.0 tags in the repo.
cc1: some warnings being treated as errors make[3]: [scripts/Makefile.build:282: /home/media/.cache/yay/tbs-linux_media-git/src/media_build/v4l/ipu3-cio2.o] Error 1 make[3]: Waiting for unfinished jobs.... make[2]: [Makefile:1571: module/home/media/.cache/yay/tbs-linux_media-git/src/media_build/v4l] Error 2 make[2]: Leaving directory '/usr/lib/modules/5.1.4-arch1-1-ARCH/build' make[1]: [Makefile:53: default] Error 2 make[1]: Leaving directory '/home/media/.cache/yay/tbs-linux_media-git/src/media_build/v4l' make: *** [Makefile:26: all] Error 2 ==> ERROR: A failure occurred in build(). Aborting... Error making: tbs-linux_media-git
p-we commented on 2018-05-31 00:48 (UTC) (edited on 2018-05-31 02:18 (UTC) by p-we)
I know about the "extra modules" which is handy to not have to build a new package at every point release. But AFAIK this does not trigger all identically named modules in the extra modules directory to override their counterparts in the kernel's media tree. When I was maintaining the ffdecsawrapper AUR package a few years ago, the dvbdev.h file was patched but the rebuilt patched dvbdev module did not replace the like named in-tree kernel module unless put in the updates directory. Obviously in this current scenario most of the 700+ similarly named media modules in kernel are unaffected by the tbsdtv media tree replacements but some of them are modified. The unique TBS modules would take of course. Thanks for the info regarding depmod as I thought demod did need to be triggered. Please inform me otherwise if I am wrong about the directories. I speak from experience with DTV run on ArchLinux but not expertise. My recent experience with a brand new Coffee Lake i5 based media server and TBS DVB-S cards onboard using TVHeadend on current 4.16 ARCH went from 'partially reliable' to 'perfect' since a week of running after making this change. I otherwise would not have bothered to chime in here. Cheers.
swearchnick commented on 2018-05-30 14:38 (UTC) (edited on 2018-05-30 16:20 (UTC) by swearchnick)
@p-we: No and no. Directory doesn't matter there is a symlink "extra modules" in $pkgdir/usr/lib/modules/uname -r owned by linux package. Depmod is taken care of by an arch linux general hook. You probably need to make a separate PKGBUILD for your LTS kernel. For vanilla arch kernel your statements are not correct.
p-we commented on 2018-05-30 12:54 (UTC)
I instaled this package to get mixed results. When I examined the PKGBUILD I noticed that the modulea are installed into the 'extramodules' directory which is essentialy wrong. This is complete custom rebuild of the linux media stack where the existing media stack must be replaced, i.e. not augmented, to ensure proper function. The modules need to be placed in $pkgdir/usr/lib/modules/uname -r
/updates to replace the existing in-tree modules. Depmod also needs to be run following installation to make sure this happens. I had less quirky things happening once I changed this with my 6984 and 6908
p-we commented on 2018-04-22 23:09 (UTC) (edited on 2018-04-22 23:10 (UTC) by p-we)
Anyone out there trying to get these drivers working on an AMD Ryzen system? I've got Ryzen 1600x + B350 chipset where TBS drivers not working. I have TBS 6984, 6985, and 6908 cards all of which work with AMD K8 and Intel Sandy Bridge. The problem seems to begin (and end) with dmesg showing that firmware is not being picked up. Any insights appreciated. The old SandyBridge is slowly dying. Using Arch LTS 4.14. Thanks
Pinned Comments