[05:04] <twb> I have some TBS DVB-T tuners that I use to turn Australian terrestrial digital TV into IPTV.
[05:05] <twb> Originally these didn't have in-kernel drivers - the TBS people took a copy of the linux media repo, edited a bunch of crap, then dumped it onto their own website
[05:05] <twb> e.g. https://www.tbsiptv.com/download/common/tbs-linux-drivers_v170330.zip
[05:05] <twb> I then had to build this, and not even with DKMS, but using some weird v4l-specific makefile stuff
[05:06] <twb> http://ix.io/1XYV  like this
[05:07] <twb> Anyway.  It seems that TBS company have changed how their stuff works: https://github.com/tbsdtv/linux_media/wiki  so now they want me to git clone their fork of the full v4l linux codebase, and then run THEIR wacky scripts
[05:07] <twb> So before I start doing that, I thought: maybe these cards Just Work in mainlinux linux by now?
[05:08] <twb> *mainline linux
[05:08] <twb> Is there a way to easily check that - easier than "just boot a mainline kernel"?  Like is there an HCL page somewhere?
[05:09] <twb> lspci -nn reports "01:00.0 Multimedia controller [0480]: TBS Technologies DVB-S2 4 Tuner PCIe Card [544d:6178]"
[05:20] <twb> Well https://www.linuxtv.org/wiki/index.php/TBS6205 exists but doesn't actually tell me how supported it is
[05:21] <twb> I'm about to test a stock 4.19 kernel now.  If that doesn't Just Work, I'll try to build an OS image with stock 5.2
[05:49] <twb> $boss says the receipts are for TBS 6205 and TBS 6285
[05:53] <twb> sigh, more yaks to shave
[05:53] <twb> with a 4.19 stock kernel instead of a 4.9 kernel + tbs crap, our tv server doesn't boot up
[05:53] <twb> The error is a missing proprietary firmware blob for the broadcom bnx2 NIC
[05:53] <twb> We are installing firmware-bnx2 in the SOE...
[05:54] <twb> SOE compile didn't work for some reason?
[05:54] <twb> Oh never mind, I named it funny
[06:00] <twb> Oh sorry, that last block of whinging was meant for work IRC
[06:53] <twb> OK, neither stock 4.19 nor stock 5.2 worked with these SAA7160-based TBS cards (probably TBS 6502's).  /dev/dvb* doesn't show up at all.
[06:54] <twb> So back to buggerizing around with these non-dkms third party kernel modules :-/
[08:14] <bbrezillon> hverkuil, mchehab: I just noticed "media: hantro: h264: Fix the frame_num wraparound case" and the 2 patches it depends on have been queued for 5.5, and I was expecting them to be queued to the fixes branch. It's definitely my fault since I didn't mention that anywhere in the patch series (I thought the Fixes tag was implicity implying "queue to fixes branch")
[08:15] <bbrezillon> I'll try to make it clear next time (I see ezequielg adds a "for 5.4" in the subject prefix)
[08:15] <bbrezillon> tfiga: FYI ^
[09:13] <bbrezillon> hverkuil: RFC v3 sent
[10:22] <tfiga> bbrezillon: thanks for the heads up
[10:23] <tfiga> I believe we have corresponding fixes in our branch already, but we'll refresh them with merged ones
[10:58] <mchehab> bbrezillon: no, we use fixes tag also for patches for next devel version. Please always use cc: stable@vger.kernel.org when you send patches that should be backported. Also, better warn us when you're sending a regression-fix patch that should be applied to the current release instead of -next.
[11:40] <bbrezillon> mchehab: actually, I didn't intend to Cc the stable ML as the bug is only present in v5.4-rc1
[11:41] <bbrezillon> but I should have make it explicit that I was expecting those patches to be applied to the fixes branch
[12:35] *** Melatonina has left 
[12:40] <ndufresne> pH5, thanks for the patch, looks indeed like what was blocking me yesterday, I'll give it a try
[12:41] <ndufresne> pH5, it might yield some discussions though here, there seems to be goods and bad to this, of course lazy allocation in the VA driver would fix this, but I guess that's for later
[14:25] <ndufresne> pH5, thanks, quite some progress, but now everything is green, got a check what is going on
[15:53] *** benjiG has left