[09:28] <marc|gonzalez> mchehab: syoung: b-rad: hello mates :-)
[09:28] <marc|gonzalez> Soooo, I have a question about my beloved si2168 driver upstream
[09:29] <marc|gonzalez> The HW is able to scan terrestrial frequencies in a mode where it scans for both DVB-T and DVB-T2 *at the same time*
[09:29] <marc|gonzalez> However, the driver does not use that feature at the moment... I'd like to add it, but I'm not sure about the API
[09:31] <marc|gonzalez> Typically, userspace would call at some point indirectly call si2168_set_frontend() with c->delivery_system set to either SYS_DVBT or SYS_DVBT2
[09:31] <marc|gonzalez> It might not expect the demod to scan for both?
[09:32] <marc|gonzalez> Should a new delivery_system type be declared, maybe DVB-T-ALL or some such?
[12:53] <mchehab> marc|gonzalez: I suspect b-rad_ might have missed your question
[12:53] <marc|gonzalez> mchehab: What do you mean "missed my question" ?
[12:53] <mchehab> about DVB-T2
[12:53] <marc|gonzalez> on the mailing list or here?
[12:54] <mchehab> I mean, he just loggged as b-rad_
[12:54] <mchehab> here
[12:54] <marc|gonzalez> ah I see, I highlighted b-rad, but he's now b-rad_ ...
[12:54] <mchehab> anyway, that's indeed a good point... I'm not sure how drivers currently handle DVB-T x DVB-T2 scanning
[12:55] <mchehab> I guess some drivers just accept DVB-T as part of a DVB-T2 scan, while others don't
[12:55] <mchehab> s/scan/tuning/
[12:55] <marc|gonzalez> mchehab: I'm looking at a user-space tool that's supposed to do "everything" : https://github.com/mighty-p/t2scan/
[12:56] <marc|gonzalez> I have spent some time studying the si2168 data sheet and I see that some HW features are unused in the Linux driver
[12:56] <mchehab> ah, a variant of w_scan
[12:56] <marc|gonzalez> I'm wondering how much is due to the API...
[12:58] <mchehab> yeah, probably some things are due to the API
[12:58] <mchehab> Btw, some Sony chipsets even have a way to do blind scans
[12:59] <mchehab> which should be faster than doing it via software
[12:59] <marc|gonzalez> "blind scan" would mean: find everything on a given frequency interval?
[13:00] <mchehab> blind scan I mean scan without needing a file
[13:00] <mchehab> (like w_scan and this t2scan tool)
[13:00] <marc|gonzalez> I'm not really clear about low-level stuff between tuner and demod and the terrestrial parameters like bandwidth, FFT size, etc
[13:00] <mchehab> for DVB-T/T2, this is not that hard, but this is a lot harder for DVB-S/S2
[13:00] <mchehab> a blind scan with DVB-S/S2 takes hours
[13:01] <marc|gonzalez> I don't know how much MUST be given and not guessed
[13:01] <mchehab> with those Sony chiptets, it happens in minuts
[13:01] <marc|gonzalez> Were they using a SONY-made demod?
[13:01] <mchehab> CXD drivers
[13:02] <mchehab> the feat is not there, but one develper who upstreamed the driver (not the official one) did some tests with such feat
[13:02] <marc|gonzalez> interesting... My task is to add support for DVB-T2 and not make scanning time worse. Ideally even optimize it...
[13:03] <mchehab> I was hoping that he would be trying to push it
[13:03] <mchehab> IMHO, the best would be to add a feature like:
[13:03] <mchehab> seek for the next available channel starting from freq "foo"
[13:04] <marc|gonzalez> how wide of a step though?
[13:04] <mchehab> something like that would be generic enough to be implemented at driver level, on devices that would support something like that
[13:05] <mchehab> marc|gonzalez: for DVB-T/T2 this is not an issue... as frequencies are equally spaced within VHF or UHF range
[13:05] <marc|gonzalez> In my use-case, I have a list of 7 frequencies where there is something, I must determine if it's T ot T2
[13:05] <mchehab> In practice, I guess the same applies for DVB-C, but this may not be the case
[13:06] <mchehab> for DVB-S/S2, the channel position is actually a nightmare
[13:06] <mchehab> that's where a hardware-based scan could benefit
[13:07] <mchehab> well, 7 frequencies is not too much
[13:08] <mchehab> you could try first T2, falling back to T if T2 doesn't work
[13:08] <marc|gonzalez> mchehab: that would double the scan time
[13:08] <mchehab> (yet, a proper scan kernel feature could improve it)
[13:09] <mchehab> marc|gonzalez: it won't double... probably most channels are T2. It will only double the time for T channels
[13:09] <marc|gonzalez> In France today, 0 channels are T2
[13:09] <mchehab> (and the number of T channels should reduce as time goes by)
[13:09] <marc|gonzalez> it's expected for 2024 only
[13:09] <mchehab> oh, really?
[13:09] <mchehab> didn't know that!
[13:10] <marc|gonzalez> I think I'm going to hack the driver and keep the dirty code to myself...
[13:11] <marc|gonzalez> Unless we can get some discussion going on the list for a clean way forward with b-rad_ and yourself
[13:49] <mchehab> marc|gonzalez: as I said, the better would be to add a scan function
[13:49] <mchehab> we have an API for that at V4L2 side
[13:50] <mchehab> VIDIOC_S_HW_FREQ_SEEK
[13:51] <mchehab> IMO, we should implement something similar at the Kernel side
[13:51] <marc|gonzalez> mchehab: OK, I might look into that once I figure out the HW bits
[13:51] <mchehab> for DVB
[13:51] <marc|gonzalez> oh there's nothing right now?
[13:51] <mchehab> well, there's just for V4L2
[13:52] <mchehab> implementing it for DVB shouldn't be hard
[13:52] <marc|gonzalez> mchehab: I'm not familiar with the distinction V4L2 vs DVB ?
[13:52] <mchehab> two different APIs
[13:52] <marc|gonzalez> I mean, in the end, it has to hit the driver, right?
[13:52] <mchehab> one for analog TV, cameras, radio, etc
[13:53] <mchehab> yes, both reach the same drivers in the end
[13:53] <marc|gonzalez> So they would just call the set_frontend() callback?
[13:53] <mchehab> for analog, there are a bunch of other callbacks
[13:53] <marc|gonzalez> Because right now, the si2168 set_frontend does not do the right thing, for broad scanning
[13:53] <mchehab> in the case of VIDIOC_S_HW_FREQ_SEEK, it uses a separate function
[13:54] <mchehab> separate callback, I mean
[13:54] <mchehab> (few drivers actually implement it at V4L2 side)
[13:55] <mchehab> as you may see, the V4L2 API sets:
[13:56] <mchehab> low freq, high freq, step, and if it will seek channels from the lowest to the highest fequency (or the other way)
[13:56] <mchehab> (it also has two V4L2 specific parameters - not relevant for DVB)
[13:58] <mchehab> for DVB, we could just add a few extra properties, like
[13:59] <mchehab> DTV_SEEK_STEP, DTV_SEEK_LOW_FREQ, DTV_SEEK_HIGH_FREQ, DTV_SEEK_START_FROM_LOW
[13:59] <mchehab> the core could auto-fill DTV_SEEK_LOW_FREQ, DTV_SEEK_HIGH_FREQ with some default (based on frontend low/high freq)
[13:59] <marc|gonzalez> OK thanks for the pointers, I will try to play with the HW, and report back
[14:03] <marc|gonzalez> mchehab: what about parameters like QAM256 or 8k  can they be automagically detected?
[14:04] <marc|gonzalez> Or do we need to cycle through all the possibilities?
[14:04] <marc|gonzalez> Or it depends on the HW?
[14:04] <marc|gonzalez> Like the Sony demod that can do everything in a single HW step
[14:04] <mchehab> well, IMO, if the hardware is capable of auto-detectiong, those shoulnd't be passed
[14:05] <mchehab> the hardware should be set to autodetect and then report what it was detected
[14:05] <mchehab> it the hardware doesn't support that, well, it should report an error, and userspace will use the normal scan mode
[14:05] <marc|gonzalez> mchehab: in a hypothetical SCAN API function, you mean?
[14:05] <mchehab> yeah, that's what I'm talking
[14:06] <mchehab> we should implement it *only* if the hardware is capable of auto-detecting the tuning parameters
[14:06] <mchehab> most of modern ones can
[14:06] <mchehab> hmm... there is a catch, though!
[14:07] <mchehab> DVB-T2 has one property that I'm not sure if this is detected
[14:07] <marc|gonzalez> the PLP thingy?
[14:07] <mchehab> yes
[14:07] <marc|gonzalez> no that is autodetected in si2168 I think
[14:08] <mchehab> OK
[14:08] <mchehab> yeah, some devices can autodetect
[14:08] <marc|gonzalez> at least the "strongest PLP" whatever that means
[14:08] <marc|gonzalez> might not be deterministic!
[14:08] <marc|gonzalez> depending on scan-time conditions
[14:09] <mchehab> well, maybe detecting one could be enough... not sure
[14:09] <mchehab> I mean, maybe the NIT tables will contain info about other PLPs
[14:09] <mchehab> and userspace could use that, together with the "legacy" way to detect the other PLPs
[14:10] <mchehab> documenting it could be painful, though
[14:10] <mchehab> we may need something special for PLP scanning
[14:11] <mchehab> (same happens for DVB-S2, which has something equivalent to PLP
[14:12] <mchehab> DTV_STREAM_ID
[14:12] <mchehab> =============
[14:12] <mchehab> Used on DVB-S2, DVB-T2 and ISDB-S.
[14:12] <mchehab> in practice, I never saw more than one PLP being used at the same time
[14:12] <mchehab> but there are some places where the default (PLP = 0) won't tune
[14:13] <marc|gonzalez> typically, these specs are written by people who love matroska-dolls with many levels of complexity, but in the end, it's rare for everything in the spec to be used, in my limited experience
[14:14] <mchehab> heh
[14:14] <mchehab> anyway, need to go
[14:14] <mchehab> ttyl
[14:14] <marc|gonzalez> bye!
[14:50] <b-rad> marc|gonzalez, did you see my auto T/T2 patch that was rejected?
[14:50] <marc|gonzalez> b-rad: no I have not. Who rejected it?
[14:50] <b-rad> it still exists in all of my built kernels
[14:51] <b-rad> it was rejected because i had it as a module option to enable when desired and was told no no
[14:51] <b-rad> since there was no core support like QAM_AUTO for DVBT_AUTO, i left it since i had no time
[14:51] <b-rad> (i know qam_auto and dvbt_auto are not the same really)
[14:51] <marc|gonzalez> b-rad: can you provide a link?
[14:52] <b-rad> https://patchwork.kernel.org/patch/10744999/
[14:53] <b-rad> i'm running low on things left to upstream though, so I was going to look into adding it
[14:53] <marc|gonzalez> b-rad: wow that was a short discussion :)
[14:53] <b-rad> welcome to dvb
[14:54] <b-rad> where you're lucky for a single review or comment at all
[14:54] <marc|gonzalez> b-rad: I tried upstreaming something last year, and no one cared actually
[14:54] <b-rad> c'est la vie
[14:54] <marc|gonzalez> smirk
[14:54] <b-rad> i still care because it's my job
[14:54] <marc|gonzalez> makes sense
[14:55] <marc|gonzalez> I care when it's an active task :)
[14:55] <marc|gonzalez> I had a cool patch... I'd have to dig it up someday
[14:56] <marc|gonzalez> "[RFC v2] DT-based tuner/demod init" it was :)
[14:57] <b-rad> yup i remember
[14:57] <marc|gonzalez> I was scratching on a limitation of the current DVB API
[14:57] <marc|gonzalez> the current situation is a disgrace, with everyone embedding the init of a specific tuner in their demod driver
[14:58] <marc|gonzalez> "disgrace" may be a bit strong :)
[14:58] <b-rad> it's a billion times better than the old dvb_attach abomination
[14:58] <marc|gonzalez> Wow, I cannot imagine the mess that was before then :)
[14:59] <b-rad> i won't even touch a lot of old drivers due to so many weird style choices
[15:00] <marc|gonzalez> where do you work?
[15:00] <b-rad> everything from excessive global variables to presumption of a single instance of a driver system wide
[15:00] <b-rad> hauppauge
[15:00] <marc|gonzalez> ah yes, I have heard of them
[15:01] <b-rad> you'd probably know of pctv our old euro company
[15:01] <marc|gonzalez> About 20 years ago, I wanted to digitize my VHS tapes
[15:01] <marc|gonzalez> then got lazy and figured "someone will do it better than me at some point"
[15:01] <marc|gonzalez> I was planning on using hauppauge gear with connexant chipsets
[15:02] <marc|gonzalez> also to sidestep the VHS copy protection nastiness
[15:04] <b-rad> a noble use case
[15:05] <b-rad> well i gotta go get outside, but if you want to look around in dvb-core for ideas about t/t2 auto support feel free
[15:05] <b-rad> i still get regular inquiries about why i don't upstream it, but alas there's just pieces missing in between
[15:06] <b-rad> and that whole "time" thing
[15:07] <marc|gonzalez> thanks! ttyl
[15:33] <b-rad> i need to change my filter to leave a copy of list mails cc'd to me
[16:35] *** _abbenormal has quit IRC (Ping timeout: 240 seconds)
[21:44] *** Muzer has quit IRC (Ping timeout: 260 seconds)