libff-devel — Discussion about the development of libff

[Libff-devel] Re: Vegastrike and Force Feedback

[Alexander R. <ale...@us...>]

Hi,

On Sunday 03 March 2002 20:02, you wrote:
> > >
> > > usbcore                50752   1 [iforce hid usbmouse usb-uhci]
> > > joydev                  6176   0
> > > iforce                  9584   0 (unused)
> >
> > I am really willing to help you, but I need more details. What is the
> > problem ? What did you try, and what failed ?

I am just trying to use the joystick with USB - but I haven't ever touched 
usb, so ....?

Can you tell me about installing usb, or name me a good webpage?

> Now that Alex and I have the joysticks (working I presume) we can certainly

Not yet - sigh.

> start to develop for it...
> how would you think is a good way to start.... I could write raw forces out
> to it if there's a simple way to do that.......

I think it isn't that simple.

I had a look at the source code of fftest - you have to carefully handcraft 
certain effects and then play it one after another.

You should also visit the Immersion Site and download ImmersionStudio to 
create/edit effects etc - and all the other docu they have.

> when you explode forces come and hit you from all sides violently (shoudl
> work fine for joystick)
> and when you shoot I could easily add a reverse force (that would move both
> your ship and your stick)
> and then finally of course when you're flying the autocorrection system
> applies forces to your ship to make sure you're going forward...I could
> easily transfer those to the joystick if you tell me how.....
>
> lastly more force happens when you start the afterburner to make you go
> fast quickly...in combat there are a LOT of forces on you.....

It's less forces and more effects.

> anyhow not a hard job at all....  is this just low leve stuff or high level
> stuff....   ?

Using iocontrol calls ....

I think I understand how to do.



Alex


-- 
                   Alexander Rawass
          Email: ale...@us...
http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

[Libff-devel] Re: Vegastrike and Force Feedback

[Alexander R. <ale...@us...>]

Hi,

On Sunday 03 March 2002 23:47, you wrote:
> >
> > I mean this seems like the most basic possible...can I just fopen
> > (/dev/jsX) and write some stuff tehre for forces...can you tell me how to
> > do this? or is the timing important and are otehr things important...... 
> > low level is ok since right now all I need is 1 function:
> >
> > void ApplyForce (x,y,z);
> > that's both direction and magnitude....
> > is that difficult to implement in low level...?
>
> No, it's only one ioctl. Have a look at the utility called ffmvforce
> (available on my homepage or at linuxconsole.sourceforge.net).
>
> The API is described in Documentation/input/ff.txt in the patched linux
> sources.
> Briefly:
> 1. You create/update effects using ioctls on /dev/input/eventX
> 2. You play/stop effects by writing into /dev/input/eventX
> 3. You query device features by... guess what ? ioctls on /dev/input/eventX
> (4. /dev/input/eventX is handled by the module called evdev.o)
>
> /dev/input/jsX isn't actually necessary. But you can use it too if you
> want.

I've read it and I think I understand how it is done.


Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Libff-devel] Re: Vegastrike and Force Feedback

[Alexander R. <ale...@us...>]

Hi,

On Sunday 03 March 2002 12:52, you wrote:
> >
> > What has been done in writing such a high-level library already?
> > Any concepts yet etc?

I'll have a look at the mailing-list archive.

> > the right 'eight way' hatswitch is recognized as axes 4&5 - why is that
> > hatswitch an axis - and not maybe a row of buttons?
>
> Hats really are axes, aren't they ? I mean, if you see them as buttons,
> that means the left and the right positions could be enabled at the same
> time, which isn't the case. But you're right to rise the question, the

Hmm - agreed.

> left hatswitch should be seen as axes as well, which isn't the case for
> the moment.

Does anyone know how sdl recognizes hatswitches as hatswitches?

Vegastrike says this about found joysticks:

>2 joysticks were found.

>The names of the joysticks are:
>    ttyS1/serio0/input0
>axes: 6 buttons: 13 hats: 0
>    ttyS1/serio0/input0
>axes: 4 buttons: 13 hats: 1

Huh? SDL found 2 joysticks - with the same input - but differently?

What's going on?

What does VS say about your stick?

> > The Button Nr.2 and Button Nr.3 (in terms of my joysticks manual) are
> > somehow 'swapped' - at least, 'Button 2' is button nr. 2 in jstest, and
> > 'Button 3' is button 1 in jstest.
>
> I have a tendancy to ignore these docs (they don't say anything about
> the protocol used ;) I will fix it.

Maybe it's wrong in the manual :-)

> >  [alex@jungle ff-utils]$ ./fftest /dev/input/event0
> > Force feedback test program.
> > HOLD FIRMLY YOUR WHEEL OR JOYSTICK TO PREVENT DAMAGES
> >
> > Device /dev/input/event0 opened
> > Axes query: Axis X Axis Y
> > Effects: Constant Periodic Spring Friction
> > Number of simultaneous effects: 20
> > Enter effect number, -1 to exit
> > 1
> > Enter effect number, -1 to exit
> > 2
> >
> > Nothing happens at all.
>
> What about effects 0 and 3 ? Do they work ? Did you try to change the
> magnitude of effects ? Did you try with USB ?

No effect works.

Magnitude: I tried ./ffset -g 50 - nothing

USB: not yet

> > How can I use the other ff-utils (no docu?)?
>
> ffcfstress stresses the joystick by simulating a spring using only
> constant force effects (as explained in the source).
> ffmvforce generates forces directed toward the mouse pointer. It's also
> a kind of stress test.
> I don't see what kind of documentation you expect ? The only meaningful

Just some README about them.

> utilities are those to set the gain and the auto-center. Others are code
> sample, and the documentation is naturally situated inside the code.

Ah - I hadn't looked that far yet, with the exception of evtest.c

> > Do I have to switch the joystick on at boot time to get it recognized by
> > the driver?
>
> No, you don't. Of course, you need to have it switched on when you load
> the driver and start inputattach. But that needn't be at boot time.

But most users (at least, me) will load drivers at boot time.

So, that's not user friendly, I think?

Is it possible to change that behaviour - to load the driver without power on 
for the joystick?

> > What has stopped working is my old-analogue joystick:
> >
> > [root@jungle /root]# modprobe ns558

> > Now, with 2.4.12, the loading of ns558 doesn't work anymore - I dunno
> > why?
>
> Me neither. Perhaps a problem with es1371 ??? But I don't think the

I dunno.

> I-Force driver has anything to do with that (especially as ns558 is
> loaded before the iforce stuff). My patch does not touch ns558, btw.

Clear.



Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

[Libff-devel] Re: Vegastrike and Force Feedback

[Johann D. <de...@if...>]

Alexander Rawass wrote:
> Hi,
> 
> I am a Co-Developer to Vegastrike vegastrike.sourceforge.net, a 3D space 
> fight sim.
> 
> I have written the joystick support for Vegastrike, and now I own a new 
> force-feedback joystick, so I'll do also the Force Feedback support for 
> Vegastrike.
> 
> I've already got contacts to Johann Deneux, but I'm now also on the 
> libff-devel and linuxconsole-dev mailing lists.
> 
> My job would be, to help write a high-level force feedback library, and then 
> make Vegastrike use it.
> 
> What has been done in writing such a high-level library already?
> Any concepts yet etc?
> 

