Re: Custom-shaped periodic effects in force feedback

[Johann D. <jo...@Do...>]

On Mon, 21 Jan 2002, Rodrigo Damazio wrote:

> >
> > Another solution, which looks much better to me, would be to separate the
> > downloading of parameters and the creation of the effect with two
> > different ioctls. We would move the union out of ff_effect to
> > ff_constant_param, ff_interactive_param...
> > First the parameters would be downloaded, then the effect itself.
> > In ff_struct, we would add a "pointer" to the parameter block to use.
> >
> > Opinions ?
> >
>        How about only having two different ioctls in the case of custom 
> effects(and leaving others unaffected, thus not moving the unions)?? 
> Then one ioctl would be to download the custom effect data, then the
> normal one which creates the effect just as it's done now, with a 
> FF_CUSTOM type...something like this:
> 
> ff_effect custom;
> ff_customdata *custom_data;
> size_t custom_data_size;
> 
> .... (malloc and assign data to these structs)
> 
> /* Upload custom data */
> ioctl(fd, EVIOCSCUSTOM, custom_data,  custom_data_size);
> 
> custom.shapeid = customdata->shapeid;
> 
> /* Upload effect */
> ioctl(fd, EVIOCSFF, &custom, sizeof(ff_effect));
> 
>    Then we'd have to write a little shapeid management(easy)...and 
> probably we'd delete a shape from kernel memory after it's used in an 
> effect(just so we don't need another ioctl for that), assigning -1 back 
> to shapeid in ff_effect(and to avoid bad programming, just make it 
> ignore any FF_CUSTOM where a shapeid is -1)...or even keep it and create 
> a EVIOCRMCUSTOM to remove it when desired...
> 
> Let me know what you think...

That's quite close to what I had in mind, except you apply it only for
custom effects. Deciding to keep or not the union looks like a rather
unimportant decision to me. I suggested to remove the union and use
parameter blocks to keep some kind of coherency in the API.

More important is the question about whether we should have parameter
blocks in the API at all.

The parameter block ioctl approach rises the following issues:
- One parameter block may be used by several effects. One may see that as
a feature, as it might allow for some memory to be saved. I am not
convinced it would be very useful, though.
- What should be put into parameters, and what should be put into the core
of the effect ? For example, the direction of a constant effect is encoded
in the core of the effect in the I-Force protocol, while the amplitude is
stored in a parameter block. It seems PID does the same. What if another
protocol chooses to put the direction into parameter blocks ?

This can lead to tricky situations. Imagine we put some attribute X into
the ff_effect, while a device really stores it in the parameter block. Now
the application decides to update the attribute X of an effect. The driver
has to change X in the parameter block (because that's what the device
wants). Imagine this parameter block is shared by another effect... If we
change it here, the attribute X of the second effect is also modified,
what is not the desired behaviour.

-- 
Johann Deneux