Re: [ANNOUNCE] DVBv5 tools version 0.0.1
On 01/11/2012 12:00 AM, Mauro Carvalho Chehab wrote: On 10-01-2012 19:36, Antti Palosaari wrote: Behaviour of new FE is strange for my eyes. Could you look and explain if it is intentional? I still see that it changes delivery system automatically to the DVB-T. That is the latest commit: commit 149709f5b8a4a8678401facb5c670119751f6087 Author: Mauro Carvalho Chehab mche...@redhat.com Date: Fri Jan 13 11:46:36 2012 -0200 [media] dvb-core: preserve the delivery system at cache clear The changeset 240ab508aa is incomplete, as the first thing that happens at cache clear is to do a memset with 0 to the cache. So, the delivery system needs to be explicitly preserved there. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com And here is log: [crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO DVB API Version 5.5, Current v5 delivery system: DVBT Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A Changing delivery system to: DVBC/ANNEX_A [crope@localhost code]$ scan ../fi-Oulu-c scanning ../fi-Oulu-c using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 33000 6875000 0 4 initial transponder 37000 6875000 0 4 initial transponder 36200 6875000 0 4 initial transponder 35400 6875000 0 4 initial transponder 34600 6875000 0 4 initial transponder 33800 6875000 0 4 initial transponder 32200 6875000 0 4 initial transponder 31400 6875000 0 4 initial transponder 37800 6875000 0 4 initial transponder 30600 6875000 0 4 initial transponder 29800 6875000 0 4 initial transponder 29000 6875000 0 5 initial transponder 27400 6875000 0 5 initial transponder 26600 6875000 0 5 initial transponder 25800 6875000 0 5 initial transponder 25000 6875000 0 5 initial transponder 24200 6875000 0 5 tune to: 33000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128 ^CERROR: interrupted by SIGINT, dumping partial result... dumping lists (0 services) Done. [crope@localhost code]$ scan ../fi-Oulu-c scanning ../fi-Oulu-c using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 33000 6875000 0 4 initial transponder 37000 6875000 0 4 initial transponder 36200 6875000 0 4 initial transponder 35400 6875000 0 4 initial transponder 34600 6875000 0 4 initial transponder 33800 6875000 0 4 initial transponder 32200 6875000 0 4 initial transponder 31400 6875000 0 4 initial transponder 37800 6875000 0 4 initial transponder 30600 6875000 0 4 initial transponder 29800 6875000 0 4 initial transponder 29000 6875000 0 5 initial transponder 27400 6875000 0 5 initial transponder 26600 6875000 0 5 initial transponder 25800 6875000 0 5 initial transponder 25000 6875000 0 5 initial transponder 24200 6875000 0 5 WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) ERROR: initial tuning failed dumping lists (0 services) Done. [crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16
Re: [ANNOUNCE] DVBv5 tools version 0.0.1
On 01/15/2012 08:37 PM, Antti Palosaari wrote: On 01/11/2012 12:00 AM, Mauro Carvalho Chehab wrote: On 10-01-2012 19:36, Antti Palosaari wrote: Behaviour of new FE is strange for my eyes. Could you look and explain if it is intentional? I still see that it changes delivery system automatically to the DVB-T. That is the latest commit: commit 149709f5b8a4a8678401facb5c670119751f6087 Author: Mauro Carvalho Chehab mche...@redhat.com Date: Fri Jan 13 11:46:36 2012 -0200 [media] dvb-core: preserve the delivery system at cache clear The changeset 240ab508aa is incomplete, as the first thing that happens at cache clear is to do a memset with 0 to the cache. So, the delivery system needs to be explicitly preserved there. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com And here is log: [crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO DVB API Version 5.5, Current v5 delivery system: DVBT Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A Changing delivery system to: DVBC/ANNEX_A [crope@localhost code]$ scan ../fi-Oulu-c scanning ../fi-Oulu-c using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 33000 6875000 0 4 initial transponder 37000 6875000 0 4 initial transponder 36200 6875000 0 4 initial transponder 35400 6875000 0 4 initial transponder 34600 6875000 0 4 initial transponder 33800 6875000 0 4 initial transponder 32200 6875000 0 4 initial transponder 31400 6875000 0 4 initial transponder 37800 6875000 0 4 initial transponder 30600 6875000 0 4 initial transponder 29800 6875000 0 4 initial transponder 29000 6875000 0 5 initial transponder 27400 6875000 0 5 initial transponder 26600 6875000 0 5 initial transponder 25800 6875000 0 5 initial transponder 25000 6875000 0 5 initial transponder 24200 6875000 0 5 tune to: 33000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128 ^CERROR: interrupted by SIGINT, dumping partial result... dumping lists (0 services) Done. [crope@localhost code]$ scan ../fi-Oulu-c scanning ../fi-Oulu-c using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 33000 6875000 0 4 initial transponder 37000 6875000 0 4 initial transponder 36200 6875000 0 4 initial transponder 35400 6875000 0 4 initial transponder 34600 6875000 0 4 initial transponder 33800 6875000 0 4 initial transponder 32200 6875000 0 4 initial transponder 31400 6875000 0 4 initial transponder 37800 6875000 0 4 initial transponder 30600 6875000 0 4 initial transponder 29800 6875000 0 4 initial transponder 29000 6875000 0 5 initial transponder 27400 6875000 0 5 initial transponder 26600 6875000 0 5 initial transponder 25800 6875000 0 5 initial transponder 25000 6875000 0 5 initial transponder 24200 6875000 0 5 WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) ERROR: initial tuning failed dumping lists (0 services) Done. [crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16
Re: [ANNOUNCE] DVBv5 tools version 0.0.1
Em 15-01-2012 18:03, Antti Palosaari escreveu: On 01/15/2012 08:37 PM, Antti Palosaari wrote: On 01/11/2012 12:00 AM, Mauro Carvalho Chehab wrote: On 10-01-2012 19:36, Antti Palosaari wrote: Behaviour of new FE is strange for my eyes. Could you look and explain if it is intentional? I still see that it changes delivery system automatically to the DVB-T. That is the latest commit: commit 149709f5b8a4a8678401facb5c670119751f6087 Author: Mauro Carvalho Chehab mche...@redhat.com Date: Fri Jan 13 11:46:36 2012 -0200 [media] dvb-core: preserve the delivery system at cache clear The changeset 240ab508aa is incomplete, as the first thing that happens at cache clear is to do a memset with 0 to the cache. So, the delivery system needs to be explicitly preserved there. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com And here is log: [crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO DVB API Version 5.5, Current v5 delivery system: DVBT Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A Changing delivery system to: DVBC/ANNEX_A [crope@localhost code]$ scan ../fi-Oulu-c scanning ../fi-Oulu-c using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 33000 6875000 0 4 initial transponder 37000 6875000 0 4 initial transponder 36200 6875000 0 4 initial transponder 35400 6875000 0 4 initial transponder 34600 6875000 0 4 initial transponder 33800 6875000 0 4 initial transponder 32200 6875000 0 4 initial transponder 31400 6875000 0 4 initial transponder 37800 6875000 0 4 initial transponder 30600 6875000 0 4 initial transponder 29800 6875000 0 4 initial transponder 29000 6875000 0 5 initial transponder 27400 6875000 0 5 initial transponder 26600 6875000 0 5 initial transponder 25800 6875000 0 5 initial transponder 25000 6875000 0 5 initial transponder 24200 6875000 0 5 tune to: 33000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128 ^CERROR: interrupted by SIGINT, dumping partial result... dumping lists (0 services) Done. [crope@localhost code]$ scan ../fi-Oulu-c scanning ../fi-Oulu-c using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 33000 6875000 0 4 initial transponder 37000 6875000 0 4 initial transponder 36200 6875000 0 4 initial transponder 35400 6875000 0 4 initial transponder 34600 6875000 0 4 initial transponder 33800 6875000 0 4 initial transponder 32200 6875000 0 4 initial transponder 31400 6875000 0 4 initial transponder 37800 6875000 0 4 initial transponder 30600 6875000 0 4 initial transponder 29800 6875000 0 4 initial transponder 29000 6875000 0 5 initial transponder 27400 6875000 0 5 initial transponder 26600 6875000 0 5 initial transponder 25800 6875000 0 5 initial transponder 25000 6875000 0 5 initial transponder 24200 6875000 0 5 WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) ERROR: initial tuning failed dumping lists (0 services) Done. [crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION
Re: [ANNOUNCE] DVBv5 tools version 0.0.1
On 01/15/2012 11:08 PM, Mauro Carvalho Chehab wrote: Em 15-01-2012 18:03, Antti Palosaari escreveu: On 01/15/2012 08:37 PM, Antti Palosaari wrote: On 01/11/2012 12:00 AM, Mauro Carvalho Chehab wrote: On 10-01-2012 19:36, Antti Palosaari wrote: That seems to be due to cxd2820r bug introduced by multi-frontend to single-frontend change. Ok. Could you please fix it and send us a patch? I already sent it and few others too. CXD2820R is still missing HAS_LOCK bit in DVB-C mode... This change introduces too many bugs as I have been fixing those whole day and not even found all yet. But now I got that error: [crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device or resource busy while opening /dev/dvb/adapter0/frontend0 Changing delivery system to: DVBC/ANNEX_A Segmentation fault (core dumped) There was a bug at the error code handling on dvb-fe-tool: basically, if it can't open a device, it were using a NULL pointer. It was likely fixed by this commit: http://git.linuxtv.org/v4l-utils.git/commit/1f669eed5433d17df4d8fb1fa43d2886f99d3991 OK, will try. Thanks Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] DVBv5 tools version 0.0.1
On 01/15/2012 11:08 PM, Mauro Carvalho Chehab wrote: There was a bug at the error code handling on dvb-fe-tool: basically, if it can't open a device, it were using a NULL pointer. It was likely fixed by this commit: http://git.linuxtv.org/v4l-utils.git/commit/1f669eed5433d17df4d8fb1fa43d2886f99d3991 That bug was fixed as I tested. But could you tell why dvb-fe-tool --set-delsys=DVBC/ANNEX_A calls get_frontent() ? That will cause this kind of calls in demod driver: init() get_frontend() get_frontend() sleep() My guess is that it resolves current delivery system. But as demod is usually sleeping (not tuned) at that phase it does not know frontend settings asked, like modulation etc. In case of cxd2820r those are available after set_frontend() call. I think I will add check and return -EINVAL in that case. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] DVBv5 tools version 0.0.1
Em 15-01-2012 19:47, Antti Palosaari escreveu:
On 01/15/2012 11:08 PM, Mauro Carvalho Chehab wrote:
There was a bug at the error code handling on dvb-fe-tool: basically, if it
can't open
a device, it were using a NULL pointer. It was likely fixed by this commit:
http://git.linuxtv.org/v4l-utils.git/commit/1f669eed5433d17df4d8fb1fa43d2886f99d3991
That bug was fixed as I tested.
But could you tell why dvb-fe-tool --set-delsys=DVBC/ANNEX_A calls
get_frontent() ?
That's what happens here, at the application level:
$ strace dvb-fe-tool -d DVBC/ANNEX_A
open(/dev/dvb/adapter0/frontend0, O_RDWR) = 3
ioctl(3, FE_GET_INFO, 0xb070c4) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f37922be000
write(1, Device DRXK DVB-C DVB-T (/dev/dv..., 68Device DRXK DVB-C DVB-T
(/dev/dvb/adapter0/frontend0) capabilities:
) = 68
write(1, \tCAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC..., 245CAN_FEC_1_2 CAN_FEC_2_3
CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO
CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_32
CAN_QAM_64 CAN_QAM_128 CAN_QAM_256 CAN_RECOVER CAN_TRANSMISSION_MODE_AUTO
) = 245
ioctl(3, FE_GET_PROPERTY, 0x7fff326ce310) = 0
write(1, DVB API Version 5.5, Current v5 ..., 54DVB API Version 5.5, Current
v5 delivery system: DVBT
) = 54
ioctl(3, FE_GET_PROPERTY, 0x7fff326ce310) = 0
write(1, Supported delivery systems: DVBC..., 62Supported delivery systems:
DVBC/ANNEX_A DVBC/ANNEX_C [DVBT]
) = 62
write(1, Changing delivery system to: DVB..., 42Changing delivery system to:
DVBC/ANNEX_A
) = 42
ioctl(3, FE_SET_PROPERTY, 0x7fff326ce340) = 0
close(3)= 0
exit_group(0) = ?
The first FE_GET_PROPERTY reads the DVB API version and the current delivery
system:
parms-dvb_prop[0].cmd = DTV_API_VERSION;
parms-dvb_prop[1].cmd = DTV_DELIVERY_SYSTEM;
dtv_prop.num = 2;
dtv_prop.props = parms-dvb_prop;
/* Detect a DVBv3 device */
if (ioctl(fd, FE_GET_PROPERTY, dtv_prop) == -1) {
parms-dvb_prop[0].u.data = 0x300;
parms-dvb_prop[1].u.data = SYS_UNDEFINED;
}
parms-version = parms-dvb_prop[0].u.data;
parms-current_sys = parms-dvb_prop[1].u.data;
The second FE_GET_PROPERTY is used only if DVB API v5.5 or upper is detected,
and does:
parms-dvb_prop[0].cmd = DTV_ENUM_DELSYS;
parms-n_props = 1;
dtv_prop.num = 1;
dtv_prop.props = parms-dvb_prop;
if (ioctl(fd, FE_GET_PROPERTY, dtv_prop) == -1) {
perror(FE_GET_PROPERTY);
dvb_v5_free(parms);
close(fd);
return NULL;
}
Both were called inside dvb_fe_open().
The FE_SET_PROPERTY changes the property inside the DVBv5 cache,
at dvb_set_sys():
dvb_prop[0].cmd = DTV_DELIVERY_SYSTEM;
dvb_prop[0].u.data = sys;
prop.num = 1;
prop.props = dvb_prop;
if (ioctl(parms-fd, FE_SET_PROPERTY, prop) == -1) {
perror(Set delivery system);
return errno;
}
The FE_SET_PROPERTY doesn't call a DTV_TUNE, so it shouldn't be calling the
set frontend methods inside the driver.
So, from the userspace applications standpoint, I'm not seeing anything wrong.
That will cause this kind of calls in demod driver:
init()
get_frontend()
get_frontend()
sleep()
My guess is that it resolves current delivery system. But as demod is usually
sleeping (not tuned) at that phase it does not know frontend settings asked,
like modulation etc. In case of cxd2820r those are available after
set_frontend() call. I think I will add check and return -EINVAL in that case.
What seems to be happening at dvb-core/dvb_frontend.h is due to this code:
if(cmd == FE_GET_PROPERTY) {
...
/*
* Fills the cache out struct with the cache contents, plus
* the data retrieved from get_frontend.
*/
dtv_get_frontend(fe, NULL);
for (i = 0; i tvps-num; i++) {
err = dtv_property_process_get(fe, c, tvp + i, file);
if (err 0)
goto out;
(tvp + i)-result = err;
}
E. g. even if the FE_GET_PROPERTY is only reading the DVB version and calling
DTV_ENUM_DELSYS, it is calling the dtv_get_frontend() to retrieve more data.
What it can be done is to do something like:
static bool need_get_frontend()
{
...
for (i = 0; i tvps-num; i++)
...
}
if (need_get_frontend(tvps))
dtv_get_frontend(fe, NULL);
for (i = 0; i tvps-num; i++)
Re: [ANNOUNCE] DVBv5 tools version 0.0.1
Em 15-01-2012 22:16, Mauro Carvalho Chehab escreveu:
Em 15-01-2012 19:47, Antti Palosaari escreveu:
On 01/15/2012 11:08 PM, Mauro Carvalho Chehab wrote:
There was a bug at the error code handling on dvb-fe-tool: basically, if it
can't open
a device, it were using a NULL pointer. It was likely fixed by this commit:
http://git.linuxtv.org/v4l-utils.git/commit/1f669eed5433d17df4d8fb1fa43d2886f99d3991
That bug was fixed as I tested.
But could you tell why dvb-fe-tool --set-delsys=DVBC/ANNEX_A calls
get_frontent() ?
That's what happens here, at the application level:
$ strace dvb-fe-tool -d DVBC/ANNEX_A
open(/dev/dvb/adapter0/frontend0, O_RDWR) = 3
ioctl(3, FE_GET_INFO, 0xb070c4) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f37922be000
write(1, Device DRXK DVB-C DVB-T (/dev/dv..., 68Device DRXK DVB-C DVB-T
(/dev/dvb/adapter0/frontend0) capabilities:
) = 68
write(1, \tCAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC..., 245 CAN_FEC_1_2 CAN_FEC_2_3
CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO
CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_32
CAN_QAM_64 CAN_QAM_128 CAN_QAM_256 CAN_RECOVER CAN_TRANSMISSION_MODE_AUTO
) = 245
ioctl(3, FE_GET_PROPERTY, 0x7fff326ce310) = 0
write(1, DVB API Version 5.5, Current v5 ..., 54DVB API Version 5.5,
Current v5 delivery system: DVBT
) = 54
ioctl(3, FE_GET_PROPERTY, 0x7fff326ce310) = 0
write(1, Supported delivery systems: DVBC..., 62Supported delivery systems:
DVBC/ANNEX_A DVBC/ANNEX_C [DVBT]
) = 62
write(1, Changing delivery system to: DVB..., 42Changing delivery system
to: DVBC/ANNEX_A
) = 42
ioctl(3, FE_SET_PROPERTY, 0x7fff326ce340) = 0
close(3)= 0
exit_group(0) = ?
The first FE_GET_PROPERTY reads the DVB API version and the current delivery
system:
parms-dvb_prop[0].cmd = DTV_API_VERSION;
parms-dvb_prop[1].cmd = DTV_DELIVERY_SYSTEM;
dtv_prop.num = 2;
dtv_prop.props = parms-dvb_prop;
/* Detect a DVBv3 device */
if (ioctl(fd, FE_GET_PROPERTY, dtv_prop) == -1) {
parms-dvb_prop[0].u.data = 0x300;
parms-dvb_prop[1].u.data = SYS_UNDEFINED;
}
parms-version = parms-dvb_prop[0].u.data;
parms-current_sys = parms-dvb_prop[1].u.data;
The second FE_GET_PROPERTY is used only if DVB API v5.5 or upper is detected,
and does:
parms-dvb_prop[0].cmd = DTV_ENUM_DELSYS;
parms-n_props = 1;
dtv_prop.num = 1;
dtv_prop.props = parms-dvb_prop;
if (ioctl(fd, FE_GET_PROPERTY, dtv_prop) == -1) {
perror(FE_GET_PROPERTY);
dvb_v5_free(parms);
close(fd);
return NULL;
}
Both were called inside dvb_fe_open().
The FE_SET_PROPERTY changes the property inside the DVBv5 cache,
at dvb_set_sys():
dvb_prop[0].cmd = DTV_DELIVERY_SYSTEM;
dvb_prop[0].u.data = sys;
prop.num = 1;
prop.props = dvb_prop;
if (ioctl(parms-fd, FE_SET_PROPERTY, prop) == -1) {
perror(Set delivery system);
return errno;
}
The FE_SET_PROPERTY doesn't call a DTV_TUNE, so it shouldn't be calling the
set frontend methods inside the driver.
So, from the userspace applications standpoint, I'm not seeing anything wrong.
That will cause this kind of calls in demod driver:
init()
get_frontend()
get_frontend()
sleep()
My guess is that it resolves current delivery system. But as demod is
usually sleeping (not tuned) at that phase it does not know frontend
settings asked, like modulation etc. In case of cxd2820r those are available
after set_frontend() call. I think I will add check and return -EINVAL in
that case.
What seems to be happening at dvb-core/dvb_frontend.h is due to this code:
if(cmd == FE_GET_PROPERTY) {
...
/*
* Fills the cache out struct with the cache contents, plus
* the data retrieved from get_frontend.
*/
dtv_get_frontend(fe, NULL);
for (i = 0; i tvps-num; i++) {
err = dtv_property_process_get(fe, c, tvp + i, file);
if (err 0)
goto out;
(tvp + i)-result = err;
}
E. g. even if the FE_GET_PROPERTY is only reading the DVB version and calling
DTV_ENUM_DELSYS, it is calling the dtv_get_frontend() to retrieve more data.
What it can be done is to do something like:
static bool need_get_frontend()
{
...
for (i = 0; i tvps-num; i++)
...
}
if
Re: [ANNOUNCE] DVBv5 tools version 0.0.1
Behaviour of new FE is strange for my eyes. Could you look and explain if it is intentional? [crope@localhost dvb]$ ./dvb-fe-tool Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO DVB API Version 5.5, Current v5 delivery system: DVBT Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A [crope@localhost dvb]$ czap MTV3 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '/home/crope/.czap/channels.conf' 11 MTV3 :33000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128:305:561:3 11 MTV3 : f 33000, s 6875000, i 2, fec 0, qam 4, v 0x131, a 0x231, s 0x3 ERROR: frontend device is not a QAM (DVB-C) device [crope@localhost dvb]$ ./dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO DVB API Version 5.5, Current v5 delivery system: DVBT Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A Changing delivery system to: DVBC/ANNEX_A [crope@localhost dvb]$ ./dvb-fe-tool Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO DVB API Version 5.5, Current v5 delivery system: DVBC/ANNEX_A Supported delivery systems: DVBT DVBT2 [DVBC/ANNEX_A] [crope@localhost dvb]$ czap MTV3 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '/home/crope/.czap/channels.conf' 11 MTV3 :33000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128:305:561:3 11 MTV3 : f 33000, s 6875000, i 2, fec 0, qam 4, v 0x131, a 0x231, s 0x3 status 00 | signal | snr 00c6 | ber | unc | ^C [crope@localhost dvb]$ ./dvb-fe-tool Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO DVB API Version 5.5, Current v5 delivery system: DVBT Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A [crope@localhost dvb]$ czap MTV3 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '/home/crope/.czap/channels.conf' 11 MTV3 :33000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128:305:561:3 11 MTV3 : f 33000, s 6875000, i 2, fec 0, qam 4, v 0x131, a 0x231, s 0x3 ERROR: frontend device is not a QAM (DVB-C) device [crope@localhost dvb]$ ./dvb-fe-tool Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO DVB API Version 5.5, Current v5 delivery system: DVBT Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A [crope@localhost dvb]$ -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] DVBv5 tools version 0.0.1
On 10-01-2012 19:36, Antti Palosaari wrote: Behaviour of new FE is strange for my eyes. Could you look and explain if it is intentional? [crope@localhost dvb]$ ./dvb-fe-tool Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO DVB API Version 5.5, Current v5 delivery system: DVBT Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A [crope@localhost dvb]$ czap MTV3 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '/home/crope/.czap/channels.conf' 11 MTV3 :33000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128:305:561:3 11 MTV3 : f 33000, s 6875000, i 2, fec 0, qam 4, v 0x131, a 0x231, s 0x3 ERROR: frontend device is not a QAM (DVB-C) device The selected delivery system is DVB-T. As czap doesn't have any code to force it to DVB-C, this is expected. Basically, czap needs a patch like this one: http://linuxtv.org/hg/dvb-apps/rev/0c9932885287 (I've made the patch for scan just as an example, but I'll hardly have enough time to fix it everything inside dvb-apps) [crope@localhost dvb]$ ./dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO DVB API Version 5.5, Current v5 delivery system: DVBT Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A Changing delivery system to: DVBC/ANNEX_A [crope@localhost dvb]$ ./dvb-fe-tool Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO DVB API Version 5.5, Current v5 delivery system: DVBC/ANNEX_A Supported delivery systems: DVBT DVBT2 [DVBC/ANNEX_A] [crope@localhost dvb]$ czap MTV3 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '/home/crope/.czap/channels.conf' 11 MTV3 :33000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128:305:561:3 11 MTV3 : f 33000, s 6875000, i 2, fec 0, qam 4, v 0x131, a 0x231, s 0x3 status 00 | signal | snr 00c6 | ber | unc | Ok, it worked. [crope@localhost dvb]$ ./dvb-fe-tool Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO DVB API Version 5.5, Current v5 delivery system: DVBT Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A That's weird. The dvb_frontend_clear_cache() returns the delivery system to its original state. The enclosed patch will likely fix this issue. - [PATCH] don't reset the delivery system on DTV_CLEAR Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c index a904793..4ff4b43 100644 --- a/drivers/media/dvb/dvb-core/dvb_frontend.c +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c @@ -909,7 +909,6 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe) c-state = DTV_CLEAR; - c-delivery_system = fe-ops.delsys[0]; dprintk(%s() Clearing cache for delivery system %d\n, __func__, c-delivery_system); @@ -2377,6 +2376,8 @@ int dvb_register_frontend(struct dvb_adapter* dvb, * Initialize the cache to the proper values according with the * first supported delivery system (ops-delsys[0]) */ + + c-delivery_system = fe-ops.delsys[0]; dvb_frontend_clear_cache(fe); mutex_unlock(frontend_mutex); -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dvbv5-tools update - was: Re: [ANNOUNCE] DVBv5 tools version 0.0.1
On 07-01-2012 23:52, Mauro Carvalho Chehab wrote: I decided to add support for DVB-S, even without signal for testing. This probably means that it likely will not work ;) Well, seriously, we need testers for it. The current code should be doing the same that szap does, and should work with both dvbv5-zap and dvbv5-scan. The DISEqC code there is very simple, and there's no support for dishpro/bandstacking yet. It is probably not hard to add support for it. There are still a few things missing there. For example, the current code will only use DISEqC satellite #0, as there's no code to change the satellite number yet. Anyway, testing and patches are welcome! I decided to rewrite the DISEqC code on it, in order to fix some bugs, and make the code clearer. The updates are at the tree: http://git.linuxtv.org/v4l-utils.git Basically, additional parameters for satellite delivery systems are now added to the zap and scan tools: - l lnbf selects the LNBf type. Using an invalid value like help shows what's currently supported. - S sat_number Selects satellite number, between 0 to 3. If not specified, disables DISEqC. This actually changes the DISEqC option and position parameter. According with the specs, for position B, tone should be off, and tone burst should be miniA. -W extra time in ms The DISEqC logic will wait for 15 ms. If this parameter is specified, it will add the extra time to the 15ms delay. For LNBf devices that use bandstacking (e. g. they use different LO frequrencies for V and H polarization), the code will always use 13 Volts and will disable tone/tone burst. Currently, C-Band multi and DishPro bandstacking LNBf's are supported. The code should now work with the following LNBfs: UNIVERSAL Europe 10800 to 11800 MHz and 11600 to 12700 MHz Dual LO, IF = lowband 9750 MHz, highband 10600 MHz DBS Expressvu, North America 12200 to 12700 MHz Single LO, IF = 11250 MHz STANDARD Standard 10945 to 11450 MHz Single LO, IF = 1 MHz ENHANCED Astra 10700 to 11700 MHz Single LO, IF = 9750 MHz C-BAND Big Dish - Monopoint LNBf 3700 to 4200 MHz Single LO, IF = 5150 MHz C-MULT Big Dish - Multipoint LNBf 3700 to 4200 MHz Dual LO, Bandstacking, LO POL_R 5150 MHZ, LO POL_L 5750 MHz DISHPRO DishPro LNBf 12200 to 12700 MHz Dual LO, Bandstacking, LO POL_R 11250 MHZ, LO POL_L 14350 MHz Tests are needed! Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] DVBv5 tools version 0.0.1
Hi Mauro. 2012/1/7 Mauro Carvalho Chehab mche...@redhat.com: As previously commented at the ML, I'm developing a set of tools using DVBv5 API. Instead of starting from something existing, I decided to start from scratch, in order to avoid polluting it with DVBv3 legacy stuff. Of course, I did some research inside the existing tools, in order to fill in the blanks, using the dvb-apps tzap as a reference for the first real application on it, but removing a large amount of code (file parsers, etc). They're now on a good shape, at least for my own usage ;) In order to test, you should use: git clone git://linuxtv.org/mchehab/experimental-v4l-utils.git And then run make. the utils are inside utils/dvb. Am I doing something wrong? After clone I can't find dvb subdirectory inside utils: [hop@localhost experimental-v4l-utils (master)]$ ll utils/ celkem 48 drwxr-xr-x 2 hop hop 4096 led 7 18:21 decode_tm6000/ drwxr-xr-x 3 hop hop 4096 led 7 18:21 keytable/ drwxr-xr-x 2 hop hop 4096 led 7 18:21 libmedia_dev/ drwxr-xr-x 2 hop hop 4096 led 7 18:21 libv4l2util/ -rw-r--r-- 1 hop hop 947 led 7 18:21 Makefile drwxr-xr-x 2 hop hop 4096 led 7 18:21 qv4l2/ drwxr-xr-x 2 hop hop 4096 led 7 18:21 rds/ drwxr-xr-x 2 hop hop 4096 led 7 18:21 v4l2-compliance/ drwxr-xr-x 2 hop hop 4096 led 7 18:21 v4l2-ctl/ drwxr-xr-x 2 hop hop 4096 led 7 18:21 v4l2-dbg/ drwxr-xr-x 2 hop hop 4096 led 7 18:21 v4l2-sysfs-path/ drwxr-xr-x 2 hop hop 4096 led 7 18:21 xc3028-firmware/ Honza -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] DVBv5 tools version 0.0.1
On 07-01-2012 15:29, Honza Petrouš wrote: Hi Mauro. 2012/1/7 Mauro Carvalho Chehab mche...@redhat.com: As previously commented at the ML, I'm developing a set of tools using DVBv5 API. Instead of starting from something existing, I decided to start from scratch, in order to avoid polluting it with DVBv3 legacy stuff. Of course, I did some research inside the existing tools, in order to fill in the blanks, using the dvb-apps tzap as a reference for the first real application on it, but removing a large amount of code (file parsers, etc). They're now on a good shape, at least for my own usage ;) In order to test, you should use: git clone git://linuxtv.org/mchehab/experimental-v4l-utils.git And then run make. the utils are inside utils/dvb. Am I doing something wrong? After clone I can't find dvb subdirectory inside utils: Huh... sorry, you need to specify the branch as well. The correct syntax would be: git clone git://linuxtv.org/mchehab/experimental-v4l-utils.git dvbv5-0.0.1 it is likely that git clone has already fetched this branch as well, so, now that you've cloned it, you can do: git remote update git checkout origin/dvbv5-0.0.1 In order to build, you need to run make two times (the first one will run automake tools, and the second one will actually compile everything). After running the first make, you can just go to utils/dvb and run make from there, if you don't want to compile everything. [hop@localhost experimental-v4l-utils (master)]$ ll utils/ celkem 48 drwxr-xr-x 2 hop hop 4096 led 7 18:21 decode_tm6000/ drwxr-xr-x 3 hop hop 4096 led 7 18:21 keytable/ drwxr-xr-x 2 hop hop 4096 led 7 18:21 libmedia_dev/ drwxr-xr-x 2 hop hop 4096 led 7 18:21 libv4l2util/ -rw-r--r-- 1 hop hop 947 led 7 18:21 Makefile drwxr-xr-x 2 hop hop 4096 led 7 18:21 qv4l2/ drwxr-xr-x 2 hop hop 4096 led 7 18:21 rds/ drwxr-xr-x 2 hop hop 4096 led 7 18:21 v4l2-compliance/ drwxr-xr-x 2 hop hop 4096 led 7 18:21 v4l2-ctl/ drwxr-xr-x 2 hop hop 4096 led 7 18:21 v4l2-dbg/ drwxr-xr-x 2 hop hop 4096 led 7 18:21 v4l2-sysfs-path/ drwxr-xr-x 2 hop hop 4096 led 7 18:21 xc3028-firmware/ Honza -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] DVBv5 tools version 0.0.1
On 07-01-2012 10:19, Mauro Carvalho Chehab wrote: As previously commented at the ML, I'm developing a set of tools using DVBv5 API. Instead of starting from something existing, I decided to start from scratch, in order to avoid polluting it with DVBv3 legacy stuff. Of course, I did some research inside the existing tools, in order to fill in the blanks, using the dvb-apps tzap as a reference for the first real application on it, but removing a large amount of code (file parsers, etc). They're now on a good shape, at least for my own usage ;) In order to test, you should use: git clone git://linuxtv.org/mchehab/experimental-v4l-utils.git And then run make. the utils are inside utils/dvb. I plan to do some cleanup at the patches later (basically, changing the patch descriptions), and add it inside the v4l-utils, in order to have the basic tools I use for testing media devices into the same place. DVB TOOLS = This is a series of tools written to help testing and working with DVB, using its latest V5 API. The tools can also work with the DVBv3 API. The current tools are: dvb-fe-tool - a simple test application, that reads from the frontend. it also allows to change the default delivery system. In the future, it may be used to change any property via command line. dvb-format-convert - converts from zap and scan initial-tuning-data-file into the new format defined to work with DVBv5; dvbv5-scan - a DVBv5 scan tool; dvbv5-zap - a DVBv5 zap tool. It allow to tune into a DVB channel, and to watch to a DVB service (e. g. receiving the video and audio streams, via another application using the dvr device). Each application code is very small, as most of the code are on some generic code that will become a library in the future. CONTENTS OF THE TREE parse_string.c/parse_string.h: MPEG-TS string decoder with charset translator Used to decode NIT/SDT service name, network provider and provider name. It parses the charsets according with the DVB specs, converting them into UTF-8 (or other charset), using iconv library. descriptors.c/descriptors.h: MPEG-TS descriptors parser The code there is generig enough to decode the MPEG-TS descriptors, with the DVB and other Digital TV extensions. libscan.c/libscan/h: DVBv5 scanning library This library is used to retrieve DVB information from the MPEG TS headers, discovering the services associated to each DVB channel or transponder. The services information is the basic info that most DVB tools need to tune into a channel. dvb-file.c/dvb-file.h: DVB file read/write library. Allows parsing a DVB file (legacy or not) and to write data into a DVB file (new format only). dvb-fe.c/dvb-fe.h: DVB frontend library. Allows talking with a DVB frontend via DVBv5 or DVBv3 API. dvb-zap-format.c/dvb-legacy-channel-format.c: Contains the data structures required in order to read from the legacy formats (zap or scan initial-tuning-data-file). dvb_frontend.h: DVBv5 frontend API. This is just a copy of the newest linux/dvb/frontend.h header. I opted to keep a copy there, in order to allow working with the tools without needing to copy the latest header into /usr/include. dvb-v5.h/dvb-v5-std.h: Ancillary files linked into dvb-fe code, used to parse DVB tables. The dvbv5.h is generated by a small perl util, from the DVB FE API file. dvb-demux.c/dvb-demux.h: DVB demux library. Used by the dvbv5-zap utility. dvb-fe-tool.c, dvb-format-convert.c, dvbv5-zap.c, dvbv5-scan.c: tools code. Basically, parses the options from userspace and calls the other code to do what was requested by the user. CHANNEL/SERVICE FILE FORMAT === Instead of having two different files, one for services, and another for channels/transponders, I opted to use just one format for both. The format is: [channel] key1=value1 key2=value2 key3=value3 ... keyn=valuen lines with # are discarted by the parsers. Also, whitespaces/tabs before the keys and before/after the equal sign. Be careful: whitespace in the middle of the value are not discarded. A typical service would be like: [TV Brasil HD] VCHANNEL = 2.2 SERVICE_ID = 16160 VIDEO_PID = 770 AUDIO_PID = 514 614 FREQUENCY = 479142857 MODULATION = QAM/AUTO BANDWIDTH_HZ = 600 INVERSION = AUTO CODE_RATE_HP = AUTO CODE_RATE_LP = NONE GUARD_INTERVAL = AUTO TRANSMISSION_MODE = AUTO HIERARCHY = NONE ISDBT_LAYER_ENABLED = 7 ISDBT_PARTIAL_RECEPTION = 0 ISDBT_SOUND_BROADCASTING = 0 ISDBT_SB_SUBCHANNEL_ID = 0 ISDBT_SB_SEGMENT_IDX = 0 ISDBT_SB_SEGMENT_COUNT = 0 ISDBT_LAYERA_FEC = AUTO ISDBT_LAYERA_MODULATION = QAM/AUTO
