lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 21 Mar 2007 15:22:39 -0400
From:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
To:	"johann deneux" <johann.deneux@...il.com>
Cc:	"Jiri Slaby" <jirislaby@...il.com>,
	"STenyaK (Bruno González)" <stenyak@...il.com>,
	"Anssi Hannula" <anssi.hannula@...il.com>,
	"Linux kernel mailing list" <linux-kernel@...r.kernel.org>,
	linux-input@...ey.karlin.mff.cuni.cz
Subject: Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]

On 3/21/07, johann deneux <johann.deneux@...il.com> wrote:
> On 3/21/07, Jiri Slaby <jirislaby@...il.com> wrote:
> > STenyaK (Bruno González) napsal(a):
> > > On 3/14/07, Dmitry Torokhov <dmitry.torokhov@...il.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