Em Sat, 15 Nov 2014 01:36:48 +0200 Antti Palosaari <crope@xxxxxx> escreveu: > Moikka! > > On 11/14/2014 09:34 PM, Mauro Carvalho Chehab wrote: > > Em Wed, 12 Nov 2014 06:23:04 +0200 > > Antti Palosaari <crope@xxxxxx> escreveu: > > > >> Implement PIP mode to stream from slave demodulator. PIP mode is > >> enabled when .set_frontend is called with RF frequency 0, otherwise > >> normal demod mode is enabled. > > > > This would be an API change, so, a DocBook patch is required. > > You are wrong. PIP mode is driver/device internal thing and will not be > revealed to userspace. > > > Anyway, using frequency=0 for PIP doesn't seem to be a good idea, > > as a read from GET_PROPERTY should override the cache with the real > > frequency. > > Yes, it is a hackish solution, used to put demod#0 on certain config > when demod#1 is used. When PIP mode is set that demod#0 is totally > useless as demod#1 is in use instead. Cache is garbage and no meaning at > all. > > > Also, someone came with me with a case where auto-frequency would > > be interesting, and proposed frequency=0. I was not convinced > > (and patches weren't sent), but using 0 for AUTO seems more > > appropriate, as we do the same for bandwidth (and may do the same > > for symbol_rate). > > I totally agree that is is hackish solution. That is called from > rtl28xxu.c driver and I added already comment it is hackish solution, > but you didn't apply that commit. > > > So, the best seems to add a new property to enable PIP mode. > > No, no, no. It is like a PIP filter. It is actually special case of PID > filter, having mux, to multiplex 2 TS interfaces to one (PIP = Picture > in Picture). > > > ............................................. > . RTL2832P integrates RTL2832 demodulator . > . ____________ ____________ . ____________ > .| USB IF | | demod | . | demod | > .|------------| |------------| . |------------| > .| RTL2832P | | RTL2832 | . | MN88472 | > .| |----TS bus----|-----/ -----|-.---TS bus----| | > .|____________| |____________| . |____________| > ............................................. > > > So the basically both demod PID filters are now implemented in RTL2832 > demod. Currently PIP mode is configured just to pass all the PIDs from > MN88472 and reject RTL2832 PIDs. And when PIP mode is off, at pass all > the PIDs from RTL2832, but rejects all PIDs from MN88472. Oh, I see. What demod(s) are exposed to userspace? both or just demod#1? If both are exposed, how userspace knows that demod#0 should not be used? Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
