linuxconsole-dev

Re: interactive effects

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

Bj|rn Augustsson wrote:

> Quoting Johann Deneux <jo...@Do...>:
>
>> 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 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.)

       libff...btw, does the API have a way to get the capabilities of a=20
PID device?? Like what effects it can produce??

>> About interactive effects: See these effects as functions from somethi=
ng
>> to a force.
>> Position -> Force : That's a spring
>> Velocity -> Force : That's friction (or damping, why does pid define=20
>> both
>> as different effects ???)
>>
>
> No idea. Note how the spec avoids talking about that about halfway thru
> section 5.3, on page 12.
>
       It's just like he said...take a look at Immersion Studio...

>>> 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 IFe=
el
>> 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.
>>
>
> Right.  This is not even defined in the PID spec, which is kind of
> weird.

       That's why I thought it might be I-force specific...well, if it=20
works, just leave it there...

>>>> 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=20
>> 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 ?
>>
>
> 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=20
> between effects in this model.

       You're right - I hadn't thought about this...so we have two=20
choices - wec

>> 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=20
> like? How
> do they do this?
>
       Yes, I have - it seems they use 1-to-many...look at this:

http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/dx8_c/=
directx_cpp/Input/CPP_Tuts/Tut4/Step4CreatingEffect.asp

       It's a tutorial on how to create effects... and has links to the=20
structs definitions...

>> 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 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...)
>
       We can add members before the variable-length array...

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:38:24PM -0200, Rodrigo Damazio wrote:
> 
> Bj|rn Augustsson wrote:
> 
> > Quoting Johann Deneux <jo...@Do...>:
> >
> >> 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.)
> 
>        libff...btw, does the API have a way to get the capabilities of a 
> PID device?? Like what effects it can produce??

EVIOCGBIT(EV_FF) ...

-- 
Vojtech Pavlik
SuSE Labs

Re: interactive effects

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

On Sat, 26 Jan 2002, Rodrigo Damazio wrote:

> 
> Bj|rn Augustsson wrote:
> 
> > Quoting Johann Deneux <jo...@Do...>:
> >
> >> 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.
> >
>        It's just like he said...take a look at Immersion Studio...

The point was: what's the difference between friction and damping ? PID
define both effect types, but on page 12 they use both terms to refer to
the same function (force = f(Velocity)).

> 
> >>> 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.
> 
>        That's why I thought it might be I-force specific...well, if it 
> works, just leave it there...

It does not "work" right now, as it's not implemented (none of my devices
support it). But people working on the IFeel mouse will probably use it.

> >> 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?
> >
>        Yes, I have - it seems they use 1-to-many...look at this:
> 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dx8_c/directx_cpp/Input/CPP_Tuts/Tut4/Step4CreatingEffect.asp

I also had a look, and found no reference to sharing parameter
blocks. What they have is basically the following:
- a struct DIEFFECT describing the basic attributes (direction,
timing...). This struct has pointers to the two other structures
- a struct DIPERIODIC, to set the period, phase...
- a struct DIENVELOPE, for the envelope.

None of these structures has ids. This makes me think parameter blocks
cannot be shared, or at least the user has no control over it.

Updating effects is done the same way we do it (by sending the
changed effect and specifying the id of the effect to change). I see no
way change a parameter block alone.

To me it seems that parameter blocks do not have an existence of their
own.


-- 
Johann Deneux

Re: interactive effects

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

Johann Deneux wrote:

>On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
>
>>Bj|rn Augustsson wrote:
>>
>>>Quoting Johann Deneux <jo...@Do...>:
>>>
>>>>About interactive effects: See these effects as functions from someth=
ing
>>>>to a force.
>>>>Position -> Force : That's a spring
>>>>Velocity -> Force : That's friction (or damping, why does pid define=20
>>>>both
>>>>as different effects ???)
>>>>
>>>No idea. Note how the spec avoids talking about that about halfway thr=
u
>>>section 5.3, on page 12.
>>>
>>       It's just like he said...take a look at Immersion Studio...
>>
>
>The point was: what's the difference between friction and damping ? PID
>define both effect types, but on page 12 they use both terms to refer to
>the same function (force =3D f(Velocity)).
>
        Actually, I think that's not really up to us to discuss...if it=20
has two different IDs which can be sent to the device, then we should=20
implement it, and it's up to the device to make it different(or not)...

>>>>>what would FF_RUMBLE be?? Is it I-force specific?? If it's okay, I'l=
l
>>>>>
>>>>No, this effect is the "force feedback for the poor". It's used in IF=
eel
>>>>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.
>>>>
>>>Right.  This is not even defined in the PID spec, which is kind of
>>>weird.
>>>
>>       That's why I thought it might be I-force specific...well, if it=20
>>works, just leave it there...
>>
>
>It does not "work" right now, as it's not implemented (none of my device=
s
>support it). But people working on the IFeel mouse will probably use it.
>
>>>>The other solution would be to hide these parameter blocks and let th=
e
>>>>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=20
>>>like? How
>>>do they do this?
>>>
>>       Yes, I have - it seems they use 1-to-many...look at this:
>>
>>http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/dx8_=
c/directx_cpp/Input/CPP_Tuts/Tut4/Step4CreatingEffect.asp
>>
>
>I also had a look, and found no reference to sharing parameter
>blocks. What they have is basically the following:
>- a struct DIEFFECT describing the basic attributes (direction,
>timing...). This struct has pointers to the two other structures
>- a struct DIPERIODIC, to set the period, phase...
>- a struct DIENVELOPE, for the envelope.
>
>None of these structures has ids. This makes me think parameter blocks
>cannot be shared, or at least the user has no control over it.
>
        There's struct DIPERIODIC, DIENVELOPE, then there's=20
LPDIPERIODIC, LPDIENVELOPE, etc. which are pointers to such=20
structs...that's when it happens...and in DIEFFECT struct, you can see th=
is:

    LPDIENVELOPE lpEnvelope;=20

        (I hate how obscure they make it, but it's a pointer)

>Updating effects is done the same way we do it (by sending the
>changed effect and specifying the id of the effect to change). I see no
>way change a parameter block alone.
>
        No, there isn't one at API level, but inside a program you can=20
use 1-to-n....but you're right, for the driver it seems like it's 1-to-1.=
..

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