Re: DVB-S2 API vs. HVR4000: When?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 02, 2007, 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.

good one

> 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.

no so good

> 3) A userland library _may_ offer a number of helper functions to simplify 
> in terms of applications development, turning this:

many people seem to hate ALSA, there's a lesson to be learned here

> command.id = BEGIN_TRANSACTION
> ioctl(SET_PROPERTY, &command);
>
> command.id = SET_MODULATION
> command.arg = 8VSB
> ioctl(SET_PROPERTY, &command);
>
> command.id = SET_FREQUENCY
> command.arg = 591250000
> ioctl(SET_PROPERTY, &command);
>
> command.id = VALIDATE_TRANSACTION
> ioctl(SET_PROPERTY, &command);
>
> command.id = END_TRANSACTION
> ioctl(SET_PROPERTY, &command);
>
> Into a more human readable form like this:
>
> int tune_8vsb(frequency);
>
> It's a basic approach, we trade off multiple ioctls (at a very low rate) 
> entering the kernel, for a very flexible tuning approach to frontend 
> control.

Once you have those tag/value pairs, you could batch them
together in an array and pass them down in one ioctl. This
avoids the ugly transaction stuff and keeps it atomic.
And I think it wouldn't look too ugly in user code, e.g.:

	struct dvb_tuning_param p[3] = {
		{ .id = MODULATION, .val = MOD_8VSB },
		{ .id = FREQUENCY,  .val = 591250000 },
		{ .id = 0 }
	};
	ioctl(fd, DVB_TUNE, p);


But there's more work to do:
- need for .val being variable lenght or a union of different types?
- extend existing enums or define new ones for MODULATION etc?
- how to do FE_GET_FRONTEND
- etc.

I'm sure we could have endless debates over the details ;-)

I hope many others will comment which approach they like better,
or which one they think will be ready for prime time sooner.

Personally I don't care either way. I spent a lot of time discussing
the "multiproto" API and I believe it could be ready soon with
a few minor tweaks. OTOH this tag/value approach seems to be
more flexible, but who knows how much work it'll take to complete.


Johannes

_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux