Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]

["johann deneux" <johann.deneux@gmail.com>]

On 3/14/07, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On 3/14/07, STenyaK (Bruno González) <stenyak@gmail.com> wrote:
> >
> >
> > On 3/14/07, Anssi Hannula <anssi.hannula@gmail.com> wrote:
> > > >> Do we have any idea if there any users of FF out there?
> > > >
> > > > At least me :). I'm using it for wheel and joystick in modules for
> > locally
> > > > developped multiplatform virtual reality system.
> > >
> > > Wine and BZflag come to mind, though I think the support is quite
> > > limited in both.
> > >
> >
> > There's also vDrift (racing sim), they added support very recently.
> > I plan to add it in my car sim too, but there's still nothing coded.
> >
> > I have a question: if the force is to be 3D, why only 3 possible values?
> > What would they be, 3 torques or 3 forces? In the case of car sims (ff
> > steering wheels), only one axis of torque is usually used (except for 6 dof
> > platforms, as mentioned).
> >
>
> I wonder if we could somehow extend or augment FF envelope se we could
> specify a plane for the effect.. Then a vector could be represented by
> a sum 3 constant effects in 3 separate planes and we could also use
> spring and other effects as well.

I don't think struct ff_envelope is a good candidate: Spring effects
don't have any envelope.
We have plenty of space for new effect types. Why not add a bunch of
new types, and add more structs in the ff_effect union?

The other option where you somehow manage to specify planes and
combine several effects is a good solution for devices where the
driver is responsible for storing effects, but it's wasteful for
I-Force-like devices where the effects are stored on the device. You
would be using two (or more) effects in the device's memory where only
one would be used if you used all the potential of the device. That
is, unless the driver is smart enough to merge effects, but that seems
hard.

-- 
Johann