<div dir="ltr"><br><br><div class="gmail_quote">On Tue, Nov 25, 2008 at 8:34 PM, Morgan TÝrvolt <span dir="ltr">&lt;<a href="mailto:morgan.torvolt@gmail.com">morgan.torvolt@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Regarding the actual problem, I have never been happy with the<br>
&quot;FE_QPSK&quot; and &quot;FE_OFDM&quot; enum fe_types. This imho does not make much<br>
sense. I would like to know what a card is supposed to receive. One<br>
modulation type is not locked to a transmission medium, nor frequency<br>
range, and QPSK can easily be used in a cable network if one wished to<br>
do so. I second the proposed solution of Artem, but I would do it with<br>
a twist.<br>
<br>
If possible, I would keep the old system for backwards compatibility,<br>
and create a different command where this confusing QPSK/OFDM/QAM gets<br>
removed altogether. I would have a enum frontend type that would<br>
indicate what standard is being followed, if any. An additional<br>
indication of all the different modulation types that is supported is<br>
a must. In addition to what Artem proposed, I would like to be able to<br>
read a supported frequency range ( i.e 950-2150 for satellite tuners<br>
), and supported symbol rates. The last part there about symbol rate<br>
could be different for different modulation types. Most people would<br>
not need this, but some do. I don&#39;t think I have a good solution for<br>
how one would solve that, but one way would be if you could do as with<br>
the ca_types supported that is returned from different CAMs. One could<br>
return a list of stucts with modulation types and their respective<br>
limits and parameters. I don&#39;t know if this is really useful, but I<br>
remember that on some of the satellite modems we used, the symbol rate<br>
was limited by the center frequency of the carrier. If you got to<br>
close to the max and min, the carrier bandwidth would have to be<br>
reduced. There might be some equipment out there that has such<br>
limitations, and it could be worth adding support for that I guess.</blockquote><div>If we&#39;re talking(writing) about enhanced capabilities, I&#39;ll throw my 2 cents as well...<br>The driver has to return what settings it will accept in tune command (or maybe other commands as well).<br>
For example, there is a chipset (don&#39;t remember the name) that doesn&#39;t support AUTO settings for modulation, FEC and rolloff.<br>If that info will be available to the application (such as scan I&#39;m dealing with), it will be very useful.<br>
</div></div><br></div>