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

Date:	Tue, 27 Mar 2007 23:34:51 +0200
From:	"johann deneux" <johann.deneux@...il.com>
To:	"Jiri Slaby" <jirislaby@...il.com>
Cc:	"Dmitry Torokhov" <dtor@...ightbb.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/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.

For instance, we could replace

__u16 type;

by

__u8 motor;
__u8 type;

since 16 bits seems way more than needed for the effect type.

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.

As a reminder, here is the current definition of ff_effect:

struct ff_effect {
       __u16 type;
       __s16 id;
       __u16 direction;
       struct ff_trigger trigger;
       struct ff_replay replay;

       union {
               struct ff_constant_effect constant;
               struct ff_ramp_effect ramp;
               struct ff_periodic_effect periodic;
               struct ff_condition_effect condition[2]; /* One for each axis */
               struct ff_rumble_effect rumble;
       } u;
};

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