Messages in this thread | | | Date | Tue, 27 Mar 2007 23:34:51 +0200 | From | "johann deneux" <> | Subject | Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver] |
| |
On 3/27/07, Jiri Slaby <jirislaby@gmail.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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |