linuxconsole-dev

Re: Interactive Effects

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

Johann Deneux wrote:

> On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
>
>>    I just realized - the interactive effect struct doesn't allow us=20
>> to assign independent parameters to the X and Y axes...it should=20
>> though, since the PID spec says there are two condition blocks for it=20
>> - one for each axis...is it okay to modify it to include separate=20
>> parameters??
>>
>
> Definitely yes. I-Force also allows that.
>
   Okay, will do so...also, is itme who has an outdated version of=20
input.h, or does it really not have ET Ramp, Damper, and Inertia?? And=20
what would FF_RUMBLE be?? Is it I-force specific?? If it's okay, I'll=20
add FF_RAMP, FF_DAMPER, and FF_INERTIA since they're defined in the=20
spec(5.1.1)...

>
> Anyway, we will have to change the API to take custom effects into
> account.
>
   Yes, I know...have you decided how we'll do that?? I guess that=20
since(in PID specs at least) custom effect data is sent on one(or more)=20
report by itself, saved in a memory position(just like an effect), etc.,=20
we could just make an IOCTL to upload the custom data, then we can=20
normally upload an effect which points to that custom data...that would=20
require only minor changes to the existing code...

Rodrigo

P.S.: I've started libff too...send me all ideas you have for nice=20
things it could do...I'm using re-usable parameter blocks(something like=20
FF_create_constant(float direction, float magnitude, FF_envelope=20
*envelope, FF_trigger *trigger, FF_time *time, FF_flags flags)  )

--=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: Interactive Effects

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

Johann Deneux wrote:

> On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
>
>> Johann Deneux wrote:
>>
>>> On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
>>>
>>>>   I just realized - the interactive effect struct doesn't allow us=20
>>>> to assign independent parameters to the X and Y axes...it should=20
>>>> though, since the PID spec says there are two condition blocks for=20
>>>> it - one for each axis...is it okay to modify it to include=20
>>>> separate parameters??
>>>>
>>> Definitely yes. I-Force also allows that.
>>>
>>   Okay, will do so...also, is itme who has an outdated version of=20
>> input.h, or does it really not have ET Ramp, Damper, and Inertia?? And
>
>
> Ramps did not seem to useful to me. Indeed, they can be realised using
> other effects, for example, using a shaped constant effect.
> However, I think they should be added in the API. It's up to the=20
> driver to
> decide how to implement this effect.
>
       I'm in favor of implmenting it, to comply with the specs...

>
> About interactive effects: See these effects as functions from somethin=
g
> to a force.
> Position -> Force : That's a spring
> Velocity -> Force : That's friction (or damping, why does pid define bo=
th
> as different effects ???)
> Acceleration -> Force : That should be inertia. It's not implemented in
> I-Force. Actually, Immersion seems to consider this to be the same as
> friction.
>
       I knew this...if you look in Immersion Studio, you'll see you can=20
actually see a graph force vs. {position | velocity | acceleration }...

>
>
> I agree that we should add FF_INERTIA and FF_RAMP, but FF_DAMPER looks
> pretty useless to me. Unless I missed the point ?
>
       Well, I've tried creating some Damper effects - it does make a=20
difference...besides, it's in the specs...

>> what would FF_RUMBLE be?? Is it I-force specific?? If it's okay, I'll
>
>
> No, this effect is the "force feedback for the poor". It's used in IFee=
l
> mice for example. It's just a simple vibration. You can find it in
> some console joypads, too. For example, the AVB Pegasus joystick has
> (should have, mine has none) a connector to add a joypad supporting=20
> rumble
> effects.
>
       Oh, okay...doesn't it have any parameters?? Not even magnitude??

>> add FF_RAMP, FF_DAMPER, and FF_INERTIA since they're defined in the
>> spec(5.1.1)...
>>
>>> Anyway, we will have to change the API to take custom effects into
>>> account.
>>>
>>   Yes, I know...have you decided how we'll do that?? I guess that
>
>
> No. The "1 parameter block - n effects" is appealing, but we must make =
it
> hardware independant. Right now, there is no obstacle to doing it, as
> I-Force and PID seems to share the same view of what to put into=20
> parameter
> blocks. Is it a safe bet to assume future specs won't change ?
>
       Well, if this model is working well, there'd be no reason for=20