We have been discussing the API. A first draft is ready, and we should 
start to implement it any time soon. Rodrigo, could you commit the 
header to CVS ?

> Currently, I've installed  kernel-2.4.12 and using Johanns patch for this 
> kernel.
> 
> I've read through the docu, and got my system to recognize the joystick.
> 
> I've got an AVB Top Shot Pegasus (connected to the serial port):
> 
> [alex@jungle vegastrike-current]$ jstest /dev/js0
> Joystick (ttyS1/serio0/input0) has 6 axes and 13 buttons. Driver version is 
> 2.1.0.
> Testing ... (interrupt to exit)
> Axes:  0:     0  1:     0  2:     0  3:     0  4:     0  5:     0 Buttons:  
> 0:off  1:off  2:off  3:off  4:off  5:on   6:off  7:off  8:off  9Axes:  0:     
> 0  1:     0  2:     0  3:     0  4:     0  5:     0 Buttons:  0:off  1:off  
> 2:off  3:off  4:off  5:on   6:off  7:off  8:off  9
> 
> Some questions:
> 
> the right 'eight way' hatswitch is recognized as axes 4&5 - why is that 
> hatswitch an axis - and not maybe a row of buttons?

Hats really are axes, aren't they ? I mean, if you see them as buttons, 
that means the left and the right positions could be enabled at the same 
time, which isn't the case. But you're right to rise the question, the 
left hatswitch should be seen as axes as well, which isn't the case for 
the moment.

> 
> The Button Nr.2 and Button Nr.3 (in terms of my joysticks manual) are somehow 
> 'swapped' - at least, 'Button 2' is button nr. 2 in jstest, and 'Button 3' is 
> button 1 in jstest.

I have a tendancy to ignore these docs (they don't say anything about 
the protocol used ;) I will fix it.

> 
> The eventtest util also works fine for me:
> [alex@jungle ff-utils]$ ./evtest /dev/input/event0
> Input driver version is 1.0.0
> Input device ID: bus 0x3 vendor 0x5ef product 0x20a version 0x0
> Input device name: "ttyS1/serio0/input0"
> Supported events:
> 
> [etc]
> 
> 
> ffset -a <whatever>
> 
> seems also to work fine - the autocenter gets set from 0 to 100.
> 
> 
> What doesn't work is fftest:

This is a more annoying issue.

> 
>  [alex@jungle ff-utils]$ ./fftest /dev/input/event0
> Force feedback test program.
> HOLD FIRMLY YOUR WHEEL OR JOYSTICK TO PREVENT DAMAGES
>  
> Device /dev/input/event0 opened
> Axes query: Axis X Axis Y
> Effects: Constant Periodic Spring Friction
> Number of simultaneous effects: 20
> Enter effect number, -1 to exit
> 1
> Enter effect number, -1 to exit
> 2
> 
> Nothing happens at all.

What about effects 0 and 3 ? Do they work ? Did you try to change the 
magnitude of effects ? Did you try with USB ?

> 
> How can I use the other ff-utils (no docu?)?

ffcfstress stresses the joystick by simulating a spring using only 
constant force effects (as explained in the source).
ffmvforce generates forces directed toward the mouse pointer. It's also 
a kind of stress test.
I don't see what kind of documentation you expect ? The only meaningful 
utilities are those to set the gain and the auto-center. Others are code 
sample, and the documentation is naturally situated inside the code.

> 
> Do I have to switch the joystick on at boot time to get it recognized by the 
> driver?
> 

No, you don't. Of course, you need to have it switched on when you load 
the driver and start inputattach. But that needn't be at boot time.

> What has stopped working is my old-analogue joystick:
> 
> [root@jungle /root]# modprobe ns558
> /lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o: init_module: No 
> such device
> Hint: insmod errors can be caused by incorrect module parameters, including 
> invalid IO or IRQ parameters
> /lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o: insmod 
> /lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o failed
> /lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o: insmod ns558 failed
> 
> Before I used 2.4.12, I tried using 2.4.2 with it's non-force-feedback 
> 'iforce' drivers.
> 
> With 2.4.2, my analogue joystick became js0 and the Pegasus was js1.
> 
> Now, with 2.4.12, the loading of ns558 doesn't work anymore - I dunno why?
> 

Me neither. Perhaps a problem with es1371 ??? But I don't think the 
I-Force driver has anything to do with that (especially as ns558 is 
loaded before the iforce stuff). My patch does not touch ns558, btw.

> I don't think that's a problem with the force-feedback-drivers - any idea why 
> it doesn't want my ns558 module (haven't changed anything in BIOS or 
> interrupts).
> 
> See here my loading script:
> 
> echo "Loading Sound modules"
>  
> modprobe es1371 joystick=0x200
>  
> echo "Loading Joystick modules"
>  
> modprobe joydev # userland interface
> modprobe ns558 # gameport driver
> modprobe analog # analog-joystick
>  
> modprobe serio
> modprobe serport
> modprobe iforce
> modprobe evdev
>  
> /usr/local/bin/inputattach --iforce /dev/ttyS1 &
> 
> 
> Any ideas or comments?
> 
> I'll hope I'll be able to update on 2.4.17 soon.
> 
> 
> 
> Alex
> 
> 

-- 
Johann Deneux

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif

[Libff-devel] Vegastrike and Force Feedback

[Alexander R. <ale...@us...>]

Hi,

I am a Co-Developer to Vegastrike vegastrike.sourceforge.net, a 3D space 
fight sim.

I have written the joystick support for Vegastrike, and now I own a new 
force-feedback joystick, so I'll do also the Force Feedback support for 
Vegastrike.

I've already got contacts to Johann Deneux, but I'm now also on the 
libff-devel and linuxconsole-dev mailing lists.

My job would be, to help write a high-level force feedback library, and then 
make Vegastrike use it.

What has been done in writing such a high-level library already?
Any concepts yet etc?

Currently, I've installed  kernel-2.4.12 and using Johanns patch for this 
kernel.

I've read through the docu, and got my system to recognize the joystick.

I've got an AVB Top Shot Pegasus (connected to the serial port):

[alex@jungle vegastrike-current]$ jstest /dev/js0
Joystick (ttyS1/serio0/input0) has 6 axes and 13 buttons. Driver version is 
2.1.0.
Testing ... (interrupt to exit)
Axes:  0:     0  1:     0  2:     0  3:     0  4:     0  5:     0 Buttons:  
0:off  1:off  2:off  3:off  4:off  5:on   6:off  7:off  8:off  9Axes:  0:     
0  1:     0  2:     0  3:     0  4:     0  5:     0 Buttons:  0:off  1:off  
2:off  3:off  4:off  5:on   6:off  7:off  8:off  9

Some questions:

the right 'eight way' hatswitch is recognized as axes 4&5 - why is that 
hatswitch an axis - and not maybe a row of buttons?

The Button Nr.2 and Button Nr.3 (in terms of my joysticks manual) are somehow 
'swapped' - at least, 'Button 2' is button nr. 2 in jstest, and 'Button 3' is 
button 1 in jstest.

The eventtest util also works fine for me:
[alex@jungle ff-utils]$ ./evtest /dev/input/event0
Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0x5ef product 0x20a version 0x0
Input device name: "ttyS1/serio0/input0"
Supported events:

[etc]


ffset -a <whatever>

