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 _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
