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