seems also to work fine - the autocenter gets set from 0 to 100.


What doesn't work is fftest:

 [alex@jungle ff-utils]$ ./fftest /dev/input/event0
Force feedback test program.
HOLD FIRMLY YOUR WHEEL OR JOYSTICK TO PREVENT DAMAGES
 
Device /dev/input/event0 opened
Axes query: Axis X Axis Y
Effects: Constant Periodic Spring Friction
Number of simultaneous effects: 20
Enter effect number, -1 to exit
1
Enter effect number, -1 to exit
2

Nothing happens at all.

How can I use the other ff-utils (no docu?)?

Do I have to switch the joystick on at boot time to get it recognized by the 
driver?

What has stopped working is my old-analogue joystick:

[root@jungle /root]# modprobe ns558
/lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o: init_module: No 
such device
Hint: insmod errors can be caused by incorrect module parameters, including 
invalid IO or IRQ parameters
/lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o: insmod 
/lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o failed
/lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o: insmod ns558 failed

Before I used 2.4.12, I tried using 2.4.2 with it's non-force-feedback 
'iforce' drivers.

With 2.4.2, my analogue joystick became js0 and the Pegasus was js1.

Now, with 2.4.12, the loading of ns558 doesn't work anymore - I dunno why?

I don't think that's a problem with the force-feedback-drivers - any idea why 
it doesn't want my ns558 module (haven't changed anything in BIOS or 
interrupts).

See here my loading script:

echo "Loading Sound modules"
 
modprobe es1371 joystick=0x200
 
echo "Loading Joystick modules"
 
modprobe joydev # userland interface
modprobe ns558 # gameport driver
modprobe analog # analog-joystick
 
modprobe serio
modprobe serport
modprobe iforce
modprobe evdev
 
/usr/local/bin/inputattach --iforce /dev/ttyS1 &


Any ideas or comments?

I'll hope I'll be able to update on 2.4.17 soon.



Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

[Libff-devel] Proposed Headers

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

    Hi there...sorry for the long delay, I had serious server problems=20
here...
    Well, I've changed those headers as we discussed...I kept the=20
functions for creating the blocks, added some device handling ones,=20
changed a lot of parameters, and added the set_parameter and=20
get_parameter so languages without direct struct access(or commercial=20
games which can't rely on a fixed struct) can use the library just as=20
well...I still need to standardize coding(it's all mixed up for now),=20
but that's less important...

Rodrigo

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

Re: [Libff-devel] Re: libff API

[Johann D. <de...@if...>]

Rodrigo Damazio wrote:
> Johann Deneux wrote:
> 
>> Rodrigo Damazio wrote:
>>
>>>
>>> Johann Deneux wrote:
>>>
>>>> On Sun, 17 Feb 2002, Rodrigo Damazio wrote:
>>>>
>>>>> interoperability, why couldn't other languages handle structs??
>>>>>
>>>>
>>>> I don't know if all languages have the notion of structures, and if 
>>>> they
>>>> do, their implementation may be binary-incompatible with C.
>>>> These are hypothetical issues, I don't know much about Perl, Python, 
>>>> Ruby
>>>> and other languages people like.
>>>> Another problem is that every time we touch a structure, every 
>>>> application using libff must be recompiled.
>>>> If we hide the structures, recompilation is only necessary when 
>>>> changing
>>>> the function prototypes.
>>>>
>>>   I get your point...how about using both ways?? Having the structs, 
>>> and if the calling language can't handle them directly, it can just 
>>> use the manipulation functions, whereas in C and similars which can 
>>> handle structs, it can be made a lot easier...or perhaps we even 
>>> should make this a C-only version and write wrappers for Perl and 
>>> other languages...I've seen a few libraries which do that...
>>>
>>
>> Ok. But then we have to design our structures very carefully, so that 
>> we hopefully do not need to change them later on. 
> 
> 
>    I was thinking...how much slower is it to use your method?? It

You have to put the parameters on the stack, make a function call, 
execute the body, store the result, return. That's several times slower 
than making a direct access to a structure.
But this is still ok. The second method would take a few nanoseconds, 
the first a few tens of nanoseconds. Unless you change these parameters 
very often (several millions of times per second), it's hardly going to 
be noticeable. Anyway, I don't think it's possible nor useful to update 
an effect more than 100 times a second.

> wouldn't imply a meaninful delay for a game, would it?? Perhaps we could 
> use that for changing parameters, and make some shortcut functions such 
> as to create an effect, already passing all the parameters in a single 
> function instead of making lots of individual calls...also functions for 
> copying blocks and the like...that should make it just as usable as 
> using structs...
> 

Yes, probably.
Should we have the notion of parameter blocks ? It looks a bit too 
hardware specific to me. But maybe I am exagerating.
I think we should not hesitate to experiment different approaches. We 
are only two to discuss these problems, and neither of us is very 
experienced in this area.
The best would be to start implementing something and try it out.



>        I see...ok, so we'll use the original way(returning the error 
> code)...I'll put all this in the header file and send it later tonight...

Yes, having some code at sight will help clarify and summarize what has 
been discussed.

-- 
Johann Deneux

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif

Re: [Libff-devel] Re: libff API

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

Johann Deneux wrote:

> Rodrigo Damazio wrote:
>
>>
>> Johann Deneux wrote:
>>
>>> On Sun, 17 Feb 2002, Rodrigo Damazio wrote:
>>>
>>>> interoperability, why couldn't other languages handle structs??
>>>>
>>>
>>> I don't know if all languages have the notion of structures, and if=20
>>> they
>>> do, their implementation may be binary-incompatible with C.
>>> These are hypothetical issues, I don't know much about Perl, Python,=20
>>> Ruby
>>> and other languages people like.
>>> Another problem is that every time we touch a structure, every=20
>>> application using libff must be recompiled.
>>> If we hide the structures, recompilation is only necessary when=20
>>> changing
>>> the function prototypes.
>>>
>>   I get your point...how about using both ways?? Having the structs,=20
>> and if the calling language can't handle them directly, it can just=20
>> use the manipulation functions, whereas in C and similars which can=20
>> handle structs, it can be made a lot easier...or perhaps we even=20
>> should make this a C-only version and write wrappers for Perl and=20
>> other languages...I've seen a few libraries which do that...
>>
>
> Ok. But then we have to design our structures very carefully, so that=20
> we hopefully do not need to change them later on.=20

    I was thinking...how much slower is it to use your method?? It=20
wouldn't imply a meaninful delay for a game, would it?? Perhaps we could=20
use that for changing parameters, and make some shortcut functions such=20
as to create an effect, already passing all the parameters in a single=20
function instead of making lots of individual calls...also functions for=20
copying blocks and the like...that should make it just as usable as=20
using structs...

>
>>>>        - Perhaps we should treat compound effects the same way we=20
>>>> treat effects - that would not only make it easier to use, but=20
>>>> would also give us the possibility to build an effect hierarchy...
>>>>        - About effect IDs, how about keeping it in the struct=20
>>>> itself?? That'd make it a bit easier for updating effects...
>>>>
>>>>        Also, about ff_error, I'm in doubt whether we should return=20
>>>> it in all functions, or should return pointers directly(and upon an=20
>>>> error, return NULL)...that would allow for something like this:
>>>>
>>>> eff =3D FF_create_constant(dir, mag, FF_create_envelope(bla bla),=20
>>>> FF_create_trigger(bla bla), FF_create_time(bla bla), flags);
>>>> instead of having to create each of these individually and setting=20
>>>> all their parameters...
>>>>
>>>
>>> Why not. But then we cannot return error codes. The user only knows=20
>>> if it
>>> worked/failed, but has no hint why.
>>>
>>       Can't we use something like errno for the errors?? That's what=20
>> I thought...or even a function FF_get_error...although you may be=20
>> right...
>
>
> We could, but I personnaly dislike this method. In a multithreaded=20
> process, handling errno correctly is not obvious.
> We could use errno if it bought us something, but I just do not see=20
> the advantage of using composition of functions. It only spares the=20
> declaration of a few variables, but the developer may want to keep=20
> track of the parameter blocks ids anyway, which means he will have to=20
> declare variables for those blocks.=20

        I see...ok, so we'll use the original way(returning the error=20
code)...I'll put all this in the header file and send it later tonight...

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

