All of lore.kernel.org
 help / color / mirror / Atom feed
* [ANNOUNCE] DVBv5 tools version 0.0.1
@ 2012-01-07 12:19 Mauro Carvalho Chehab
  2012-01-07 17:29 ` Honza Petrouš
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Mauro Carvalho Chehab @ 2012-01-07 12:19 UTC (permalink / raw)
  To: Linux Media Mailing List

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 = 6000000
        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
        ISDBT_LAYERA_SEGMENT_COUNT = 0
        ISDBT_LAYERA_TIME_INTERLEAVING = 0
        ISDBT_LAYERB_FEC = AUTO
        ISDBT_LAYERB_MODULATION = QAM/AUTO
        ISDBT_LAYERB_SEGMENT_COUNT = 0
        ISDBT_LAYERB_TIME_INTERLEAVING = 0
        ISDBT_LAYERC_FEC = AUTO
        ISDBT_LAYERC_MODULATION = QAM/AUTO
        ISDBT_LAYERC_SEGMENT_COUNT = 0
        ISDBT_LAYERC_TIME_INTERLEAVING = 0
        DELIVERY_SYSTEM = ISDBT

Just the channel description for it would be:

[CHANNEL]
        FREQUENCY = 479142857
        MODULATION = QAM/AUTO
        BANDWIDTH_HZ = 6000000
        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
        ISDBT_LAYERA_SEGMENT_COUNT = 0
        ISDBT_LAYERA_TIME_INTERLEAVING = 0
        ISDBT_LAYERB_FEC = AUTO
        ISDBT_LAYERB_MODULATION = QAM/AUTO
        ISDBT_LAYERB_SEGMENT_COUNT = 0
        ISDBT_LAYERB_TIME_INTERLEAVING = 0
        ISDBT_LAYERC_FEC = AUTO
        ISDBT_LAYERC_MODULATION = QAM/AUTO
        ISDBT_LAYERC_SEGMENT_COUNT = 0
        ISDBT_LAYERC_TIME_INTERLEAVING = 0
        DELIVERY_SYSTEM = ISDBT

CURRENT ISSUES
==============

The dvb-fe-tool and the dvb-format-convert are generic enough to work
with all delivery systems. However, the other two tools need to do
some diferent things, depending on the delivery system.

I'm currently with only ISDB-T signals here, so the other two
tools were tested only with it.

The dvbv5-zap in general won't work with Satellite delivery
systems. It lacks polarity settings, and it doesn't know anything
about LNB or DISEqC. It shouldn't hard to port those things into it, 
but a DVB-S signal is needed to test. As I don't have it curently,
I'm not working to add support for it at the moment. 

Patches are welcome.

The dvbv5-scan also won't work with Satellite delivery systems
due to the same reasons.

Patches are welcome.

The dvbv5-scan should likely work with the other standards, but the
descriptor parser for NIT, PAT, PMT and SDT tables are fine-tuned
for ISDB-T. Adding more parsed info there could help to improve the
detected things, like virtual channels. Maybe some additional
tables would need to be parsed for ATSC.

It also doesn't current look inside the network descriptors to get
other transponders. So, on DVB-C, it will only get the channels
at the main frequency. I should fix it in a near future.

It is very likely that it will work as-is for DVB-T. 

If someone wants to patch the code to improve the tool, the descriptors
parser is inside descriptors.c file. The scan code that uses it is
at libscan.c. Finally, the data structure used by the scan parsing
is at libscan.h. The procedure is basicallt to add a new data field inside
the libscan.h structures, and then change the descriptors.c file
to fill it.

The main structure is this one:

struct dvb_descriptors {
        int verbose;

        struct pat_table pat_table;
        struct nit_table nit_table;
        struct sdt_table sdt_table;

        /* Used by descriptors to know where to update a PMT/Service/TS */
        unsigned cur_pmt;
        unsigned cur_service;
        unsigned cur_ts;
};

While parsing each table, the current item being parsed is pointed by
one of those unsigned values: cur_pmt, cur_service, cur_ts. Use this
to fill the data structure.

The dvb-file will likely need changes too, in order to write the
parsed information inside the channels file.

Patches are welcome!

Regards,
Mauro

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [ANNOUNCE] DVBv5 tools version 0.0.1
  2012-01-07 12:19 [ANNOUNCE] DVBv5 tools version 0.0.1 Mauro Carvalho Chehab
@ 2012-01-07 17:29 ` Honza Petrouš
  2012-01-07 20:05   ` Mauro Carvalho Chehab
  2012-01-08  1:52 ` Mauro Carvalho Chehab
  2012-01-10 21:36 ` Antti Palosaari
  2 siblings, 1 reply; 14+ messages in thread
From: Honza Petrouš @ 2012-01-07 17:29 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List

Hi Mauro.

2012/1/7 Mauro Carvalho Chehab <mchehab@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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [ANNOUNCE] DVBv5 tools version 0.0.1
  2012-01-07 17:29 ` Honza Petrouš
