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

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] [day] [month] [year] [list]

Date:	Fri, 30 Mar 2007 22:11:20 +0300
From:	Anssi Hannula <anssi.hannula@...il.com>
To:	johann deneux <johann.deneux@...il.com>
CC:	Jiri Slaby <jirislaby@...il.com>,
	Dmitry Torokhov <dtor@...ightbb.com>,
	"STenyaK (Bruno González)" 
	<stenyak@...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]

johann deneux wrote:
> On 3/27/07, Jiri Slaby <jirislaby@...il.com> wrote:
> 
>> Ok, so how to deal with these devices? Does anybody have some idea?
>> That's
>> what I was talking about somewhere in the beginning of this thread,
>> the raw
>> values, because it seems too specific for letting kernel to cope with
>> each
>> of these devices separately, but there might be a better idea in
>> somebody's
>> head? But raw is ugly...
>>
> 
> What about adding a member to ff_effect which would be the number of the
> motor?
> We can't change the layout of ff_effect too much though, so we have to
> find unused bits and put them to work.

Actually, having thought more about this, I'm beginning to believe
Jiri's original FF_RAW approach could actually be a good option to add
3d effect support to the API. It would be similar to FF_CONSTANT but
instead of angle+magnitude the force is defined as s16 per every axis
(so it could actually be used with current drivers as well).

Alternatively we could define FF_3D_CONSTANT as an usual FF_CONSTANT
with an additional direction value, allowing a 3D force to be described
using 2x direction and magnitude.

Or we could define both ;)

Howewer, if I understood correctly that the 3 values the phantom device
takes are not really magnitudes along X, Y, Z, but some possibly
unaligned motors specific to this device, we cannot really abstract the
device motors into a 3D force effect. We could still add some FF_RAW
type, however, but with the values representing motors instead of axes,
with the exact function (direction) of each motor being left undefined
in the API (unlike the FF_RAW type I was talking a few paragraphs ago,
this type of course wouldn't be used at all by other drivers).

> Another possibility is to get rid of "trigger" and replace it by __u8
> motor and some padding, since that's I-Force specific (are there other
> drivers that implement that?). The goal of "trigger" is to start an
> effect when a button is pressed, which can be done from userland
> instead. It's not like we need micro-second latency when starting
> effects.

The generic PID driver implements that. I also think implementing the
support in software for the devices not supporting triggers in hw could
be quite easily done in ff-core.c or ff-memless.c.

(I also don't know what the triggers are useful for)

johann deneux also wrote in another message:
> The
> problem is to make an extension that does not duplicate the
> capabilities of the existing API. We don't want to have two ways of
> specifying the same effects.

How is this a problem?

-- 
Anssi Hannula

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