[Libff-devel] Re: libff API

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

Rodrigo Damazio wrote:

> 
> Johann Deneux wrote:
> 
>> On Sun, 17 Feb 2002, Rodrigo Damazio wrote:
>>
>>> interoperability, why couldn't other languages handle structs??
>>>
>>
>> I don't know if all languages have the notion of structures, and if they
>> do, their implementation may be binary-incompatible with C.
>> These are hypothetical issues, I don't know much about Perl, Python, Ruby
>> and other languages people like.
>> Another problem is that every time we touch a structure, every 
>> application using libff must be recompiled.
>> If we hide the structures, recompilation is only necessary when changing
>> the function prototypes.
>>
>   I get your point...how about using both ways?? Having the structs, and 
> if the calling language can't handle them directly, it can just use the 
> manipulation functions, whereas in C and similars which can handle 
> structs, it can be made a lot easier...or perhaps we even should make 
> this a C-only version and write wrappers for Perl and other 
> languages...I've seen a few libraries which do that...
> 

Ok. But then we have to design our structures very carefully, so that we 
hopefully do not need to change them later on.


>>>        - Perhaps we should treat compound effects the same way we 
>>> treat effects - that would not only make it easier to use, but would 
>>> also give us the possibility to build an effect hierarchy...
>>>        - About effect IDs, how about keeping it in the struct 
>>> itself?? That'd make it a bit easier for updating effects...
>>>
>>>        Also, about ff_error, I'm in doubt whether we should return it 
>>> in all functions, or should return pointers directly(and upon an 
>>> error, return NULL)...that would allow for something like this:
>>>
>>> eff = FF_create_constant(dir, mag, FF_create_envelope(bla bla), 
>>> FF_create_trigger(bla bla), FF_create_time(bla bla), flags);
>>> instead of having to create each of these individually and setting 
>>> all their parameters...
>>>
>>
>> Why not. But then we cannot return error codes. The user only knows if it
>> worked/failed, but has no hint why.
>>
>       Can't we use something like errno for the errors?? That's what I 
> thought...or even a function FF_get_error...although you may be right...

We could, but I personnaly dislike this method. In a multithreaded 
process, handling errno correctly is not obvious.
We could use errno if it bought us something, but I just do not see the 
advantage of using composition of functions. It only spares the 
declaration of a few variables, but the developer may want to keep track 
of the parameter blocks ids anyway, which means he will have to declare 
variables for those blocks.


-- 
Johann Deneux

[Libff-devel] Re: libff API

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

Johann Deneux wrote:

> On Sun, 17 Feb 2002, Rodrigo Damazio wrote:
>
>> interoperability, why couldn't other languages handle structs??
>>
>
> I don't know if all languages have the notion of structures, and if the=
y
> do, their implementation may be binary-incompatible with C.
> These are hypothetical issues, I don't know much about Perl, Python, Ru=
by
> and other languages people like.
> Another problem is that every time we touch a structure, every=20
> application using libff must be recompiled.
> If we hide the structures, recompilation is only necessary when changin=
g
> the function prototypes.
>
   I get your point...how about using both ways?? Having the structs,=20
and if the calling language can't handle them directly, it can just use=20
the manipulation functions, whereas in C and similars which can handle=20
structs, it can be made a lot easier...or perhaps we even should make=20
this a C-only version and write wrappers for Perl and other=20
languages...I've seen a few libraries which do that...

>>        - Perhaps we should treat compound effects the same way we=20
>> treat effects - that would not only make it easier to use, but would=20
>> also give us the possibility to build an effect hierarchy...
>>        - About effect IDs, how about keeping it in the struct=20
>> itself?? That'd make it a bit easier for updating effects...
>>
>>        Also, about ff_error, I'm in doubt whether we should return it=20
>> in all functions, or should return pointers directly(and upon an=20
>> error, return NULL)...that would allow for something like this:
>>
>> eff =3D FF_create_constant(dir, mag, FF_create_envelope(bla bla),=20
>> FF_create_trigger(bla bla), FF_create_time(bla bla), flags);
>> instead of having to create each of these individually and setting=20
>> all their parameters...
>>
>
> Why not. But then we cannot return error codes. The user only knows if =
it
> worked/failed, but has no hint why.
>
       Can't we use something like errno for the errors?? That's what I=20
thought...or even a function FF_get_error...although you may be right...

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: [Libff-devel] libff API

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

On Mon, 18 Feb 2002, Rodrigo Damazio wrote:

> Johann Deneux wrote:
> 
> > On Sun, 17 Feb 2002, Rodrigo Damazio wrote:
> >
> >> Johann Deneux wrote:
> >>
> >>>>       My idea was not using a queue - it was just aborting and
> >>>> returning an error and let the application decide whether it'll try 
> >>>> again, etc..
> >>>>
> >>> Ok. That's what's being done now.
> >>
> >>        Do you think we should keep it this way?? I think it's good 
> >> enough...
> >>
> >
> > Yes. We can also add a FF_play_as_soon_as_possible function that takes
> > care of the retries (the actual name of the function should be shorter,
> > of course).
> >
>        That would need a thread just for handling the retries, wouldn't 
> it??

Indeed.


-- 
Johann Deneux

Re: [Libff-devel] libff API

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

Johann Deneux wrote:

> On Sun, 17 Feb 2002, Rodrigo Damazio wrote:
>
>> Johann Deneux wrote:
>>
>>>>       My idea was not using a queue - it was just aborting and
>>>> returning an error and let the application decide whether it'll try=20
>>>> again, etc..
>>>>
>>> Ok. That's what's being done now.
>>
>>        Do you think we should keep it this way?? I think it's good=20
>> enough...
>>
>
> Yes. We can also add a FF_play_as_soon_as_possible function that takes
> care of the retries (the actual name of the function should be shorter,
> of course).
>
       That would need a thread just for handling the retries, wouldn't=20
it??

