linuxconsole-dev

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

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

Re: Custom-shaped periodic effects in force feedback

[Bj|rn A. <d3a...@dt...>]

Quoting Johann Deneux <jo...@Do...>:
> On Mon, 21 Jan 2002, Rodrigo Damazio wrote:
> 
> >    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.

I agree, that's more like what the real thing (at least wrt PID) looks
like anyway.

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

I think it could, especially for envelope* blocks , which I imagine you
could recycle quite a lot. But really, this is an application thing to
decide, the kernel shouldn't involve itself in these kind of details.

(iforce refers to these as shape. Envelope is from the PID spec, so I'm
going to use that naming.)

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

That gets real ugly either way we do it. It makes sense to do it in the
most logical way though, which IHMO is the iforce/PID way; all effects
have a direction, it makes sense to have it in the main block.

(And at least in PID, the amplitude thing is a bit weird. the Set Effect
report has "Gain", and for example the Constant Force effect block has 
"Magnitude". Difference? Magnitude is signed, otherwise I think they're
just multiplied together (along with the Device Gain.))

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

Ouch! Let's not do that. *IF* a device that behaves substantially
differently from iforce and PID shows up, it's probably time to
introduce some kind of libff or whatever to deal with this stuff.

/August.
-- 
Wrong on most accounts.  const Foo *foo; and Foo const *foo; mean the same: foo
being a pointer to const Foo.  const Foo const *foo; would mean the same but is
illegal (double const).  You are confusing this with Foo * const foo; and const
Foo * const foo; respectively. -David Kastrup, comp.os.linux.development.system

Re: Custom-shaped periodic effects in force feedback

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

On Mon, 21 Jan 2002, Bj|rn Augustsson wrote:

> Quoting Johann Deneux <jo...@Do...>:
> > On Mon, 21 Jan 2002, Rodrigo Damazio wrote:
> > 
> > >    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.
> 
> I agree, that's more like what the real thing (at least wrt PID) looks
> like anyway.

Yes, I know. But the reason I did not choose this scheme earlier was that
it seemed too close to the hardware.

> 
> > 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.
> 
> I think it could, especially for envelope* blocks , which I imagine you
> could recycle quite a lot. But really, this is an application thing to
> decide, the kernel shouldn't involve itself in these kind of details.

Well, the kernel is involved anyway. Either it allows 1 parameter block to
n effects, or not. The first model seems more attracting, but it has the
issue described below.

> 
> (iforce refers to these as shape. Envelope is from the PID spec, so I'm
> going to use that naming.)
> 
> > - 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 ?
> 
> That gets real ugly either way we do it. It makes sense to do it in the
> most logical way though, which IHMO is the iforce/PID way; all effects
> have a direction, it makes sense to have it in the main block.
> 
> (And at least in PID, the amplitude thing is a bit weird. the Set Effect
> report has "Gain", and for example the Constant Force effect block has 
> "Magnitude". Difference? Magnitude is signed, otherwise I think they're
> just multiplied together (along with the Device Gain.))
> 
> > 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.
> 
> Ouch! Let's not do that. *IF* a device that behaves substantially

What do you mean ? We can't help it. For this problem to arise, it is
enough to have these two conditions:
1) We allow 1-to-n, instead or (1,2)-to-1 as it is now.
2) We don't control the placement of attributes

1) would be nice to have, but for 2), we can only hope all future devices
won't change too much.

> differently from iforce and PID shows up, it's probably time to
> introduce some kind of libff or whatever to deal with this stuff.

What do you mean ? having two different interfaces, and hiding their
differences in a libff ? I fear this may only move the problem from the
driver to libff.

-- 
Johann Deneux

Re: Custom-shaped periodic effects in force feedback

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

On Mon, Jan 21, 2002 at 11:28:33PM +0100, Johann Deneux wrote:

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

We have seven force feedback protocols so far:

1) Rumble (in many different pads)
2) I-Force 1.0 (in the CH Products FF stick, mostly similar to 2.0)
3) I-Force 2.0 (most common)
4) MS MIDI-based FF (very similar to PID)
5) PID (New MS devices, and the Logitech WingMan ForceFeedback mouse)
6) Logitech's new host-controlled FF (basically I-Force done mostly
   on the host CPU)
7) Logitech's new iFeel mice (host controlled vibration)

I think the current API still wraps well enough around them, so that's
OK. Just keep in mind that it should be generic enough, but never too
generic. Too generic things become unusable.

-- 
Vojtech Pavlik
SuSE Labs