Re: Custom-shaped periodic effects in force feedback

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

Quoting Johann Deneux <jo...@Do...>:
> On Mon, 21 Jan 2002, Rodrigo Damazio wrote:
> 
> >    Then we'd have to write a little shapeid management(easy)...and 
> > probably we'd delete a shape from kernel memory after it's used in an 
> > effect(just so we don't need another ioctl for that), assigning -1 back 
> > to shapeid in ff_effect(and to avoid bad programming, just make it 
> > ignore any FF_CUSTOM where a shapeid is -1)...or even keep it and create 
> > a EVIOCRMCUSTOM to remove it when desired...
> > 
> > Let me know what you think...
> 
> That's quite close to what I had in mind, except you apply it only for
> custom effects. Deciding to keep or not the union looks like a rather
> unimportant decision to me. I suggested to remove the union and use
> parameter blocks to keep some kind of coherency in the API.

I agree, that's more like what the real thing (at least wrt PID) looks
like anyway.

> More important is the question about whether we should have parameter
> blocks in the API at all.
> 
> The parameter block ioctl approach rises the following issues:
> - One parameter block may be used by several effects. One may see that as
> a feature, as it might allow for some memory to be saved. I am not
> convinced it would be very useful, though.

I think it could, especially for envelope* blocks , which I imagine you
could recycle quite a lot. But really, this is an application thing to
decide, the kernel shouldn't involve itself in these kind of details.

(iforce refers to these as shape. Envelope is from the PID spec, so I'm
going to use that naming.)

> - What should be put into parameters, and what should be put into the core
> of the effect ? For example, the direction of a constant effect is encoded
> in the core of the effect in the I-Force protocol, while the amplitude is
> stored in a parameter block. It seems PID does the same. What if another
> protocol chooses to put the direction into parameter blocks ?

That gets real ugly either way we do it. It makes sense to do it in the
most logical way though, which IHMO is the iforce/PID way; all effects
have a direction, it makes sense to have it in the main block.

(And at least in PID, the amplitude thing is a bit weird. the Set Effect
report has "Gain", and for example the Constant Force effect block has 
"Magnitude". Difference? Magnitude is signed, otherwise I think they're
just multiplied together (along with the Device Gain.))

> This can lead to tricky situations. Imagine we put some attribute X into
> the ff_effect, while a device really stores it in the parameter block. Now
> the application decides to update the attribute X of an effect. The driver
> has to change X in the parameter block (because that's what the device
> wants). Imagine this parameter block is shared by another effect... If we
> change it here, the attribute X of the second effect is also modified,
> what is not the desired behaviour.

Ouch! Let's not do that. *IF* a device that behaves substantially
differently from iforce and PID shows up, it's probably time to
introduce some kind of libff or whatever to deal with this stuff.

/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