Re: Force feedback API

[Vojtech P. <vo...@su...>]

On Sun, Sep 30, 2001 at 06:37:47AM +0200, Oliver Hamann wrote:
> 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);

Looks OK to me, too.

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

I don't like this much. Ioctls shouldn't be used for starting/stopping
things, ioctls should be for setting things up. Just a matter of taste.

-- 
Vojtech Pavlik
SuSE Labs