@ 2012-01-07 20:05   ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 14+ messages in thread
From: Mauro Carvalho Chehab @ 2012-01-07 20:05 UTC (permalink / raw)
  To: Honza Petrouš; +Cc: Linux Media Mailing List

On 07-01-2012 15:29, Honza Petrouš wrote:
> Hi Mauro.
> 
> 2012/1/7 Mauro Carvalho Chehab <mchehab@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [ANNOUNCE] DVBv5 tools version 0.0.1
  2012-01-07 12:19 [ANNOUNCE] DVBv5 tools version 0.0.1 Mauro Carvalho Chehab
  2012-01-07 17:29 ` Honza Petrouš
@ 2012-01-08  1:52 ` Mauro Carvalho Chehab
  2012-01-08 12:57   ` dvbv5-tools update - was: " Mauro Carvalho Chehab
  2012-01-10 21:36 ` Antti Palosaari
  2 siblings, 1 reply; 14+ messages in thread
From: Mauro Carvalho Chehab @ 2012-01-08  1:52 UTC (permalink / raw)
  To: Linux Media Mailing List

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 = 6000000
>         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
>         ISDBT_LAYERA_SEGMENT_COUNT = 0
>         ISDBT_LAYERA_TIME_INTERLEAVING = 0
>         ISDBT_LAYERB_FEC = AUTO
>         ISDBT_LAYERB_MODULATION = QAM/AUTO
>         ISDBT_LAYERB_SEGMENT_COUNT = 0
>         ISDBT_LAYERB_TIME_INTERLEAVING = 0
>         ISDBT_LAYERC_FEC = AUTO
>         ISDBT_LAYERC_MODULATION = QAM/AUTO
>         ISDBT_LAYERC_SEGMENT_COUNT = 0
>         ISDBT_LAYERC_TIME_INTERLEAVING = 0
>         DELIVERY_SYSTEM = ISDBT
> 
> Just the channel description for it would be:
> 
> [CHANNEL]
>         FREQUENCY = 479142857
>         MODULATION = QAM/AUTO
>         BANDWIDTH_HZ = 6000000
>         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
>         ISDBT_LAYERA_SEGMENT_COUNT = 0
>         ISDBT_LAYERA_TIME_INTERLEAVING = 0
>         ISDBT_LAYERB_FEC = AUTO
>         ISDBT_LAYERB_MODULATION = QAM/AUTO
>         ISDBT_LAYERB_SEGMENT_COUNT = 0
>         ISDBT_LAYERB_TIME_INTERLEAVING = 0
>         ISDBT_LAYERC_FEC = AUTO
>         ISDBT_LAYERC_MODULATION = QAM/AUTO
>         ISDBT_LAYERC_SEGMENT_COUNT = 0
>         ISDBT_LAYERC_TIME_INTERLEAVING = 0
>         DELIVERY_SYSTEM = ISDBT
> 
> CURRENT ISSUES
> ==============
> 
> The dvb-fe-tool and the dvb-format-convert are generic enough to work
> with all delivery systems. However, the other two tools need to do
> some diferent things, depending on the delivery system.
> 
> I'm currently with only ISDB-T signals here, so the other two
> tools were tested only with it.
> 
> The dvbv5-zap in general won't work with Satellite delivery
> systems. It lacks polarity settings, and it doesn't know anything
> about LNB or DISEqC. It shouldn't hard to port those things into it, 
> but a DVB-S signal is needed to test. As I don't have it curently,
> I'm not working to add support for it at the moment. 
> 
> Patches are welcome.

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!

Regards,
Mauro

^ permalink raw reply	[flat|nested] 14+ messages in thread

