Custom-shaped periodic effects in force feedback

[Rodrigo D. <cu...@uo...>]

Johann Deneux wrote:


> On Sun, 20 Jan 2002, Rodrigo Damazio wrote:
>
>>        Btw, how do custom effects work??
>>
>
> They are not supported by the current API. We need to add it. The probl=
em
> would be how to pass the variable length data describing the shape of t=
he
> force ?
> One way would be to append it to the ff_effect:
>
> ff_effect* custom;
> s8* shape;
> custom =3D (ff_effect*)malloc(sizeof(ff_effect) + len_shape);
> shape =3D ((s8*)custom) + sizeof(ff_effect);
>
> /* Init custom */
> ...
>
> /* Init shape */
> for (i=3D0; i<len_shape; ++i) {
>  shape(i) =3D ...;
> }
>
> /* Upload effect to device */
> ioctl(fd, EVIOCS_FF, custom, sizeof(ff_effect)+len_shape);
>
> If we can use ISO C instead of ANSI C, I think there is a feature in th=
e
> new specs allowing for variable-size arrays to be placed at the end of =
a
> structure, which eliminates the initialization of the shape pointer.
>
       I personally think that wouldn't be very good, because it'd put a=20
restriction on what compilers or compiler options could be used for it...

>
> Another solution, which looks much better to me, would be to separate t=
he
> 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=20
effects(and leaving others unaffected, thus not moving the unions)??=20
Then one ioctl would be to download the custom effect data, then the=20
normal one which creates the effect just as it's done now, with a=20
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 =3D customdata->shapeid;

/* Upload effect */
ioctl(fd, EVIOCSFF, &custom, sizeof(ff_effect));

   Then we'd have to write a little shapeid management(easy)...and=20
probably we'd delete a shape from kernel memory after it's used in an=20
effect(just so we don't need another ioctl for that), assigning -1 back=20
to shapeid in ff_effect(and to avoid bad programming, just make it=20
ignore any FF_CUSTOM where a shapeid is -1)...or even keep it and create=20
a EVIOCRMCUSTOM to remove it when desired...

Let me know what you think...
Rodrigo

--=20
*******************************
* Rodrigo Damazio             *
* *************************** *
* cu...@uo...            *
* rod...@po... *
* ICQ: #3560450               *
* http://www.vros.com/cuddly/ *
* *************************** *
* Engenharia da Computa=E7=E3o    *
* Escola Polit=E9cnica          *
* USP - S=E3o Paulo             *
*******************************