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