* dvbv5-tools update - was: Re: [ANNOUNCE] DVBv5 tools version 0.0.1
  2012-01-08  1:52 ` Mauro Carvalho Chehab
@ 2012-01-08 12:57   ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 14+ messages in thread
From: Mauro Carvalho Chehab @ 2012-01-08 12:57 UTC (permalink / raw)
  To: Linux Media Mailing List

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 = 10000 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [ANNOUNCE] DVBv5 tools version 0.0.1
  2012-01-07 12:19 [ANNOUNCE] DVBv5 tools version 0.0.1 Mauro Carvalho Chehab
  2012-01-07 17:29 ` Honza Petrouš
  2012-01-08  1:52 ` Mauro Carvalho Chehab
@ 2012-01-10 21:36 ` Antti Palosaari
  2012-01-10 22:00   ` Mauro Carvalho Chehab
  2 siblings, 1 reply; 14+ messages in thread
From: Antti Palosaari @ 2012-01-10 21:36 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List

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 :330000000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128:305:561:3
  11 MTV3 : f 330000000, 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 :330000000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128:305:561:3
  11 MTV3 : f 330000000, s 6875000, i 2, fec 0, qam 4, v 0x131, a 0x231, 
s 0x3
status 00 | signal ffff | snr 00c6 | ber 00000000 | unc 00000000 |
^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 :330000000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128:305:561:3
  11 MTV3 : f 330000000, 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/

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [ANNOUNCE] DVBv5 tools version 0.0.1
  2012-01-10 21:36 ` Antti Palosaari
@ 2012-01-10 22:00   ` Mauro Carvalho Chehab
  2012-01-15 18:37     ` Antti Palosaari
  0 siblings, 1 reply; 14+ messages in thread
From: Mauro Carvalho Chehab @ 2012-01-10 22:00 UTC (permalink / raw)
  To: Antti Palosaari; +Cc: Linux Media Mailing List

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 :330000000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128:305:561:3
>  11 MTV3 : f 330000000, 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 :330000000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128:305:561:3
>  11 MTV3 : f 330000000, s 6875000, i 2, fec 0, qam 4, v 0x131, a 0x231, s 0x3
> status 00 | signal ffff | snr 00c6 | ber 00000000 | unc 00000000 |

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 <mchehab@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);


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [ANNOUNCE] DVBv5 tools version 0.0.1
  2012-01-10 22:00   ` Mauro Carvalho Chehab
@ 2012-01-15 18:37     ` Antti Palosaari
  2012-01-15 20:03       ` Antti Palosaari
  0 siblings, 1 reply; 14+ messages in thread
From: Antti Palosaari @ 2012-01-15 18:37 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List

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 <mchehab@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 <mchehab@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 330000000 6875000 0 4
initial transponder 370000000 6875000 0 4
initial transponder 362000000 6875000 0 4
initial transponder 354000000 6875000 0 4
initial transponder 346000000 6875000 0 4
initial transponder 338000000 6875000 0 4
initial transponder 322000000 6875000 0 4
initial transponder 314000000 6875000 0 4
initial transponder 378000000 6875000 0 4
initial transponder 306000000 6875000 0 4
initial transponder 298000000 6875000 0 4
initial transponder 290000000 6875000 0 5
initial transponder 274000000 6875000 0 5
initial transponder 266000000 6875000 0 5
initial transponder 258000000 6875000 0 5
initial transponder 250000000 6875000 0 5
initial transponder 242000000 6875000 0 5
 >>> tune to: 330000000: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 330000000 6875000 0 4
initial transponder 370000000 6875000 0 4
initial transponder 362000000 6875000 0 4
initial transponder 354000000 6875000 0 4
initial transponder 346000000 6875000 0 4
initial transponder 338000000 6875000 0 4
initial transponder 322000000 6875000 0 4
initial transponder 314000000 6875000 0 4
initial transponder 378000000 6875000 0 4
initial transponder 306000000 6875000 0 4
initial transponder 298000000 6875000 0 4
initial transponder 290000000 6875000 0 5
initial transponder 274000000 6875000 0 5
initial transponder 266000000 6875000 0 5
initial transponder 258000000 6875000 0 5
initial transponder 250000000 6875000 0 5
initial transponder 242000000 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 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]$


regards
Antti

-- 
http://palosaari.fi/

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [ANNOUNCE] DVBv5 tools version 0.0.1
  2012-01-15 18:37     ` Antti Palosaari