them to change it... _if_ they ever do, we'll think about it...even=20
because if they change it, it'll have to be backwards-compatible...

> The other solution would be to hide these parameter blocks and let the
> driver optimize its memory usage. This looks pretty ambitious to me,
> though.
>
       Would even be nice, but I think we should leave this decision to=20
the programmer...

> The last solution is to go for "1 parameter block - 1
> effect" solution. It's safe, easy to implement, but it kills the
> possibility to share parameters between several effects.
>
       I prefer the first one...it's how I'm creating prototypes for=20
libff at least...

>> since(in PID specs at least) custom effect data is sent on one(or=20
>> more) report by itself, saved in a memory position(just like an=20
>> effect), etc., we could just make an IOCTL to upload the custom data,=20
>> then we can normally upload an effect which points to that custom=20
>> data...that would require only minor changes to the existing code...
>>
>> Rodrigo
>>
>> P.S.: I've started libff too...send me all ideas you have for nice=20
>> things it could do...I'm using re-usable parameter blocks(something=20
>> like FF_create_constant(float direction, float magnitude, FF_envelope=20
>> *envelope, FF_trigger *trigger, FF_time *time, FF_flags flags)  )
>>
>
> So you are going towards a user-visible 1-parameter-n-effects approach =
?
>
       Yes(actually it's n-parameters-m-effects)...even if that happens=20
only at a library level, and the kernel works differently...obviously,=20
there will be some convenient functions like to delete an effect and all=20
its related parameter blocks, so if a programmer wants 1-to-1, he can=20
just do something like:

eff =3D FF_create_constant(0, 1, FF_create_envelope(bla bla),=20
FF_create_trigger(bla bla), FF_create_time(bla bla), 0);

and then later a:

FF_delete_effect_related(eff);

   Would free all parameters blocks allocated...obviously it needs some=20
checks like if the user did something like

eff2.envelope =3D eff.envelope;

   Then we'd need to set eff2.envelope to NULL, just so it can't get=20
sent and cause a memory bug...

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: Interactive Effects

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

On Sat, Jan 26, 2002 at 11:37:56PM -0200, Rodrigo Damazio wrote:
> >> what would FF_RUMBLE be?? Is it I-force specific?? If it's okay, I'll
> >
> >
> > No, this effect is the "force feedback for the poor". It's used in IFeel
> > mice for example. It's just a simple vibration. You can find it in
> > some console joypads, too. For example, the AVB Pegasus joystick has
> > (should have, mine has none) a connector to add a joypad supporting 
> > rumble
> > effects.
> >
>        Oh, okay...doesn't it have any parameters?? Not even magnitude??

No, it doesn't have even magnitude. 

-- 
Vojtech Pavlik
SuSE Labs

Re: Interactive Effects

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

On Sat, 26 Jan 2002, Rodrigo Damazio wrote:

> Johann Deneux wrote:
> 
> >
> > About interactive effects: See these effects as functions from something
> > to a force.
> > Position -> Force : That's a spring
> > Velocity -> Force : That's friction (or damping, why does pid define both
> > as different effects ???)
> > Acceleration -> Force : That should be inertia. It's not implemented in
> > I-Force. Actually, Immersion seems to consider this to be the same as
> > friction.
> >
>        I knew this...if you look in Immersion Studio, you'll see you can 
> actually see a graph force vs. {position | velocity | acceleration }...
> 
> >
> >
> > I agree that we should add FF_INERTIA and FF_RAMP, but FF_DAMPER looks
> > pretty useless to me. Unless I missed the point ?
> >
>        Well, I've tried creating some Damper effects - it does make a 
> difference...besides, it's in the specs...

The direct input docs describes these condition types in:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dx8_c/directx_cpp/Input/Using/ForceFeedback/EffectConditions.asp
The interesting part is:
"
    *  Friction. The force is applied when the axis is moved and depends
on the defined friction coefficient.
    * Damper. The force increases in proportion to the velocity with which
the user moves the axis.
"
Apparently, the friction does not depend on the speed. And now that I
write it, it hits me: friction is not force = f(Velocity). I should have
known it.
The formula is defined as following:
force.direction = -velocity.direction
force.magnitude = k
Imagine you are pushing a heavy box on the ground. k depends on the type
of the ground, the material of the box and the mass of the box. As those
do not change, k is indeed constant.

