Re: Custom-shaped periodic effects in force feedback

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

On Mon, 21 Jan 2002, Bj|rn Augustsson wrote:

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

Yes, I know. But the reason I did not choose this scheme earlier was that
it seemed too close to the hardware.

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

Well, the kernel is involved anyway. Either it allows 1 parameter block to
n effects, or not. The first model seems more attracting, but it has the
issue described below.

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

What do you mean ? We can't help it. For this problem to arise, it is
enough to have these two conditions:
1) We allow 1-to-n, instead or (1,2)-to-1 as it is now.
2) We don't control the placement of attributes

1) would be nice to have, but for 2), we can only hope all future devices
won't change too much.

> differently from iforce and PID shows up, it's probably time to
> introduce some kind of libff or whatever to deal with this stuff.

What do you mean ? having two different interfaces, and hiding their
differences in a libff ? I fear this may only move the problem from the
driver to libff.

-- 
Johann Deneux