>>>>>>       I suppose there is another lib which can be used for=20
>>>>>> reading the device data?? Like axes position, buttons, etc...so=20
>>>>>> we don't need to worry about that, right?
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> No, we do need to take care of that.
>>>>
>>>>
>>>>
>>>>       Incredible enough, I looked, and there's NO basic joystick=20
>>>> library in freshmeat or sourceforge...just stuff like "run programs=20
>>>> with your joystick"...should we really include that in libff, or=20
>>>> would it be better to make a generic event library(like directinput)=
??
>>>>
>>> Well, there are PLib, SDL, libjsw, certainly ClanLib and maybe others.
>>
>>        I know...but should we implement input functions in libff too,=20
>> or should we just leave that up to other libs??
>>
>
> My philosophy is "If other people can do some work, let them do it".
> The nice thing about the drivers in Linux is that it is possible to ope=
n
> one joystick several times. This means that input and force feedback
> libraries do not need to be aware of eachother.
>
       Yes, I have realized that...it's really nice...

>>>>>>>>> Other question: what's your opinion about the shared parameter
>>>>>>>>
>>>>> block issue ? It's seems we are
>>>>>
>>>>>>>>> forced to go for the restrictive 1-parameter 1-effect scheme=20
>>>>>>>>> on the driver side, but that does
>>>>>>>>> not mean we cannot try to emulate it on the API side.
>>>>>>>>>
>>>>>>>>       I'm in favor of it - in fact the API has already started=20
>>>>>>>> with that idea...but probably(and specially if the kernel=20
>>>>>>>> chooses 1-to-1 scheme), updating a block will only change the=20
>>>>>>>> effects where it is used, if the effect itself is updated...
>>>>>>>>
>>>>>>> We will need to define clearly what we mean by effect. To me, it=20
>>>>>>> looks
>>>>>>> like we should apply the change as soon as the parameter block=20
>>>>>>> is changed.
>>>>>>>
>>>>>>       An effect is a group of properties that will generate a=20
>>>>>> force...
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Then when you update a parameter you update the effect itself too.=20
>>>>> How can you update a parameter without updating the effect ?
>>>>
>>>>
>>>>
>>>>
>>>>       You can't..specially if the kernel uses 1-to-1 parameter=20
>>>> models...you can update the copy that is in user memory, and that=20
>>>> may make managing effects easier, for example you can have all your=20
>>>> effects with the same envelope, and can change only one envelope,=20
>>>> but you still have to call an update for all the effects...perhaps=20
>>>> we could even write a little function that would update all effects=20
>>>> that use a certain block automagically...
>>>>
>>>
>>> By the way, I wondered what happened to those two messages I sent=20
>>> yesterday. I can see them in the archives, but I have not yet=20
>>> received them. I posted two messages entitled "API: handling=20
>>> effects" and "API suggestion: feature queries". Did you receive them =
?
>>
>>        No, I didn't...maybe you should repost them...I'll look in the=20
>> archive anyway...
>>        I'm attaching a rough draft of the API - it's just my initial=20
>> suggestion...please do criticize...
>>        One point I forgot to mention is the whole thing about angle=20
>> units - in my suggestion I made it so the programmer can specify=20
>> angles in degrees(0-360), radians(0-2PI), grads(0-400), or=20
>> raw(0-FFFF)...what do you think about that??
>>
>
> Why not. I do not think it's necessary, as programmers can probably do=20
> the
> conversion themselves. I never heard anybody complaining that the math
> lib (cos, sin and friends) only handled radians. But people certainly
> won't complain if we give them macros to handle the conversions.
>
       I guess I'll just make it raw angles and leave all the conversion=20
to macros then...

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: [Libff-devel] Re: libff API

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

On Sun, 17 Feb 2002, Rodrigo Damazio wrote:

> Johann Deneux wrote:
> 
> >>
> >>        My idea was not using a queue - it was just aborting and 
> 
> >> returning an error and let the application decide whether it'll try 
> >> again, etc..
> >>
> >
> > Ok. That's what's being done now. 
> 
>         Do you think we should keep it this way?? I think it's good 
> enough...

Yes. We can also add a FF_play_as_soon_as_possible function that takes
care of the retries (the actual name of the function should be shorter,
of course).

> 
> >
> >>>>> Maybe there are properties of the device itself that could be 
> >>>>> queried, too.
> >>>>> Do you see any such dynamic property (ie beside the name, type, 
> >>>>> effects supported
> >>>>> by the device) ?
> >>>>>
> >>>>        That'd be stuff like gain, which actuactors are enabled, etc... 
> >>>
>     How about this part?? How important is it??

I think it is. I agree we need to be able to query the device.

> 
> >>>>
> >>>>        I suppose there is another lib which can be used for reading 
> >>>> the device data?? Like axes position, buttons, etc...so we don't 
> >>>> need to worry about that, right?
> >>>
> >>>
> >>>
> >>>
> >>> No, we do need to take care of that. 
> >>
> >>
> >>
> >>        Incredible enough, I looked, and there's NO basic joystick 
> >> library in freshmeat or sourceforge...just stuff like "run programs 
> >> with your joystick"...should we really include that in libff, or 
> >> would it be better to make a generic event library(like directinput)??
> >>
> >
> > Well, there are PLib, SDL, libjsw, certainly ClanLib and maybe others. 
> 
>         I know...but should we implement input functions in libff too, 
> or should we just leave that up to other libs??

My philosophy is "If other people can do some work, let them do it".
The nice thing about the drivers in Linux is that it is possible to open
one joystick several times. This means that input and force feedback
libraries do not need to be aware of eachother.

> 
> >
> >>> >>>>Other question: what's your opinion about the shared parameter 
> >>> block issue ? It's seems we are
> >>>
> >>>>>>> forced to go for the restrictive 1-parameter 1-effect scheme on 
> >>>>>>> the driver side, but that does
> >>>>>>> not mean we cannot try to emulate it on the API side.
> >>>>>>>
> >>>>>>        I'm in favor of it - in fact the API has already started 
> >>>>>> with that idea...but probably(and specially if the kernel chooses 
> >>>>>> 1-to-1 scheme), updating a block will only change the effects 
> >>>>>> where it is used, if the effect itself is updated...
> >>>>>>
> >>>>>
> >>>>> We will need to define clearly what we mean by effect. To me, it 
> >>>>> looks
> >>>>> like we should apply the change as soon as the parameter block is 
> >>>>> changed.
> >>>>>
> >>>>        An effect is a group of properties that will generate a 
> >>>> force...
> >>>
> >>>
> >>>
> >>>
> >>> Then when you update a parameter you update the effect itself too. 
> >>> How can you update a parameter without updating the effect ? 
> >>
> >>
> >>
> >>
> >>        You can't..specially if the kernel uses 1-to-1 parameter 
> >> models...you can update the copy that is in user memory, and that may 
> >> make managing effects easier, for example you can have all your 
> >> effects with the same envelope, and can change only one envelope, but 
> >> you still have to call an update for all the effects...perhaps we 
> >> could even write a little function that would update all effects that 
> >> use a certain block automagically...
> >
> >
> > By the way, I wondered what happened to those two messages I sent 
> > yesterday. I can see them in the archives, but I have not yet received 
> > them. I posted two messages entitled "API: handling effects" and "API 
> > suggestion: feature queries". Did you receive them ? 
> 
>         No, I didn't...maybe you should repost them...I'll look in the 
> archive anyway...
>         I'm attaching a rough draft of the API - it's just my initial 
> suggestion...please do criticize...
>         One point I forgot to mention is the whole thing about angle 
> units - in my suggestion I made it so the programmer can specify angles 
> in degrees(0-360), radians(0-2PI), grads(0-400), or raw(0-FFFF)...what 
> do you think about that??