I will check again what USBsnoopy says. I seem to recall that for I-Force
devices, friction = damping.

-- 
Johann Deneux

Re: Interactive Effects

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

On Sat, 26 Jan 2002, Rodrigo Damazio wrote:

> Johann Deneux wrote:
> 
> > On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
> >
> >>    I just realized - the interactive effect struct doesn't allow us 
> >> to assign independent parameters to the X and Y axes...it should 
> >> though, since the PID spec says there are two condition blocks for it 
> >> - one for each axis...is it okay to modify it to include separate 
> >> parameters??
> >>
> >
> > Definitely yes. I-Force also allows that.
> >
>    Okay, will do so...also, is itme who has an outdated version of 
> input.h, or does it really not have ET Ramp, Damper, and Inertia?? And 

Ramps did not seem to useful to me. Indeed, they can be realised using
other effects, for example, using a shaped constant effect.
However, I think they should be added in the API. It's up to the driver to
decide how to implement this effect.

About interactive effects: See these effects as functions from something
to a force.
Position -> Force : That's a spring
Velocity -> Force : That's friction (or damping, why does pid define both
as different effects ???)
Acceleration -> Force : That should be inertia. It's not implemented in
I-Force. Actually, Immersion seems to consider this to be the same as
friction.

I agree that we should add FF_INERTIA and FF_RAMP, but FF_DAMPER looks
pretty useless to me. Unless I missed the point ?

> what would FF_RUMBLE be?? Is it I-force specific?? If it's okay, I'll 

No, this effect is the "force feedback for the poor". It's used in IFeel
mice for example. It's just a simple vibration. You can find it in
some console joypads, too. For example, the AVB Pegasus joystick has
(should have, mine has none) a connector to add a joypad supporting rumble
effects.

> add FF_RAMP, FF_DAMPER, and FF_INERTIA since they're defined in the
> spec(5.1.1)...
> 
> >
> 
> > Anyway, we will have to change the API to take custom effects into
> > account.
> >
>    Yes, I know...have you decided how we'll do that?? I guess that 

No. The "1 parameter block - n effects" is appealing, but we must make it
hardware independant. Right now, there is no obstacle to doing it, as
I-Force and PID seems to share the same view of what to put into parameter
blocks. Is it a safe bet to assume future specs won't change ?

The other solution would be to hide these parameter blocks and let the
driver optimize its memory usage. This looks pretty ambitious to me,
though.

The last solution is to go for "1 parameter block - 1
effect" solution. It's safe, easy to implement, but it kills the
possibility to share parameters between several effects.

> since(in PID specs at least) custom effect data is sent on one(or more) 
> report by itself, saved in a memory position(just like an effect), etc., 
> we could just make an IOCTL to upload the custom data, then we can 
> normally upload an effect which points to that custom data...that would 
> require only minor changes to the existing code...
> 
> Rodrigo
> 
> P.S.: I've started libff too...send me all ideas you have for nice 
> things it could do...I'm using re-usable parameter blocks(something like 
> FF_create_constant(float direction, float magnitude, FF_envelope 
> *envelope, FF_trigger *trigger, FF_time *time, FF_flags flags)  )
> 

So you are going towards a user-visible 1-parameter-n-effects approach ?

-- 
Johann Deneux

Re: Interactive Effects

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

Quoting Johann Deneux <jo...@Do...>:
> On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
> > Johann Deneux wrote:
> > > On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
> >    Okay, will do so...also, is itme who has an outdated version of 
> > input.h, or does it really not have ET Ramp, Damper, and Inertia?? And 
> 
> Ramps did not seem to useful to me. Indeed, they can be realised using
> other effects, for example, using a shaped constant effect.

You can't emulate a shaped ramp effect that way though.

> However, I think they should be added in the API. It's up to the driver to
> decide how to implement this effect.

I agree that they should be added to the API. I don't think a driver
should decide to emulate one effect with another, except in extreme
cases. This sort of thing is much better done in userspace. (A library
for example.) 

