| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| marc|gonzalez | mchehab: syoung: b-rad: hello mates :-)
Soooo, I have a question about my beloved si2168 driver upstream 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* 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 Typically, userspace would call at some point indirectly call si2168_set_frontend() with c->delivery_system set to either SYS_DVBT or SYS_DVBT2 It might not expect the demod to scan for both? Should a new delivery_system type be declared, maybe DVB-T-ALL or some such? | [09:28] |
| ......................................... (idle for 3h21mn) | ||
| 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:53] |
| mchehab | I mean, he just loggged as b-rad_
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
I guess some drivers just accept DVB-T as part of a DVB-T2 scan, while others don't s/scan/tuning/ | [12:54] |
| marc|gonzalez | mchehab: I'm looking at a user-space tool that's supposed to do "everything" : https://github.com/mighty-p/t2scan/
I have spent some time studying the si2168 data sheet and I see that some HW features are unused in the Linux driver | [12:55] |
| mchehab | ah, a variant of w_scan | [12:56] |
| marc|gonzalez | I'm wondering how much is due to the API... | [12:56] |
| mchehab | yeah, probably some things are due to the API
Btw, some Sony chipsets even have a way to do blind scans which should be faster than doing it via software | [12:58] |
| marc|gonzalez | "blind scan" would mean: find everything on a given frequency interval? | [12:59] |
| mchehab | blind scan I mean scan without needing a file
(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
a blind scan with DVB-S/S2 takes hours | [13:00] |
| 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
the feat is not there, but one develper who upstreamed the driver (not the official one) did some tests with such feat | [13:01] |
| marc|gonzalez | interesting... My task is to add support for DVB-T2 and not make scanning time worse. Ideally even optimize it... | [13:02] |
| mchehab | I was hoping that he would be trying to push it
IMHO, the best would be to add a feature like: seek for the next available channel starting from freq "foo" | [13:03] |
| 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
marc|gonzalez: for DVB-T/T2 this is not an issue... as frequencies are equally spaced within VHF or UHF range | [13:04] |
| 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
for DVB-S/S2, the channel position is actually a nightmare that's where a hardware-based scan could benefit well, 7 frequencies is not too much you could try first T2, falling back to T if T2 doesn't work | [13:05] |
| marc|gonzalez | mchehab: that would double the scan time | [13:08] |
| mchehab | (yet, a proper scan kernel feature could improve it)
marc|gonzalez: it won't double... probably most channels are T2. It will only double the time for T channels | [13:08] |
| 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?
didn't know that! | [13:09] |
| marc|gonzalez | I think I'm going to hack the driver and keep the dirty code to myself...
Unless we can get some discussion going on the list for a clean way forward with b-rad_ and yourself | [13:10] |
| ........ (idle for 38mn) | ||
| mchehab | marc|gonzalez: as I said, the better would be to add a scan function
we have an API for that at V4L2 side VIDIOC_S_HW_FREQ_SEEK IMO, we should implement something similar at the Kernel side | [13:49] |
| 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
implementing it for DVB shouldn't be hard | [13:51] |
| 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
yes, both reach the same drivers in the end | [13:52] |
| 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
separate callback, I mean (few drivers actually implement it at V4L2 side) as you may see, the V4L2 API sets: low freq, high freq, step, and if it will seek channels from the lowest to the highest fequency (or the other way) (it also has two V4L2 specific parameters - not relevant for DVB) for DVB, we could just add a few extra properties, like DTV_SEEK_STEP, DTV_SEEK_LOW_FREQ, DTV_SEEK_HIGH_FREQ, DTV_SEEK_START_FROM_LOW the core could auto-fill DTV_SEEK_LOW_FREQ, DTV_SEEK_HIGH_FREQ with some default (based on frontend low/high freq) | [13:53] |
| marc|gonzalez | OK thanks for the pointers, I will try to play with the HW, and report back
mchehab: what about parameters like QAM256 or 8k can they be automagically detected? Or do we need to cycle through all the possibilities? Or it depends on the HW? Like the Sony demod that can do everything in a single HW step | [13:59] |
| mchehab | well, IMO, if the hardware is capable of auto-detectiong, those shoulnd't be passed
the hardware should be set to autodetect and then report what it was detected it the hardware doesn't support that, well, it should report an error, and userspace will use the normal scan mode | [14:04] |
| marc|gonzalez | mchehab: in a hypothetical SCAN API function, you mean? | [14:05] |
| mchehab | yeah, that's what I'm talking
we should implement it *only* if the hardware is capable of auto-detecting the tuning parameters most of modern ones can hmm... there is a catch, though! DVB-T2 has one property that I'm not sure if this is detected | [14:05] |
| marc|gonzalez | the PLP thingy? | [14:07] |
| mchehab | yes | [14:07] |
| marc|gonzalez | no that is autodetected in si2168 I think | [14:07] |
| mchehab | OK
yeah, some devices can autodetect | [14:08] |
| marc|gonzalez | at least the "strongest PLP" whatever that means
might not be deterministic! depending on scan-time conditions | [14:08] |
| mchehab | well, maybe detecting one could be enough... not sure
I mean, maybe the NIT tables will contain info about other PLPs and userspace could use that, together with the "legacy" way to detect the other PLPs documenting it could be painful, though we may need something special for PLP scanning (same happens for DVB-S2, which has something equivalent to PLP DTV_STREAM_ID ============= Used on DVB-S2, DVB-T2 and ISDB-S. in practice, I never saw more than one PLP being used at the same time but there are some places where the default (PLP = 0) won't tune | [14:09] |
| 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:13] |
| mchehab | heh
anyway, need to go ttyl | [14:14] |
| marc|gonzalez | bye! | [14:14] |
| ........ (idle for 36mn) | ||
| 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
it was rejected because i had it as a module option to enable when desired and was told no no since there was no core support like QAM_AUTO for DVBT_AUTO, i left it since i had no time (i know qam_auto and dvbt_auto are not the same really) | [14:50] |
| marc|gonzalez | b-rad: can you provide a link? | [14:51] |
| b-rad | https://patchwork.kernel.org/patch/10744999/
i'm running low on things left to upstream though, so I was going to look into adding it | [14:52] |
| marc|gonzalez | b-rad: wow that was a short discussion :) | [14:53] |
| b-rad | welcome to dvb
where you're lucky for a single review or comment at all | [14:53] |
| 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
I care when it's an active task :) I had a cool patch... I'd have to dig it up someday "[RFC v2] DT-based tuner/demod init" it was :) | [14:54] |
| b-rad | yup i remember | [14:57] |
| marc|gonzalez | I was scratching on a limitation of the current DVB API
the current situation is a disgrace, with everyone embedding the init of a specific tuner in their demod driver "disgrace" may be a bit strong :) | [14:57] |
| 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:58] |
| b-rad | i won't even touch a lot of old drivers due to so many weird style choices | [14:59] |
| 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
hauppauge | [15:00] |
| marc|gonzalez | ah yes, I have heard of them | [15:00] |
| 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
then got lazy and figured "someone will do it better than me at some point" I was planning on using hauppauge gear with connexant chipsets also to sidestep the VHS copy protection nastiness | [15:01] |
| b-rad | a noble use case
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 i still get regular inquiries about why i don't upstream it, but alas there's just pieces missing in between and that whole "time" thing | [15:04] |
| marc|gonzalez | thanks! ttyl | [15:07] |
| ...... (idle for 26mn) | ||
| b-rad | i need to change my filter to leave a copy of list mails cc'd to me | [15:33] |
| ............. (idle for 1h2mn) | ||
| *** | _abbenormal has quit IRC (Ping timeout: 240 seconds) | [16:35] |
| .............................................................. (idle for 5h9mn) | ||
| Muzer has quit IRC (Ping timeout: 260 seconds) | [21:44] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |