Steven Toth wrote:
> The design goals for me are:
>> 1) We stop trying to predict what the API will need in 5 years, and
> focus on building a very simplistic ioctl API for getting and setting
> generic frontend properties, it should be basic enough to deal with any
> new modulation type (or advanced tuner) that we know of today.
>> 2) We change the tuning mechanism from being (mostly) atomic
> (SET_FRONTEND) to a looser command/sequence definition. (Thereby
> stepping away from fixed structs that define the ABI). With two new
> ioctls (get_property/set_property) and a simple property struct which
> specifies how generic types are passed to/from the kernel.
>> 3) A userland library _may_ offer a number of helper functions to
> simplify in terms of applications development, turning this:
>
[..]
> command.id = END_TRANSACTION
> ioctl(SET_PROPERTY, &command);
>> Into a more human readable form like this:
>> int tune_8vsb(frequency);
>
Even before you thought even, we (myself and adq) have had an
implementation to do this, in kernel it was called "mti" and the
userspace interface called "libdvbapi". The sample implementation
was with the stv0299 and the ttpci card. This was more than 18
months back. The reason for that cause was another specific
demodulator.
You can read through the archives, on the same, tuning algorithms
and so on. In that scenario, we additionally had the tuning algorithm
in userspace too, simplifying many other things.
HTH
Manu