Executive summary: In order for effects to be played, the correct ff_effect structure will need to be present; if you can't play the effects it's better not to detect the joystick as FF, because it's really not. The structure is not used *yet*, but will be. There was an older version of force feedback code before (in some of the stock 2.4 kernels) which had some of the same features (such as the EV_FF bit), but has incompatible structures, and afaik there were never any force feedback drivers written for it. The newer interface has working iForce (logitech, guillemot, et al) and MS sidewinder drivers written for it, so that's the one I was targetting. You can see them side by side if you have linux/input.h from an unpatched late 2.4 kernel and a 2.6 kernel. E.g. from 2.4.29: struct ff_effect { __u16 type; __s16 id; struct ff_trigger trigger; struct ff_replay replay; union { struct ff_constant_effect constant; struct ff_periodic_effect periodic; struct ff_interactive_effect interactive; } u; }; and from 2.6.11: 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; }; Both versions have the same version define, but code for one will obviously not compile with the other. Testing for ff_effect.direction was the most direct way I could think of of differentiating the two. The code in FF #1 and #2 will theoretically work on either version, it's true...but detecting that a joystick has FF is not much use if you can't play any effects on it. --Daniel Remenak On 28 Jul 2005 12:56:19 +0200, Alexandre Julliard <julliard(a)winehq.org> wrote: