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):
<SUMMIT>
The main issue with fe_caps is that, currently, there are only two bits left,
between:
FE_HAS_EXTENDED_CAPS = 0x800000,
and
FE_CAN_MULTISTREAM = 0x4000000,
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
(Mauro).
For example, mb86a20s frontend doesn't support guard interval equal to
1/32[1].
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.
</SUMMIT>
[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.
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