> About interactive effects: See these effects as functions from something
> to a force.
> Position -> Force : That's a spring
> Velocity -> Force : That's friction (or damping, why does pid define both
> as different effects ???)

No idea. Note how the spec avoids talking about that about halfway thru
section 5.3, on page 12.

> Acceleration -> Force : That should be inertia. It's not implemented in
> I-Force. Actually, Immersion seems to consider this to be the same as
> friction.
> 
> I agree that we should add FF_INERTIA and FF_RAMP, but FF_DAMPER looks
> pretty useless to me. Unless I missed the point ?

Beats me.
 
> > what would FF_RUMBLE be?? Is it I-force specific?? If it's okay, I'll 
> 
> No, this effect is the "force feedback for the poor". It's used in IFeel
> mice for example. It's just a simple vibration. You can find it in
> some console joypads, too. For example, the AVB Pegasus joystick has
> (should have, mine has none) a connector to add a joypad supporting rumble
> effects.

Right.  This is not even defined in the PID spec, which is kind of
weird. 

> > > Anyway, we will have to change the API to take custom effects into
> > > account.
> > >
> >    Yes, I know...have you decided how we'll do that?? I guess that 
> 
> No. The "1 parameter block - n effects" is appealing, but we must make it
> hardware independant. Right now, there is no obstacle to doing it, as
> I-Force and PID seems to share the same view of what to put into parameter
> blocks. Is it a safe bet to assume future specs won't change ?

Actually, having thought about this some more, this is NOT how PID
works, unless you're in driver-managed mode (which the MS FF2 isn't -
it uses the "device managed"  memory model. (Maybe it can switch, I
haven't checked that carefully, but I don't think so.)