@ 2012-01-15 20:03       ` Antti Palosaari
  2012-01-15 21:08         ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 14+ messages in thread
From: Antti Palosaari @ 2012-01-15 20:03 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List

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 <mchehab@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 <mchehab@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 330000000 6875000 0 4
> initial transponder 370000000 6875000 0 4
> initial transponder 362000000 6875000 0 4
> initial transponder 354000000 6875000 0 4
> initial transponder 346000000 6875000 0 4
> initial transponder 338000000 6875000 0 4
> initial transponder 322000000 6875000 0 4
> initial transponder 314000000 6875000 0 4
> initial transponder 378000000 6875000 0 4
> initial transponder 306000000 6875000 0 4
> initial transponder 298000000 6875000 0 4
> initial transponder 290000000 6875000 0 5
> initial transponder 274000000 6875000 0 5
> initial transponder 266000000 6875000 0 5
> initial transponder 258000000 6875000 0 5
> initial transponder 250000000 6875000 0 5
> initial transponder 242000000 6875000 0 5
>  >>> tune to: 330000000: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 330000000 6875000 0 4
> initial transponder 370000000 6875000 0 4
> initial transponder 362000000 6875000 0 4
> initial transponder 354000000 6875000 0 4
> initial transponder 346000000 6875000 0 4
> initial transponder 338000000 6875000 0 4
> initial transponder 322000000 6875000 0 4
> initial transponder 314000000 6875000 0 4
> initial transponder 378000000 6875000 0 4
> initial transponder 306000000 6875000 0 4
> initial transponder 298000000 6875000 0 4
> initial transponder 290000000 6875000 0 5
> initial transponder 274000000 6875000 0 5
> initial transponder 266000000 6875000 0 5
> initial transponder 258000000 6875000 0 5
> initial transponder 250000000 6875000 0 5
> initial transponder 242000000 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 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]$

That seems to be due to cxd2820r bug introduced by multi-frontend to 
single-frontend change.


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)
[crope@localhost code]$

I opened device using VLC and then try to switch it to correct mode. But 
it crash and no picture.

Antti


-- 
http://palosaari.fi/

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [ANNOUNCE] DVBv5 tools version 0.0.1
  2012-01-15 20:03       ` Antti Palosaari
@ 2012-01-15 21:08         ` Mauro Carvalho Chehab
  2012-01-15 21:14           ` Antti Palosaari
  2012-01-15 21:47           ` Antti Palosaari
  0 siblings, 2 replies; 14+ messages in thread
From: Mauro Carvalho Chehab @ 2012-01-15 21:08 UTC (permalink / raw)
  To: Antti Palosaari; +Cc: Linux Media Mailing List

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 <mchehab@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 <mchehab@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 330000000 6875000 0 4
>> initial transponder 370000000 6875000 0 4
>> initial transponder 362000000 6875000 0 4
>> initial transponder 354000000 6875000 0 4
>> initial transponder 346000000 6875000 0 4
>> initial transponder 338000000 6875000 0 4
>> initial transponder 322000000 6875000 0 4
>> initial transponder 314000000 6875000 0 4
>> initial transponder 378000000 6875000 0 4
>> initial transponder 306000000 6875000 0 4
>> initial transponder 298000000 6875000 0 4
>> initial transponder 290000000 6875000 0 5
>> initial transponder 274000000 6875000 0 5
>> initial transponder 266000000 6875000 0 5
>> initial transponder 258000000 6875000 0 5
>> initial transponder 250000000 6875000 0 5
>> initial transponder 242000000 6875000 0 5
>>  >>> tune to: 330000000: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 330000000 6875000 0 4
>> initial transponder 370000000 6875000 0 4
>> initial transponder 362000000 6875000 0 4
>> initial transponder 354000000 6875000 0 4
>> initial transponder 346000000 6875000 0 4
>> initial transponder 338000000 6875000 0 4
>> initial transponder 322000000 6875000 0 4
>> initial transponder 314000000 6875000 0 4
>> initial transponder 378000000 6875000 0 4
>> initial transponder 306000000 6875000 0 4
>> initial transponder 298000000 6875000 0 4
>> initial transponder 290000000 6875000 0 5
>> initial transponder 274000000 6875000 0 5
>> initial transponder 266000000 6875000 0 5
>> initial transponder 258000000 6875000 0 5
>> initial transponder 250000000 6875000 0 5
>> initial transponder 242000000 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 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]$
> 
> 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?

> 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


> [crope@localhost code]$
> 
> I opened device using VLC and then try to switch it to correct mode. But it crash and no picture.
> 
> Antti
> 
> 

Regards,
Mauro

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [ANNOUNCE] DVBv5 tools version 0.0.1
  2012-01-15 21:08         ` Mauro Carvalho Chehab
@ 2012-01-15 21:14           ` Antti Palosaari
  2012-01-15 21:47           ` Antti Palosaari
  1 sibling, 0 replies; 14+ messages in thread
From: Antti Palosaari @ 2012-01-15 21:14 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List

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/

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [ANNOUNCE] DVBv5 tools version 0.0.1
  2012-01-15 21:08         ` Mauro Carvalho Chehab
  2012-01-15 21:14           ` Antti Palosaari
@ 2012-01-15 21:47           ` Antti Palosaari
  2012-01-16  0:16             ` Mauro Carvalho Chehab
  1 sibling, 1 reply; 14+ messages in thread
