Force feedback API

[Oliver H. <au...@od...>]

Hi!

Lessening bug 3 isn't any longer a reason to discuss about the API (see
my previous mail in the mailing list). But i like it anyway - do you even?

Vojtech Pavlik wrote:
> 
> On Sat, Sep 29, 2001 at 02:03:11PM +0200, Johann Deneux wrote:
> 
> > I am not especially willing to make the distinction between effect
> > packets and parameter packets visible to the user. Other protocoles
> > may have a different understanding of what goes into an effect packet,
> > and what goes into a parameter packet. What I could do is store the
> > effects uploaded with ioctl in the driver. When other ioctls are
> > performed to update an effect, I could analyse the difference and send
> > only the necessary packets. Or I could change the API. Each call to
> > ioctl would set one property of an effect:
> >
> > struct effect_property prop;
> > prop.type = FF_PROP_ATTACK_LEVEL;
> > prop.value = ...
> > ioctl(fd, EVIOCSFF, &prop);
> >
> > prop.type = FF_PROP_ATTACK_DURATION;
> > prop.value = ...
> > ioctl(fd, EVIOCSFF, &prop);
> > ...
> >
> > Instead of the one big ff_effect structure used now.
> 
> I think the differential uploading is nicest.

I think the nicest would be both, differential uploading _and_ property API.

I really like the property idea very much, it's cool! The structure will get
binary incompatible when ever an extension is needed. Even, for compatible
extensions, properties could get default values when they are not sent by
the user on effect creation.

But to the example above: When will the parameter packet be sent to the
device? On effect re-start or on each ioctl call? Both would'nt be good if
we have a packet type, wich does not need an effect re-start and which has
more than one parameter. So, what about sending an unsorted set of properties
on each ioctl call? I mean something like this:

struct effect_property prop[3];
prop[0].type = FF_PROP_ATTACK_LEVEL;
prop[0].value = ...
prop[1].type = FF_PROP_ATTACK_DURATION;
prop[1].value = ...
prop[2].type = FF_PROP_END;
ioctl(fd, EVIOCSFF, prop);

In addition, to make the start/stop concept easier, you could add
a property for it (e.g type=FF_PROP_PLAY, value=FF_START or FF_STOP),
so that the effect is (re-)started or stoped on each reception of
this property. Then the user could modify and re-start an effect
by just one ioctl call.

Hmm, my next thought is to write the set of properties to the device,
instead of calling ioctls. What about that?

- - - - - - -
Oliver Hamann