Here you get a number (in the FF2 case, 40) "slots" to put effects in,
and they each have room for whatever extra parameter blocks are needed.
(Ie, they're often oversized.) You can _not_ share parameter blocks 
between effects in this model. 

> The other solution would be to hide these parameter blocks and let the
> driver optimize its memory usage. This looks pretty ambitious to me,
> though.

Absolutely. Again, it could be done in a library.

Hmm, Rodrigo, did you have a look at what the MS DirectInput looks like? How
do they do this?

> The last solution is to go for "1 parameter block - 1
> effect" solution. It's safe, easy to implement, but it kills the
> possibility to share parameters between several effects.

Right. 
 
Now for custom effects, I think we should have a separate call to upload
those. Having the variable length array thing you suggested is nice, but
then we can't add more fields to the strut after that if we choose to
later. (Or can we? I seem to remember that the variable length array has
to be the last member of a struct, but I'm not sure...)

/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: Interactive Effects

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

On Sat, Jan 26, 2002 at 07:12:10PM +0100, Bj|rn Augustsson wrote:

> Actually, having thought about this some more, this is NOT how PID
> works, unless you're in driver-managed mode (which the MS FF2 isn't -
> it uses the "device managed"  memory model. (Maybe it can switch, I
> haven't checked that carefully, but I don't think so.)
> 

No, it cannot be switched. "Device managed" is MSFF, "driver managed" is
i-force basically. That's why both the models were put into the spec.

-- 
Vojtech Pavlik
SuSE Labs

Re: Interactive Effects

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

On Sat, 26 Jan 2002, Bj|rn Augustsson wrote:

> Quoting Johann Deneux <jo...@Do...>:
> > On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
> > > Johann Deneux wrote:
> > > > On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
> > >    Okay, will do so...also, is itme who has an outdated version of 
> > > input.h, or does it really not have ET Ramp, Damper, and Inertia?? And 
> > 
> > Ramps did not seem to useful to me. Indeed, they can be realised using
> > other effects, for example, using a shaped constant effect.
> 
> You can't emulate a shaped ramp effect that way though.

Right. You can however use sawtooth up or down, though. Set the effect
length to play for one period only, and set the magnitude and offset to
the "right" values. It is then still possible to add a shape.
The point is, it seems there are different ways to achieve one given
effect. Should we have a "non prime" set of effects ?

>[...]
> > The other solution would be to hide these parameter blocks and let the
> > driver optimize its memory usage. This looks pretty ambitious to me,
> > though.
> 
> Absolutely. Again, it could be done in a library.
> 
> Hmm, Rodrigo, did you have a look at what the MS DirectInput looks like? How
> do they do this?
> 
> > The last solution is to go for "1 parameter block - 1
> > effect" solution. It's safe, easy to implement, but it kills the
> > possibility to share parameters between several effects.
> 
> Right. 
>  
> Now for custom effects, I think we should have a separate call to upload
> those. Having the variable length array thing you suggested is nice, but
> then we can't add more fields to the strut after that if we choose to
> later. (Or can we? I seem to remember that the variable length array has
> to be the last member of a struct, but I'm not sure...)

You are right. Anyway, I think we should stick to ANSI C. Not for the
driver itself of course, but for the user-visible headers.
Yet another solution would be that the user provides a pointer to a buffer
describing the custom effect.
Isn't this solution nicer ? I personnaly dislike the idea of having
several ioctls perform one operation (the uploading of a full-effect)

> 
> /August.
> 
By the way, how should we call you ? August or Bj-pipe-rn :) ?

-- 
Johann Deneux

Re: Interactive Effects

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

Johann Deneux wrote:

>On Sat, 26 Jan 2002, Bj|rn Augustsson wrote:
>
>>Quoting Johann Deneux <jo...@Do...>:
>>
>>>On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
>>>
>>>>Johann Deneux wrote:
>>>>
>>>>>On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
>>>>>
>>>>   Okay, will do so...also, is itme who has an outdated version of=20
>>>>input.h, or does it really not have ET Ramp, Damper, and Inertia?? An=
d=20
>>>>
>>>Ramps did not seem to useful to me. Indeed, they can be realised using
>>>other effects, for example, using a shaped constant effect.
>>>
>>You can't emulate a shaped ramp effect that way though.
>>
>
>Right. You can however use sawtooth up or down, though. Set the effect
>length to play for one period only, and set the magnitude and offset to
>the "right" values. It is then still possible to add a shape.
>The point is, it seems there are different ways to achieve one given
>effect. Should we have a "non prime" set of effects ?
>
        There obviously are many ways to achieve a given effect, but I=20
think that decision should not be made by the kernel...the kernel should=20
just give all standard effects...

>>>The last solution is to go for "1 parameter block - 1
>>>effect" solution. It's safe, easy to implement, but it kills the
>>>possibility to share parameters between several effects.
>>>
>>Right.=20
>>=20
>>Now for custom effects, I think we should have a separate call to uploa=
d
>>those. Having the variable length array thing you suggested is nice, bu=
t
>>then we can't add more fields to the strut after that if we choose to
>>later. (Or can we? I seem to remember that the variable length array ha=
s
>>to be the last member of a struct, but I'm not sure...)
>>
>
>You are right. Anyway, I think we should stick to ANSI C. Not for the
>driver itself of course, but for the user-visible headers.
>Yet another solution would be that the user provides a pointer to a buff=
er
>describing the custom effect.
>Isn't this solution nicer ? I personnaly dislike the idea of having
>several ioctls perform one operation (the uploading of a full-effect)
>
        The idea is good...would also need a buffer size in there...is=20
that safe enough? To just invade userspace and take the buffer?? What=20
happens if the user allocated a 1-byte buffer and tells us it has 1000=20
bytes?? Would it be possible that we'd be invading another process's=20
memory?? (excuse me, I hate memory management, hehe)

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: Interactive Effects

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

On Sat, Jan 26, 2002 at 11:37:27PM -0200, Rodrigo Damazio wrote:

> >You are right. Anyway, I think we should stick to ANSI C. Not for the
> >driver itself of course, but for the user-visible headers.
> >Yet another solution would be that the user provides a pointer to a buffer
> >describing the custom effect.
> >Isn't this solution nicer ? I personnaly dislike the idea of having
> >several ioctls perform one operation (the uploading of a full-effect)
> >
>         The idea is good...would also need a buffer size in there...is 
> that safe enough? To just invade userspace and take the buffer?? What 
> happens if the user allocated a 1-byte buffer and tells us it has 1000 
> bytes?? Would it be possible that we'd be invading another process's 
> memory?? (excuse me, I hate memory management, hehe)

No, that can't happen. But the process will either crash or the data
transfer will fail with -EFAULT.

-- 
Vojtech Pavlik
SuSE Labs