Why not. I do not think it's necessary, as programmers can probably do the
conversion themselves. I never heard anybody complaining that the math
lib (cos, sin and friends) only handled radians. But people certainly
won't complain if we give them macros to handle the conversions.


-- 
Johann Deneux

Re: [Libff-devel] Question about current API

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

On Mon, 18 Feb 2002, Adrian McMenamin wrote:

> On Monday 18 Feb 2002 9:26 am, Johann Deneux wrote:
> > On Mon, 18 Feb 2002, Adrian McMenamin wrote:
> > > I am writing a driver for the Puru Puru Pack (Rumble Pack) on the Sega
> > > Dreamcast and I wonder if someone might tell me what measurement of time
> > > (seconds/jiffies/milliseconds?) is used for the time measurements in
> > > ff_replay?
> >
> > milliseconds.
> >
> > Do you have the latest version of this file ? If not, please fetch it from
> > the CVS of the linuxconsole project on sourceforge.
> 
> Well, I am writing the driver against 2.4.16 - which is the current 
> distribution on the linuxdc cvs.

Would you mind using the latest version of the API ? I am not too
enthusiastic about having several versions of the API.
Of course, the decision remains yours, but there are differences in
struct ff_effect that will cause compatibility issues.


-- 
Johann Deneux

Re: [Libff-devel] Question about current API

[Adrian M. <ad...@mc...>]

On Monday 18 Feb 2002 9:26 am, Johann Deneux wrote:
> On Mon, 18 Feb 2002, Adrian McMenamin wrote:
> > I am writing a driver for the Puru Puru Pack (Rumble Pack) on the Sega
> > Dreamcast and I wonder if someone might tell me what measurement of time
> > (seconds/jiffies/milliseconds?) is used for the time measurements in
> > ff_replay?
>
> milliseconds.
>
> Do you have the latest version of this file ? If not, please fetch it from
> the CVS of the linuxconsole project on sourceforge.

Well, I am writing the driver against 2.4.16 - which is the current 
distribution on the linuxdc cvs.

It's almost done - next 24hours or so (famous last words).

Adrian

Re: [Libff-devel] Question about current API

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

On Mon, 18 Feb 2002, Adrian McMenamin wrote:

> I am writing a driver for the Puru Puru Pack (Rumble Pack) on the Sega 
> Dreamcast and I wonder if someone might tell me what measurement of time 
> (seconds/jiffies/milliseconds?) is used for the time measurements in 
> ff_replay?

milliseconds.

Do you have the latest version of this file ? If not, please fetch it from
the CVS of the linuxconsole project on sourceforge.

-- 
Johann Deneux

[Libff-devel] Question about current API

[Adrian M. <ad...@mc...>]

I am writing a driver for the Puru Puru Pack (Rumble Pack) on the Sega 
Dreamcast and I wonder if someone might tell me what measurement of time 
(seconds/jiffies/milliseconds?) is used for the time measurements in 
ff_replay?

Thanks

Adrian

Re: [Libff-devel] Re: libff API

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

Johann Deneux wrote:

>>
>>        My idea was not using a queue - it was just aborting and=20
>> returning an error and let the application decide whether it'll try=20
>> again, etc..
>>
>
> Ok. That's what's being done now.=20

        Do you think we should keep it this way?? I think it's good=20
enough...

>
>>>>> Maybe there are properties of the device itself that could be=20
>>>>> queried, too.
>>>>> Do you see any such dynamic property (ie beside the name, type,=20
>>>>> effects supported
>>>>> by the device) ?
>>>>>
>>>>        That'd be stuff like gain, which actuactors are enabled, etc.=
..=20
>>>
    How about this part?? How important is it??

>>>>
>>>>        I suppose there is another lib which can be used for reading=20
>>>> the device data?? Like axes position, buttons, etc...so we don't=20
>>>> need to worry about that, right?
>>>
>>>
>>>
>>>
>>> No, we do need to take care of that.=20
>>
>>
>>
>>        Incredible enough, I looked, and there's NO basic joystick=20
>> library in freshmeat or sourceforge...just stuff like "run programs=20
>> with your joystick"...should we really include that in libff, or=20
>> would it be better to make a generic event library(like directinput)??
>>
>
> Well, there are PLib, SDL, libjsw, certainly ClanLib and maybe others.=20

        I know...but should we implement input functions in libff too,=20
or should we just leave that up to other libs??

>
>>> >>>>Other question: what's your opinion about the shared parameter=20
>>> block issue ? It's seems we are
>>>
>>>>>>> forced to go for the restrictive 1-parameter 1-effect scheme on=20
>>>>>>> the driver side, but that does
>>>>>>> not mean we cannot try to emulate it on the API side.
>>>>>>>
>>>>>>        I'm in favor of it - in fact the API has already started=20
>>>>>> with that idea...but probably(and specially if the kernel chooses=20
>>>>>> 1-to-1 scheme), updating a block will only change the effects=20
>>>>>> where it is used, if the effect itself is updated...
>>>>>>
>>>>>
>>>>> We will need to define clearly what we mean by effect. To me, it=20
>>>>> looks
>>>>> like we should apply the change as soon as the parameter block is=20
>>>>> changed.
>>>>>
>>>>        An effect is a group of properties that will generate a=20
>>>> force...
>>>
>>>
>>>
>>>
>>> Then when you update a parameter you update the effect itself too.=20
>>> How can you update a parameter without updating the effect ?=20
>>
>>
>>
>>
>>        You can't..specially if the kernel uses 1-to-1 parameter=20
>> models...you can update the copy that is in user memory, and that may=20
>> make managing effects easier, for example you can have all your=20
>> effects with the same envelope, and can change only one envelope, but=20
>> you still have to call an update for all the effects...perhaps we=20
>> could even write a little function that would update all effects that=20
>> use a certain block automagically...
>
>
> By the way, I wondered what happened to those two messages I sent=20
> yesterday. I can see them in the archives, but I have not yet received=20
> them. I posted two messages entitled "API: handling effects" and "API=20
> suggestion: feature queries". Did you receive them ?=20

        No, I didn't...maybe you should repost them...I'll look in the=20
archive anyway...
        I'm attaching a rough draft of the API - it's just my initial=20
suggestion...please do criticize...
        One point I forgot to mention is the whole thing about angle=20
units - in my suggestion I made it so the programmer can specify angles=20
in degrees(0-360), radians(0-2PI), grads(0-400), or raw(0-FFFF)...what=20
do you think about that??

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: [Libff-devel] Re: libff API

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

Johann Deneux wrote:

> Rodrigo Damazio wrote:
>
>> Johann Deneux wrote:
>>
>>> On Fri, 15 Feb 2002 20:41:27 -0200
>>> "Rodrigo Damazio" <cu...@uo...> wrote:
>>
>
>>>
>>> My first idea was that we should be able to ask the device if it's=20
>>> ready to
>>> accept an update. For example, with iforce devices, we must wait=20
>>> that the device
>>> acknowledges the update before performing a new update. However, it=20
>>> is ok to
>>> update effect 2 even if we haven't yet received the ack for effect=20
>>> 1. That's why
>>> my second thought was to do it on a per-effect basis.
>>>
>>        I see...that's possible...if the device is not ready, what=20
>> should we do?? Make it async and return an error, or should we just=20
>> sit and wait 'til it's possible??
>
>
> The iforce module just refuses the update and return an error. The=20
> reason for doing that is that generally applications that flood the=20
> device use a "ongoing update" algorithm (for example to render a force=20
> computed by the physics engine). In that case, missing an update is=20
> not too serious.
> The async solution is not too good. Whatever size we may choose for=20
> the queue, it will be filled.=20

        My idea was not using a queue - it was just aborting and=20
