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

From: Dmitry Torokhov
Date: Wed Mar 21 2007 - 15:22:59 EST


On 3/21/07, johann deneux <johann.deneux@xxxxxxxxx> wrote:
On 3/21/07, Jiri Slaby <jirislaby@xxxxxxxxx> wrote:
> STenyaK (Bruno González) napsal(a):
> > On 3/14/07, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote:
> >> > 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.
> >
> > Ideally, afaik we should use:
> > -3 values for translation force (linear force): x,y,z components of
> > the force vector.
> > -4 values for rotation force (torque): x,y,z,w components of the
> > quaternion. You can also use euler angles (and i think there are
> > another one or two notations), which is just 3 values, but i'm not
> > sure it will be a correct decision (due to the gimbal lock problem,
> > which may or may not be present in ff devices, dunno).
>
> So, the resolution is? Since I want no longer have out-of-kernel driver, I
> need to know how to implement the phantom driver -- merge it `as is', i.e.
> control through mmio or rewrite ff layer somehow, and in that case how?
>
> There seem to be only few possibilities:
>
> - new 3D effect, which will be problematic in any other future use, that may
> need more than 3 axis. no matter if torques or vector is passed -- depending
> on device and programmer (as I need to compute torques from forces in FP).
> Maybe struct with 2x 3 axis is OK
>
> - "raw" effect, which may contain more axis, but this is ugly in Anssi's eyes
>
> - something else? (did I forget something)
>

I would suggest adding a new effect type (3d effect) and extending the
union in struct ff_effect.
Let me know if I'm too vague, I already suggested that solution but
got no answer. I wonder if my mail got lost, nobody understood what I
said, or if it's just a plain bad idea.


My concern with a new 3D effect is that it will be a very "simple"
effect with only constant force apllied. That might be enough for
phantom but may not be sufficient for future devices. If we add
ability to specify a "plane" for an effect we will be able to add
envelopes on top of more complex effects and get desired combined
effcet. I would not worry aboput extra memory needed on I-force like
devices because they just would not support additional "planes". What
about phantom? Would it have enough memory?

On the other hand if you guys (Anssi, Johann, Jiri...) decide that a
simple new 3d effect is the most efficient solution for now and will
be enough for a few years (till we get FF v2 API) I will merge it.

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/