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 20:02:26 +0100
From:	"johann deneux" <johann.deneux@...il.com>
To:	"Jiri Slaby" <jirislaby@...il.com>
Cc:	"\"STenyaK (Bruno González)\"" <stenyak@...il.com>,
	"Dmitry Torokhov" <dmitry.torokhov@...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, 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.

For future devices with more than 3 FF-enabled axes, we can just do
the same, or develop a whole new API. There shouldn't be any worry.

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