DVB new get info ioctl
(too old to reply)
Mauro Carvalho Chehab
2014-10-20 20:16:40 UTC
Hi Michael,

As you know, one of the topics discussed during the last Media Summit were about
writing a new ioctl to replace FE_GET_INFO's fe_caps.

The summary of our discussions follow bellow:
(mental note: I should put the description below on our mini-summit notes):

The main issue with fe_caps is that, currently, there are only two bits left,

And this is not enough to represent the current capabilities of
modern delivery system's frontends.

As a few examples of missing things that we want to be able to
report, we have:

- Some DVB-C2 demods supports automatic symbol rate detection between
a certain range (Ralph);

- Some devices that only work on "auto" mode, sometimes being even
unable to return what it was detected, even with the full specs (Ralph).

- Complex delivery systems like ISDB-T have some combinations that
aren't very common, and some chipset providers decided to not implement
For example, mb86a20s frontend doesn't support guard interval equal to

So, the agreeded strategy is to write a new ioctl that, once the delivery
system is set, it will return what are the valid values/ranges that
a given frontend property can support.

In order to optimize the drivers, the core could pre-fill it with all
that it is supported by a given delivery system, letting the driver to
override it, disabling the features that aren't supported.

Michael proposed to send RFCs for that.

[1] Also, while double checking today at the code, it also doesn't
support mode 1 (2K).

That's what it was agreed during the meeting.

After our discussions about a new ioctl that would be able to properly
report the frontend capabilities for new standards, during the Media Summit,
in order to be able to report the currently needs, I did some brainstorming
about that.

It come to me that the fe_caps replacement ioctl should need to
return not only the valid values/ranges but also a flag that will
indicate if:

- The frontend supports auto-detecting the parameter (CAN_AUTO);
- The frontend allows setting such parameter (CAN_SET) [2];
- The frontend can report the detected parameter (CAN_GET);
- If the valid values comes on ranges (IS_RANGE), to be used by
parameters like frequency and symbol rate.

Btw, we have a problem with IS_RANGE for symbol rate: There are actually
two ranges there:
- The supported symbol rate range;
- The auto-detected symbol rate range.

Perhaps Ralph could shed us a light on it, but my understanding is
that some devices might have a broader supported range than the
one that the frontend can auto-detect.

If so, the solution could be to add an extra property for the
"autodetection symbol rate" range.

[2] ISDB-S new Toshiba demod, for example, doesn't allow setting the
modulation. This should always be auto-detected via TMCC table.
Btw, this seems to be a requirement at the spec (but nothing
prevents some vendor to not implement it).

We've discussed in priv that we might report everything as ranges,
but, on a second taught, I think that we should only use ranges for
numeric values, and not for enums.