returning an error and let the application decide whether it'll try=20
again, etc..

>
>>> Maybe there are properties of the device itself that could be=20
>>> queried, too.
>>> Do you see any such dynamic property (ie beside the name, type,=20
>>> effects supported
>>> by the device) ?
>>>
>>        That'd be stuff like gain, which actuactors are enabled, etc...
>>        I suppose there is another lib which can be used for reading=20
>> the device data?? Like axes position, buttons, etc...so we don't need=20
>> to worry about that, right?
>
>
> No, we do need to take care of that.=20

        Incredible enough, I looked, and there's NO basic joystick=20
library in freshmeat or sourceforge...just stuff like "run programs with=20
your joystick"...should we really include that in libff, or would it be=20
better to make a generic event library(like directinput)??

> >>>>Other question: what's your opinion about the shared parameter=20
> block issue ? It's seems we are
>
>>>>> forced to go for the restrictive 1-parameter 1-effect scheme on=20
>>>>> the driver side, but that does
>>>>> not mean we cannot try to emulate it on the API side.
>>>>>
>>>>        I'm in favor of it - in fact the API has already started=20
>>>> with that idea...but probably(and specially if the kernel chooses=20
>>>> 1-to-1 scheme), updating a block will only change the effects where=20
>>>> it is used, if the effect itself is updated...
>>>>
>>>
>>> We will need to define clearly what we mean by effect. To me, it look=
s
>>> like we should apply the change as soon as the parameter block is=20
>>> changed.
>>>
>>        An effect is a group of properties that will generate a force...
>
>
> Then when you update a parameter you update the effect itself too. How=20
> can you update a parameter without updating the effect ?=20

        You can't..specially if the kernel uses 1-to-1 parameter=20
models...you can update the copy that is in user memory, and that may=20
make managing effects easier, for example you can have all your effects=20
with the same envelope, and can change only one envelope, but you still=20
have to call an update for all the effects...perhaps we could even write=20
a little function that would update all effects that use a certain block=20
automagically...

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: [Libff-devel] Re: libff API

[Johann D. <de...@if...>]

Rodrigo Damazio wrote:
> Johann Deneux wrote:
> 
>> On Fri, 15 Feb 2002 20:41:27 -0200
>> "Rodrigo Damazio" <cu...@uo...> wrote:

>>
>> My first idea was that we should be able to ask the device if it's 
>> ready to
>> accept an update. For example, with iforce devices, we must wait that 
>> the device
>> acknowledges the update before performing a new update. However, it is 
>> ok to
>> update effect 2 even if we haven't yet received the ack for effect 1. 
>> That's why
>> my second thought was to do it on a per-effect basis.
>>
>        I see...that's possible...if the device is not ready, what should 
> we do?? Make it async and return an error, or should we just sit and 
> wait 'til it's possible??

The iforce module just refuses the update and return an error. The 
reason for doing that is that generally applications that flood the 
device use a "ongoing update" algorithm (for example to render a force 
computed by the physics engine). In that case, missing an update is not 
too serious.
The async solution is not too good. Whatever size we may choose for the 
queue, it will be filled.

> 
>>
>> Maybe there are properties of the device itself that could be queried, 
>> too.
>> Do you see any such dynamic property (ie beside the name, type, 
>> effects supported
>> by the device) ?
>>
>        That'd be stuff like gain, which actuactors are enabled, etc...
>        I suppose there is another lib which can be used for reading the 
> device data?? Like axes position, buttons, etc...so we don't need to 
> worry about that, right?

No, we do need to take care of that.

> 
>> If there is no effect, the status of the device is obvious: it's doing
>> nothing (what could it do ???)
>>
>        It could be playing effects from another application =c))

Right.

>>>
>>>> Other question: what's your opinion about the shared parameter block 
>>>> issue ? It's seems we are
>>>> forced to go for the restrictive 1-parameter 1-effect scheme on the 
>>>> driver side, but that does
>>>> not mean we cannot try to emulate it on the API side.
>>>>
>>>        I'm in favor of it - in fact the API has already started with 
>>> that idea...but probably(and specially if the kernel chooses 1-to-1 
>>> scheme), updating a block will only change the effects where it is 
>>> used, if the effect itself is updated...
>>>
>>
>> We will need to define clearly what we mean by effect. To me, it looks
>> like we should apply the change as soon as the parameter block is 
>> changed.
>>
>        An effect is a group of properties that will generate a force...

Then when you update a parameter you update the effect itself too. How 
can you update a parameter without updating the effect ?

> 
>        Btw, should we implement effect groups, like in Immersion Studio? 
> It could be useful...

I too thought about that. See my other posts to this list...

-- 
Johann Deneux

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif

[Libff-devel] Re: libff API

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

Johann Deneux wrote:

>On Fri, 15 Feb 2002 20:41:27 -0200
>"Rodrigo Damazio" <cu...@uo...> wrote:
>
>>Johann Deneux wrote:
>>
>>>On Fri, 15 Feb 2002 11:55:38 -0200
>>>"Rodrigo Damazio" <cu...@uo...> wrote:
>>>
>>>>[...]
>>>>
>>>I think it would be nice to be able to store/load effects to/from file=
s. I
>>>already started a tool to edit effects (although its development is no=
t
>>>going forward very fast).
>>>
>>        Sounds nice...what file format are you using?? I could include=20
>>this tool in the libff package, and add support for loading its files...
>>
>
>Right now, it's not implemented. I started to hack Immersion Studio file=
s,
>but using a more readable format wouldn't hurt. I don't know much about
>XML, but an ascii-based file would be fine.
>
        Perhaps XML would be nice, since it's ascii-readable and very=20
well-structured ...

>>>What I would need is the following:
>>>- Create an effect/Load it
>>>- Update it (restart it if necessary ?)
>>>
>>        Do all devices support updating an effect while it's playing??
>>
>
>Probably not, as the DInput API mentions this issue. In that case, one s=
olution
>is to stop-update-restart effect. Not very nice, but if we use the trick=
 you
>describe below about posing we could avoid some problems related to the =
envelope.
>
        Yes, I guess so...there really ain't much we can do if the=20
device doesn't support something...

>>>- Control the playback (start, stop, pause -the later does not seem to=
 be supported by I-Force devices- )
>>>
>>        Perhaps we could emulate pause with a stop, then resume with=20
>>restarting the effect with a 0-attack-time envelope??
>>
>
>More generally, we need to know when exactly we paused. After that we ne=
ed to
>update the envelope or the time-offset for periodic effects. There is a =
nasty
>case however:
>  --X-   ----
>_/    |_/    |
>=3D=3D=3D=3D=3D=3D=3D
>^ One period
>
>If we pause at X, we can change the envelope, but we must restore it whe=
n the
>effect restarts (it is possible to play an effect several times).
>Anyway, one role of libff is to unload this piece of work from the kerne=
l driver.
>
        Hmmm I guess the main problem here would be keeping track of=20