From: Antti Palosaari @ 2012-01-15 21:47 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List

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/

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [ANNOUNCE] DVBv5 tools version 0.0.1
  2012-01-15 21:47           ` Antti Palosaari
@ 2012-01-16  0:16             ` Mauro Carvalho Chehab
  2012-01-16  2:57               ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 14+ messages in thread
From: Mauro Carvalho Chehab @ 2012-01-16  0:16 UTC (permalink / raw)
  To: Antti Palosaari; +Cc: Linux Media Mailing List

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 (need_get_frontend(tvps))
	                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;
                }

And add some logic inside need_get_frontend() to return false if the
FE_GET_PROPERTY only wants static info, like DTV_ENUM_DELSYS, DTV_VERSION
and DTV_DELIVERY_SYSTEM.

Regards,
Mauro.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [ANNOUNCE] DVBv5 tools version 0.0.1
  2012-01-16  0:16             ` Mauro Carvalho Chehab
@ 2012-01-16  2:57               ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 14+ messages in thread
From: Mauro Carvalho Chehab @ 2012-01-16  2:57 UTC (permalink / raw)
  To: Antti Palosaari; +Cc: Linux Media Mailing List

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 (need_get_frontend(tvps))
> 	                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;
>                 }
> 
> And add some logic inside need_get_frontend() to return false if the
> FE_GET_PROPERTY only wants static info, like DTV_ENUM_DELSYS, DTV_VERSION
> and DTV_DELIVERY_SYSTEM.

The enclosed patch should do the trick

-
[PATCH RFC] Don't call get_frontend() if not needed

If the frontend is in idle state, or a FE_GET_PROPERTY is called
for reading the enumsys, api version or delivery system, don't
call the frontend, as it is not needed.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

PS.: There's one extra printk here for test purposes. Of course, this should
be removed at the final version.

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c
index f5fa7aa..3c80c92 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1234,6 +1234,8 @@ static int dtv_get_frontend(struct dvb_frontend *fe,
 {
 	int r;
 
+printk("%s()\n", __func__);
+
 	if (fe->ops.get_frontend) {
 		r = fe->ops.get_frontend(fe);
 		if (unlikely(r < 0))
@@ -1739,12 +1741,35 @@ static int dvb_frontend_ioctl(struct file *file,
 	return err;
 }
 
+static bool need_get_frontend_call(struct dtv_properties *tvps,
+				   struct dtv_property *tvp)
+{
+	int i;
+
+	/*
+	 * If the DTV command is just informational or cache read,
+	 * don't bother to call the frontend to handle.
+	 */
+	for (i = 0; i < tvps->num; i++) {
+		switch(tvp->cmd) {
+		case DTV_ENUM_DELSYS:
+	        case DTV_DELIVERY_SYSTEM:
+		case DTV_API_VERSION:
+			break;
+		default:
+			return true;
+		}
+	}
+	return false;
+}
+
 static int dvb_frontend_ioctl_properties(struct file *file,
 			unsigned int cmd, void *parg)
 {
 	struct dvb_device *dvbdev = file->private_data;
 	struct dvb_frontend *fe = dvbdev->priv;
 	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+	struct dvb_frontend_private *fepriv = fe->frontend_priv;
 	int err = 0;
 
 	struct dtv_properties *tvps = NULL;
@@ -1812,7 +1837,8 @@ static int dvb_frontend_ioctl_properties(struct file *file,
 		 * Fills the cache out struct with the cache contents, plus
 		 * the data retrieved from get_frontend.
 		 */
-		dtv_get_frontend(fe, NULL);
+		if (need_get_frontend_call(tvps, tvp) && fepriv->state != FESTATE_IDLE)
+			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)

^ permalink raw reply related	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2012-01-16  2:57 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-07 12:19 [ANNOUNCE] DVBv5 tools version 0.0.1 Mauro Carvalho Chehab
2012-01-07 17:29 ` Honza Petrouš
2012-01-07 20:05   ` Mauro Carvalho Chehab
2012-01-08  1:52 ` Mauro Carvalho Chehab
2012-01-08 12:57   ` dvbv5-tools update - was: " Mauro Carvalho Chehab
2012-01-10 21:36 ` Antti Palosaari
2012-01-10 22:00   ` Mauro Carvalho Chehab
2012-01-15 18:37     ` Antti Palosaari
2012-01-15 20:03       ` Antti Palosaari
2012-01-15 21:08         ` Mauro Carvalho Chehab
2012-01-15 21:14           ` Antti Palosaari
2012-01-15 21:47           ` Antti Palosaari
2012-01-16  0:16             ` Mauro Carvalho Chehab
2012-01-16  2:57               ` Mauro Carvalho Chehab

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.