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

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

 



Markus Rechberger wrote:
> On 11/5/07, Steven Toth <stoth@xxxxxxxxxxx> wrote:
>> Johannes Stezenbach wrote:
>>> 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);
>>
>> You can't reliably pass in variably length arrays into the kernel, or
>> none of the other kernel wide drivers do, they need to be fixed length
>> for sanity reasons. That being said, I have a newly defined type which
>> represents an array enabling 16 messages to be passed in a single
>> transaction.
>>
> 
> Hi Steven,
> 
> just have a look at the i2c-dev driver it passes a variable length to
> the kernel.
> 

Hey Markus,

Good. I looked at about 40 different drivers, then ran some kernel wide 
greps before giving up. I can see it now, this is a much nicer approach.

Thanks,

- Steve


_______________________________________________
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