time, since not even the kernel knows about it - only the device...if we=20
pause the effect in the middle of the attack phase of the envelope, for=20
example, we have to set the attack level accordingly...like this - if=20
the effect should play 5 times, and we pause in the attack phase of the=20
second time...to unpause it, we'll have to: set envelope/update=20
effect/play once/set old envelop back/update/play 3 more times...and=20
make sure all this happens as fast as possible...this will be a pain to=20
code...but anyway...

>>>- Query the status of an effect (playing, stopped)
>>>
>>>It may also seem useful to be able to query the state of the device (i=
t
>>>it's accepting new updates), but I think we can stick that into the ef=
fect
>>>status query.
>>>
>>        Hmmm what if we have no effects and want to query the device??
>>
>
>My first idea was that we should be able to ask the device if it's ready=
 to
>accept an update. For example, with iforce devices, we must wait that th=
e device
>acknowledges the update before performing a new update. However, it is o=
k to
>update effect 2 even if we haven't yet received the ack for effect 1. Th=
at's why
>my second thought was to do it on a per-effect basis.
>
        I see...that's possible...if the device is not ready, what=20
should we do?? Make it async and return an error, or should we just sit=20
and wait 'til it's possible??

>
>Maybe there are properties of the device itself that could be queried, t=
oo.
>Do you see any such dynamic property (ie beside the name, type, effects =
supported
>by the device) ?
>
        That'd be stuff like gain, which actuactors are enabled, etc...
        I suppose there is another lib which can be used for reading the=20
device data?? Like axes position, buttons, etc...so we don't need to=20
worry about that, right?

>If there is no effect, the status of the device is obvious: it's doing
>nothing (what could it do ???)
>
        It could be playing effects from another application =3Dc))

>>>The question is what should be left to the user, and what should be ha=
ndled by the API ?
>>>
>>        Exactly...
>>
>>>Other question: what's your opinion about the shared parameter block i=
ssue ? It's seems we are
>>>forced to go for the restrictive 1-parameter 1-effect scheme on the dr=
iver side, but that does
>>>not mean we cannot try to emulate it on the API side.
>>>
>>        I'm in favor of it - in fact the API has already started with=20
>>that idea...but probably(and specially if the kernel chooses 1-to-1=20
>>scheme), updating a block will only change the effects where it is used=
,=20
>>if the effect itself is updated...
>>
>
>We will need to define clearly what we mean by effect. To me, it looks
>like we should apply the change as soon as the parameter block is change=
d.
>
        An effect is a group of properties that will generate a force...

        Btw, should we implement effect groups, like in Immersion=20
Studio? It could be useful...

>>>Btw, I could direct people I know are interested in force feedback to =
your
>>>sf project page. Do you plan to use mailing lists to communicate, or t=
o
>>>use the forums instead ?
>>>
>>        Sure...I'll set up mailing lists...I'll add you there too ok?
>>
>
>Sure, please do it. Or tell me when it's done, I don't know if you can s=
ubscribe
>other people than yourself.
>
        It's done, you're here now =3Dc)

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

[Libff-devel] API: handling effects

[Johann D. <de...@if...>]

Hi again,

This second mail deals with effects. We have to decide if we use open 
structures or abstract data types.

The first solution is convenient to use, provided structures don't 
change. The later is more flexible, but having to go through tens of 
function calls to create an effect can be painful.

I personnaly prefer the second solution. It has the advantage that it 
probably eases the interoperability with other languages (Perl, Python...).


1) Effect creation

/* Allocate an effect */
ff_effectId ff_effectCreate();
/* Note: effects are not bound to devices */

/* Initialize effects */
ff_error ff_effectSetType(ff_effectId, ff_effectType);
ff_error ff_effectSetParameter(ff_effectId, ff_effectParameter,
                                void* data);


Sample use:

ff_effectId fid;
fid = ff_effectCreate();

if (ff_effectSetType(fid, FF_SINE)) {
   /* handle error */
}

ff_duration period = 100; /* 100 ms */
if (ff_effectSetParameter(fid, FF_PERIOD, &period))
{
...
}

if (ff_effectSetParameter(fid, FF_MAGNITUDE, &magnitude))
{
...
}

if (ff_effectSetParameter(fid, FF_OFFSET, &offset))
{
...
}

if (ff_effectSetParameter(fid, FF_DIRECTION, &direction))
{
...
}

...

Note: calling ff_effectSetParameter while an effect is playing will 
update the effect. If dynamic updates is not supported by the device, we 
must decide if we generate an error or perform a pause-update-play.

2) Then we need functions to control playing of effects:

ff_error ff_effectPlay(ff_device, ff_effect_id, int times);
ff_error ff_effectStop(ff_device, ff_effect_id);
ff_error ff_effectPause(ff_device, ff_effect_id);

Not all devices support pausing an effect (is there any device actually 
supporting it ?). What do we do in that case ? emulation, or throw an 
error ?

3) Grouped effects

If you had the occasion to have a look at Immersion Studio, you can see 
that it's possible to create compounds of effects. This are groups of 
effects used to render complex effects.

ff_compound_id ff_compoundCreate();
ff_error ff_compoundAddEffect(ff_compound_id, ff_effect_id,
                               ff_duration start_delay);
ff_error ff_compoundPlay(ff_device, ff_compound_id, int times);
... (same as for effects).

We could even remove ff_effectPlay and friends, and use compounds only.


-- 
Johann Deneux

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif

[Libff-devel] API suggestion: feature queries

[Johann D. <de...@if...>]

Hi there !

Here is a first proposal for the API.

/* Describes a force feedback device
*/
struct ff_device;

/* Related functions */
/* Get a list of available devices on the system */
ff_device_list ff_enumerateDevices();

/* Test if an effect is supported */
bool ff_effectIsSupported(ff_device, ff_effectCapability);

ff_effectCapability would be a pair <effect, feature>. Sample pairs 
would be:
- <FF_CONSTANT, FF_ANY> to check if constant effects are supported
- <FF_CONSTANT, FF_ANY_DIRECTION> to check if constant effects can have 
any direction (not true for wheels, for example)
- <FF_RUMBLE, FF_DIRECTION> to check if rumble effects can have 
direction (I guess it's generally not the case)
- <FF_SINE, FF_UPDATE> to check if it's possible to update a sine wave 
effect while it's playing
- <FF_ALL, FF_PAUSE> to check if it's possible to pause any kind of effect
- and so on, there are many possible combinations
Note the special values FF_ANY and FF_ALL. They can be seen as kinds of 
quantifiers (FF_ANY = exists, FF_ALL = for all). For example, to test if 
a device has any ff capability at all, one could use <FF_ANY, FF_ANY> 
(that's useless though, because ff_enumerateDevices() should not return 
non-ff capable devices)
We could even use these pairs to express constraints and find all the 
devices matching those constraints. But that's for later, I think. We 
need to keep it simple at first, but let's keep this possibility in our 
minds.


/* Return the number of effects that can be played at the same time
*/
int ff_effectsNumber(ff_device);

Note that it's possible that several processes access a device. In that 
case, the actual number of effects playable at the same time may be 
lower. You may wonder what is the use of having several processes 
accessing a device. That's probably not meaningful for joysticks, but it 
is for mice.

-- 
Johann Deneux

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif