input: Introduce ff-memless-next as an improved replacement for ff-memless

include/linux/input/ff-memless-next.h new file +28 -0

+
+/** DEFINITION OF TERMS
+ *
+ * Combined effect - An effect whose force is a superposition of forces
+ *                   generated by all effects that can be added together.
+ *                   Only one combined effect can be playing at a time.
+ *                   Effects that can be added together to create a combined
+ *                   effect are FF_CONSTANT, FF_PERIODIC and FF_RAMP.
+ * Uncombinable effect - An effect that cannot be combined with another effect.
+ *                       All conditional effects - FF_DAMPER, FF_FRICTION,
+ *                       FF_INERTIA and FF_SPRING are uncombinable.
+ *                       Number of uncombinable effects playing simultaneously
+ *                       depends on the capabilities of the hardware.
+ * Rumble effect - An effect generated by device's rumble motors instead of
+ *                 force feedback actuators.
+ *
+ *
+ * HANDLING OF UNCOMBINABLE EFFECTS
+ *
+ * Uncombinable effects cannot be combined together into just one effect, at
+ * least not in a clear and obvious manner. Therefore these effects have to
+ * be handled individually by ff-memless-next. Handling of these effects is
+ * left entirely to the hardware-specific driver, ff-memless-next merely
+ * passes these effects to the hardware-specific driver at appropriate time.
+ * ff-memless-next provides the UPLOAD command to notify the hardware-specific
+ * driver that the userspace is about to request playback of an uncombinable
+ * effect. The hardware-specific driver shall take all steps needed to make
+ * the device ready to play the effect when it receives the UPLOAD command.

+ * hardware-specific driver returns 0, the upload is considered successful.
+ * START_UNCOMB and STOP_UNCOMB commands cannot fail and the device must always
+ * start the playback of the requested effect if the UPLOAD command of the
+ * respective effect has been successful. ff-memless-next will never send
+ * a START/STOP_UNCOMB command for an effect that has not been uploaded
+ * successfully, nor will it send an ERASE command for an effect that is
+ * playing (= has been started with START_UNCOMB command).

+ */

include/linux/input/ff-memless-next.h new file +9 -0

+
+enum mlnx_commands {
+	/* Start or update a combined effect. This command is sent whenever
+	 * a FF_CONSTANT, FF_PERIODIC or FF_RAMP is started, stopped or
+	 * updated by userspace, when the applied envelopes are recalculated
+	 * or when periodic effects are recalculated. */
+	MLNX_START_COMBINED,
+	/* Stop combined effect. This command is sent when all combinable
+	 * effects are stopped. */

Quoted 39 lines · Michal Malý

include/linux/input/ff-memless-next.h new file +7 -0

+
+/** DEFINITION OF TERMS
+ *
+ * Combined effect - An effect whose force is a superposition of forces
+ *                   generated by all effects that can be added together.
+ *                   Only one combined effect can be playing at a time.
+ *                   Effects that can be added together to create a

combined + * effect are FF_CONSTANT, FF_PERIODIC and
FF_RAMP. + * Uncombinable effect - An effect that cannot be combined with
another effect. + * All conditional effects -
FF_DAMPER, FF_FRICTION, + * FF_INERTIA and
FF_SPRING are uncombinable. + * Number of
uncombinable effects playing simultaneously + *
depends on the capabilities of the hardware. + * Rumble effect - An effect generated by device's rumble motors instead of + * force feedback actuators.
+ *
+ *
+ * HANDLING OF UNCOMBINABLE EFFECTS
+ *
+ * Uncombinable effects cannot be combined together into just one effect, at + * least not in a clear and obvious manner. Therefore these effects have to + * be handled individually by ff-memless-next. Handling of these effects is + * left entirely to the hardware-specific driver, ff-memless-next merely + * passes these effects to the hardware-specific driver at appropriate time. + * ff-memless-next provides the UPLOAD command to notify the hardware-specific + * driver that the userspace is about to request playback of an uncombinable + * effect. The hardware-specific driver shall take all steps needed to make + * the device ready to play the effect when it receives the UPLOAD command. + * The actual playback shall commence when START_UNCOMB command is received.
+ * Opposite to the UPLOAD command is the ERASE command which tells + * the hardware-specific driver that the playback has finished and that + * the effect will not be restarted. STOP_UNCOMB command tells
+ * the hardware-specific driver that the playback shall stop but the device + * shall still be ready to resume the playback immediately.
+ *
+ * In case it is not possible to make the device ready to play an uncombinable + * effect (all hardware effect slots are occupied), the

Quoted 2 lines

hardware-specific + * driver may return an error when it receives an UPLOAD command. If the

This part concerns me. It seems to me that devices supporting "uncombinable" effects are in fact not memoryless devices and we should not be introducing this term here. If the goal is to work around limited number of effect slots in the devices by combining certain effects then it needs to be done at ff-core level as it will be potentially useful for all devices.

Quoted 23 lines

+ * hardware-specific driver returns 0, the upload is considered successful. + * START_UNCOMB and STOP_UNCOMB commands cannot fail and the device must always + * start the playback of the requested effect if the UPLOAD command of the + * respective effect has been successful. ff-memless-next will never send + * a START/STOP_UNCOMB command for an effect that has not been uploaded + * successfully, nor will it send an ERASE command for an effect that is + * playing (= has been started with START_UNCOMB command).

+ */

include/linux/input/ff-memless-next.h new file +13 -0

+
+enum mlnx_commands {
+	/* Start or update a combined effect. This command is sent whenever
+	 * a FF_CONSTANT, FF_PERIODIC or FF_RAMP is started, stopped or
+	 * updated by userspace, when the applied envelopes are recalculated
+	 * or when periodic effects are recalculated. */
+	MLNX_START_COMBINED,
+	/* Stop combined effect. This command is sent when all combinable
+	 * effects are stopped. */
+	MLNX_STOP_COMBINED,
+	/* Start or update a rumble effect. This command is sent whenever
+	 * a FF_RUMBLE effect is started or when its magnitudes or directions
+	 * change. */

include/linux/input/ff-memless-next.h line 66

Quoted 6 lines

include/linux/input/ff-memless-next.h new file +6 -0

+	MLNX_START_RUMBLE,
+	/* Stop a rumble effect. This command is sent when all FF_RUMBLE
+	 * effects are stopped. */
+	MLNX_STOP_RUMBLE,
+	/* Start or update an uncombinable effect. This command is sent
+	 * whenever an uncombinable effect is started or updated. */

Why do we have make a distinction between rumble and all other effects?

Hi Dmitry,

thank you for reviewing this.

Quoted 40 lines · On Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote:

Quoted 39 lines · Michal Malý

include/linux/input/ff-memless-next.h new file +7 -0

+
+/** DEFINITION OF TERMS
+ *
+ * Combined effect - An effect whose force is a superposition of forces
+ *                   generated by all effects that can be added together.
+ *                   Only one combined effect can be playing at a time.
+ *                   Effects that can be added together to create a

combined + * effect are FF_CONSTANT, FF_PERIODIC and
FF_RAMP. + * Uncombinable effect - An effect that cannot be combined with
another effect. + * All conditional effects -
FF_DAMPER, FF_FRICTION, + * FF_INERTIA and
FF_SPRING are uncombinable. + * Number of
uncombinable effects playing simultaneously + *
depends on the capabilities of the hardware. + * Rumble effect - An effect generated by device's rumble motors instead of + * force feedback actuators.
+ *
+ *
+ * HANDLING OF UNCOMBINABLE EFFECTS
+ *
+ * Uncombinable effects cannot be combined together into just one effect, at + * least not in a clear and obvious manner. Therefore these effects have to + * be handled individually by ff-memless-next. Handling of these effects is + * left entirely to the hardware-specific driver, ff-memless-next merely + * passes these effects to the hardware-specific driver at appropriate time. + * ff-memless-next provides the UPLOAD command to notify the hardware-specific + * driver that the userspace is about to request playback of an uncombinable + * effect. The hardware-specific driver shall take all steps needed to make + * the device ready to play the effect when it receives the UPLOAD command. + * The actual playback shall commence when START_UNCOMB command is received.
+ * Opposite to the UPLOAD command is the ERASE command which tells + * the hardware-specific driver that the playback has finished and that + * the effect will not be restarted. STOP_UNCOMB command tells
+ * the hardware-specific driver that the playback shall stop but the device + * shall still be ready to resume the playback immediately.
+ *
+ * In case it is not possible to make the device ready to play an uncombinable + * effect (all hardware effect slots are occupied), the

Quoted 8 lines

Quoted 2 lines

hardware-specific + * driver may return an error when it receives an UPLOAD command. If the

This part concerns me. It seems to me that devices supporting "uncombinable" effects are in fact not memoryless devices and we should not be introducing this term here. If the goal is to work around limited number of effect slots in the devices by combining certain effects then it needs to be done at ff-core level as it will be potentially useful for all devices.

Force generated by a conditional effect (referred to as "uncombinable" within ff-memless-next to make the distinction clear) depends on a position of the device. For instance the more a device is deflected from a neutral position the greater force FF_SPRING generates. A truly memoryless device would have to report its position to the driver, have it calculate the appropriate force and send it back to the device. IMHO such a loop would require a very high USB polling rate to play conditional effects with acceptable quality.

We know for a fact that at least many (all?) Logitech devices that support conditional effects use this "semi-memoryless" approach where FF_CONSTANT and FF_PERIODIC are handled in the memoryless fashion and conditional effects are uploaded to the device (in a somewhat simplified form). The amount of effects that can be uploaded to a device is limited which is why ff-memless-next uses two steps (UPLOAD/ERASE and START/STOP) to handle these effects.

Conditional effects - even if they are of the same type - cannot be effectively combined into one because superposition doesn't seem to work here so they have to be processed one by one.

If we ever come across a really memoryless device it should not be particularly difficult to add another callback to ff-memless-next which would emulate conditional effects with constant force.

If we ever come across a really memoryless device it should not be particularly difficult to add another callback to ff-memless-next which would emulate conditional effects with constant force.

Quoted 4 lines

If we ever come across a really memoryless device it should not be particularly difficult to add another callback to ff-memless-next which would emulate conditional effects with constant force.

It should be noted that some (/many?) applications/games already use the CF with position feedback to emulate behaviour such as springs. The feed back loop is simply not fast enough to do emulation of friction/inertia.

I don't believe that the FF layer in the kernel should be 'tricked out' with lots of emulation features.

As a game designer (ok... tinkerer) it's a bit of a pain that devices lie about what they can really do - ie. gamepads claiming periodic ability when all they are doing is faking it with rumble.

Hi Dmitry,

thank you for reviewing this.

Quoted 40 lines · On Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote:

Quoted 39 lines · Michal Malý

include/linux/input/ff-memless-next.h new file +7 -0

+
+/** DEFINITION OF TERMS
+ *
+ * Combined effect - An effect whose force is a superposition of forces
+ *                   generated by all effects that can be added together.
+ *                   Only one combined effect can be playing at a time.
+ *                   Effects that can be added together to create a

combined + * effect are FF_CONSTANT, FF_PERIODIC and
FF_RAMP. + * Uncombinable effect - An effect that cannot be combined with
another effect. + * All conditional effects -
FF_DAMPER, FF_FRICTION, + * FF_INERTIA and
FF_SPRING are uncombinable. + * Number of
uncombinable effects playing simultaneously + *
depends on the capabilities of the hardware. + * Rumble effect - An effect generated by device's rumble motors instead of + * force feedback actuators.
+ *
+ *
+ * HANDLING OF UNCOMBINABLE EFFECTS
+ *
+ * Uncombinable effects cannot be combined together into just one effect, at + * least not in a clear and obvious manner. Therefore these effects have to + * be handled individually by ff-memless-next. Handling of these effects is + * left entirely to the hardware-specific driver, ff-memless-next merely + * passes these effects to the hardware-specific driver at appropriate time. + * ff-memless-next provides the UPLOAD command to notify the hardware-specific + * driver that the userspace is about to request playback of an uncombinable + * effect. The hardware-specific driver shall take all steps needed to make + * the device ready to play the effect when it receives the UPLOAD command. + * The actual playback shall commence when START_UNCOMB command is received.
+ * Opposite to the UPLOAD command is the ERASE command which tells + * the hardware-specific driver that the playback has finished and that + * the effect will not be restarted. STOP_UNCOMB command tells
+ * the hardware-specific driver that the playback shall stop but the device + * shall still be ready to resume the playback immediately.
+ *
+ * In case it is not possible to make the device ready to play an uncombinable + * effect (all hardware effect slots are occupied), the

Quoted 8 lines

Quoted 2 lines

hardware-specific + * driver may return an error when it receives an UPLOAD command. If the

This part concerns me. It seems to me that devices supporting "uncombinable" effects are in fact not memoryless devices and we should not be introducing this term here. If the goal is to work around limited number of effect slots in the devices by combining certain effects then it needs to be done at ff-core level as it will be potentially useful for all devices.

Force generated by a conditional effect (referred to as "uncombinable" within ff-memless-next to make the distinction clear) depends on a position of the device. For instance the more a device is deflected from a neutral position the greater force FF_SPRING generates. A truly memoryless device would have to report its position to the driver, have it calculate the appropriate force and send it back to the device. IMHO such a loop would require a very high USB polling rate to play conditional effects with acceptable quality.

We know for a fact that at least many (all?) Logitech devices that support conditional effects use this "semi-memoryless" approach where FF_CONSTANT and FF_PERIODIC are handled in the memoryless fashion and conditional effects are uploaded to the device (in a somewhat simplified form). The amount of effects that can be uploaded to a device is limited which is why ff-memless-next uses two steps (UPLOAD/ERASE and START/STOP) to handle these effects.

Conditional effects - even if they are of the same type - cannot be effectively combined into one because superposition doesn't seem to work here so they have to be processed one by one.

If we ever come across a really memoryless device it should not be particularly difficult to add another callback to ff-memless-next which would emulate conditional effects with constant force.

Quoted 85 lines · Michal Malý

Hi Dmitry,

thank you for reviewing this.

Quoted 54 lines · On Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote:

Quoted 53 lines · Michal Malý

include/linux/input/ff-memless-next.h new file +4 -0

+
+/** DEFINITION OF TERMS
+ *
+ * Combined effect - An effect whose force is a superposition of

forces
+ * generated by all effects that can be added
together.
+ * Only one combined effect can be playing at a
time.
+ * Effects that can be added together to create a
combined + * effect are FF_CONSTANT, FF_PERIODIC and
FF_RAMP. + * Uncombinable effect - An effect that cannot be combined with
another effect. + * All conditional effects -
FF_DAMPER, FF_FRICTION, + * FF_INERTIA and
FF_SPRING are uncombinable. + * Number of
uncombinable effects playing simultaneously + *
depends on the capabilities of the hardware. + * Rumble effect - An effect generated by device's rumble motors instead of + * force feedback actuators.
+ *
+ *
+ * HANDLING OF UNCOMBINABLE EFFECTS
+ *
+ * Uncombinable effects cannot be combined together into just one effect,
at + * least not in a clear and obvious manner. Therefore these effects
have to + * be handled individually by ff-memless-next. Handling of these
effects is + * left entirely to the hardware-specific driver, ff-memless-next merely + * passes these effects to the hardware-specific
driver at appropriate time. + * ff-memless-next provides the UPLOAD command to notify the hardware-specific + * driver that the userspace is
about to request playback of an uncombinable + * effect. The hardware-specific driver shall take all steps needed to make + * the device ready to play the effect when it receives the UPLOAD command. + *
The actual playback shall commence when START_UNCOMB command is received.
+ * Opposite to the UPLOAD command is the ERASE command which tells + *
the hardware-specific driver that the playback has finished and that + *
the effect will not be restarted. STOP_UNCOMB command tells
+ * the hardware-specific driver that the playback shall stop but the device + * shall still be ready to resume the playback immediately.
+ *
+ * In case it is not possible to make the device ready to play an uncombinable + * effect (all hardware effect slots are occupied), the hardware-specific + * driver may return an error when it receives an

Quoted 8 lines

Quoted 1 line

UPLOAD command. If the

This part concerns me. It seems to me that devices supporting "uncombinable" effects are in fact not memoryless devices and we should not be introducing this term here. If the goal is to work around limited number of effect slots in the devices by combining certain effects then it needs to be done at ff-core level as it will be potentially useful for all devices.

Force generated by a conditional effect (referred to as "uncombinable" within ff-memless-next to make the distinction clear) depends on a position of the device. For instance the more a device is deflected from a neutral position the greater force FF_SPRING generates. A truly memoryless device would have to report its position to the driver, have it calculate the appropriate force and send it back to the device. IMHO such a loop would require a very high USB polling rate to play conditional effects with acceptable quality.

We know for a fact that at least many (all?) Logitech devices that support conditional effects use this "semi-memoryless" approach where FF_CONSTANT and FF_PERIODIC are handled in the memoryless fashion and conditional effects are uploaded to the device (in a somewhat simplified form). The amount of effects that can be uploaded to a device is limited which is why ff-memless-next uses two steps (UPLOAD/ERASE and START/STOP) to handle these effects.

Quoted 7 lines

Conditional effects - even if they are of the same type - cannot be effectively combined into one because superposition doesn't seem to work here so they have to be processed one by one.

If we ever come across a really memoryless device it should not be particularly difficult to add another callback to ff-memless-next which would emulate conditional effects with constant force.

Thank you for the explanation. This further solidifies for me the idea that handling of such effects that are in fact uploaded to and managed by the device should not be handled by the memoryless core but rather by the driver itself. I.e. such drivers should implement their own play(), upload(), erase(), etc, and decide whether to use a hardware slot for the effect or handle effect in memoryless fashion (if possible). We can open ff-memless to allow such drivers to use parts of memoryless handling.

Quoted 85 lines · Michal Malý

Hi Dmitry,

thank you for reviewing this.

Quoted 54 lines · On Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote:

Quoted 53 lines · Michal Malý

include/linux/input/ff-memless-next.h new file +4 -0

+
+/** DEFINITION OF TERMS
+ *
+ * Combined effect - An effect whose force is a superposition of

forces
+ * generated by all effects that can be added
together.
+ * Only one combined effect can be playing at a
time.
+ * Effects that can be added together to create a
combined + * effect are FF_CONSTANT, FF_PERIODIC and
FF_RAMP. + * Uncombinable effect - An effect that cannot be combined with
another effect. + * All conditional effects -
FF_DAMPER, FF_FRICTION, + * FF_INERTIA and
FF_SPRING are uncombinable. + * Number of
uncombinable effects playing simultaneously + *
depends on the capabilities of the hardware. + * Rumble effect - An effect generated by device's rumble motors instead of + * force feedback actuators.
+ *
+ *
+ * HANDLING OF UNCOMBINABLE EFFECTS
+ *
+ * Uncombinable effects cannot be combined together into just one effect,
at + * least not in a clear and obvious manner. Therefore these effects
have to + * be handled individually by ff-memless-next. Handling of these
effects is + * left entirely to the hardware-specific driver, ff-memless-next merely + * passes these effects to the hardware-specific
driver at appropriate time. + * ff-memless-next provides the UPLOAD command to notify the hardware-specific + * driver that the userspace is
about to request playback of an uncombinable + * effect. The hardware-specific driver shall take all steps needed to make + * the device ready to play the effect when it receives the UPLOAD command. + *
The actual playback shall commence when START_UNCOMB command is received.
+ * Opposite to the UPLOAD command is the ERASE command which tells + *
the hardware-specific driver that the playback has finished and that + *
the effect will not be restarted. STOP_UNCOMB command tells
+ * the hardware-specific driver that the playback shall stop but the device + * shall still be ready to resume the playback immediately.
+ *
+ * In case it is not possible to make the device ready to play an uncombinable + * effect (all hardware effect slots are occupied), the hardware-specific + * driver may return an error when it receives an

Quoted 8 lines

Quoted 1 line

UPLOAD command. If the

This part concerns me. It seems to me that devices supporting "uncombinable" effects are in fact not memoryless devices and we should not be introducing this term here. If the goal is to work around limited number of effect slots in the devices by combining certain effects then it needs to be done at ff-core level as it will be potentially useful for all devices.

Force generated by a conditional effect (referred to as "uncombinable" within ff-memless-next to make the distinction clear) depends on a position of the device. For instance the more a device is deflected from a neutral position the greater force FF_SPRING generates. A truly memoryless device would have to report its position to the driver, have it calculate the appropriate force and send it back to the device. IMHO such a loop would require a very high USB polling rate to play conditional effects with acceptable quality.

We know for a fact that at least many (all?) Logitech devices that support conditional effects use this "semi-memoryless" approach where FF_CONSTANT and FF_PERIODIC are handled in the memoryless fashion and conditional effects are uploaded to the device (in a somewhat simplified form). The amount of effects that can be uploaded to a device is limited which is why ff-memless-next uses two steps (UPLOAD/ERASE and START/STOP) to handle these effects.

Quoted 7 lines

Conditional effects - even if they are of the same type - cannot be effectively combined into one because superposition doesn't seem to work here so they have to be processed one by one.

If we ever come across a really memoryless device it should not be particularly difficult to add another callback to ff-memless-next which would emulate conditional effects with constant force.

Thank you for the explanation. This further solidifies for me the idea that handling of such effects that are in fact uploaded to and managed by the device should not be handled by the memoryless core but rather by the driver itself. I.e. such drivers should implement their own play(), upload(), erase(), etc, and decide whether to use a hardware slot for the effect or handle effect in memoryless fashion (if possible). We can open ff-memless to allow such drivers to use parts of memoryless handling.

Thanks.

Quoted 103 lines · On Wednesday 14 of May 2014 11:05:58 Dmitry Torokhov wrote:

Quoted 85 lines · Michal Malý

Hi Dmitry,

thank you for reviewing this.

Quoted 54 lines · On Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote:

Quoted 53 lines · Michal Malý

include/linux/input/ff-memless-next.h new file +4 -0

+
+/** DEFINITION OF TERMS
+ *
+ * Combined effect - An effect whose force is a superposition of

forces
+ * generated by all effects that can be added
together.
+ * Only one combined effect can be playing at a
time.
+ * Effects that can be added together to create a
combined + * effect are FF_CONSTANT, FF_PERIODIC and
FF_RAMP. + * Uncombinable effect - An effect that cannot be combined with
another effect. + * All conditional effects -
FF_DAMPER, FF_FRICTION, + * FF_INERTIA and
FF_SPRING are uncombinable. + * Number of
uncombinable effects playing simultaneously + *
depends on the capabilities of the hardware. + * Rumble effect - An effect generated by device's rumble motors instead of + * force feedback actuators.
+ *
+ *
+ * HANDLING OF UNCOMBINABLE EFFECTS
+ *
+ * Uncombinable effects cannot be combined together into just one effect,
at + * least not in a clear and obvious manner. Therefore these effects
have to + * be handled individually by ff-memless-next. Handling of these
effects is + * left entirely to the hardware-specific driver, ff-memless-next merely + * passes these effects to the hardware-specific
driver at appropriate time. + * ff-memless-next provides the UPLOAD command to notify the hardware-specific + * driver that the userspace is
about to request playback of an uncombinable + * effect. The hardware-specific driver shall take all steps needed to make + * the device ready to play the effect when it receives the UPLOAD command. + *
The actual playback shall commence when START_UNCOMB command is received.
+ * Opposite to the UPLOAD command is the ERASE command which tells + *
the hardware-specific driver that the playback has finished and that + *
the effect will not be restarted. STOP_UNCOMB command tells
+ * the hardware-specific driver that the playback shall stop but the device + * shall still be ready to resume the playback immediately.
+ *
+ * In case it is not possible to make the device ready to play an uncombinable + * effect (all hardware effect slots are occupied), the hardware-specific + * driver may return an error when it receives an

Quoted 8 lines

Quoted 1 line

UPLOAD command. If the

This part concerns me. It seems to me that devices supporting "uncombinable" effects are in fact not memoryless devices and we should not be introducing this term here. If the goal is to work around limited number of effect slots in the devices by combining certain effects then it needs to be done at ff-core level as it will be potentially useful for all devices.

Force generated by a conditional effect (referred to as "uncombinable" within ff-memless-next to make the distinction clear) depends on a position of the device. For instance the more a device is deflected from a neutral position the greater force FF_SPRING generates. A truly memoryless device would have to report its position to the driver, have it calculate the appropriate force and send it back to the device. IMHO such a loop would require a very high USB polling rate to play conditional effects with acceptable quality.

We know for a fact that at least many (all?) Logitech devices that support conditional effects use this "semi-memoryless" approach where FF_CONSTANT and FF_PERIODIC are handled in the memoryless fashion and conditional effects are uploaded to the device (in a somewhat simplified form). The amount of effects that can be uploaded to a device is limited which is why ff-memless-next uses two steps (UPLOAD/ERASE and START/STOP) to handle these effects.

Quoted 7 lines

Conditional effects - even if they are of the same type - cannot be effectively combined into one because superposition doesn't seem to work here so they have to be processed one by one.

If we ever come across a really memoryless device it should not be particularly difficult to add another callback to ff-memless-next which would emulate conditional effects with constant force.

Thank you for the explanation. This further solidifies for me the idea that handling of such effects that are in fact uploaded to and managed by the device should not be handled by the memoryless core but rather by the driver itself. I.e. such drivers should implement their own play(), upload(), erase(), etc, and decide whether to use a hardware slot for the effect or handle effect in memoryless fashion (if possible). We can open ff-memless to allow such drivers to use parts of memoryless handling.

Quoted 1 line

Thanks.

To bring this to a conclusion we could go from, would this be an acceptable solution?

- Have the HW-specific driver talk directly to ff-core and reimplement upload(), play(), etc.
- Rewrite "ff-memless-next" so that it is not a self-contained module but a library of functions.
- Have the driver either:
- Upload an effect to a device directly if the device can fully manage the
effect by itself.
- Use provided timing functions to know when an effect should start, stop,
restart etc...
- Use provided timing AND processing functions to combine effects that can be
combined into one, calculate periodic waveforms etc?

I have no problem with throwing my current approach away but before I start working on a new one I'd like to know which way to go...

Thanks,
Michal

Quoted 134 lines · Michal Malý

Quoted 106 lines · On Wednesday 14 of May 2014 11:05:58 Dmitry Torokhov wrote:

Quoted 88 lines · Michal Malý

Hi Dmitry,

thank you for reviewing this.

Quoted 56 lines · On Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote:

Quoted 46 lines · Michal Malý

include/linux/input/ff-memless-next.h new file +4 -0

+
+/** DEFINITION OF TERMS
+ *
+ * Combined effect - An effect whose force is a superposition of

forces
+ * generated by all effects that can be added
together.
+ * Only one combined effect can be playing at a
time.
+ * Effects that can be added together to create a
combined + * effect are FF_CONSTANT, FF_PERIODIC and
FF_RAMP. + * Uncombinable effect - An effect that cannot be combined with
another effect. + * All conditional effects -
FF_DAMPER, FF_FRICTION, + * FF_INERTIA and
FF_SPRING are uncombinable. + * Number of
uncombinable effects playing simultaneously + *
depends on the capabilities of the hardware. + * Rumble effect - An effect generated by device's rumble motors instead of + * force feedback actuators.
+ *
+ *
+ * HANDLING OF UNCOMBINABLE EFFECTS
+ *
+ * Uncombinable effects cannot be combined together into just one effect,
at + * least not in a clear and obvious manner. Therefore these effects
have to + * be handled individually by ff-memless-next. Handling of these
effects is + * left entirely to the hardware-specific driver, ff-memless-next merely + * passes these effects to the hardware-specific
driver at appropriate time. + * ff-memless-next provides the UPLOAD command to notify the hardware-specific + * driver that the userspace is
about to request playback of an uncombinable + * effect. The hardware-specific driver shall take all steps needed to make + * the device ready to play the effect when it receives the UPLOAD command. + *
The actual playback shall commence when START_UNCOMB command is received.
+ * Opposite to the UPLOAD command is the ERASE command which tells + *
the hardware-specific driver that the playback has finished and that + *

Quoted 8 lines

the effect will not be restarted. STOP_UNCOMB command tells
+ * the hardware-specific driver that the playback shall stop but the device + * shall still be ready to resume the playback immediately.
+ *
+ * In case it is not possible to make the device ready to play an uncombinable + * effect (all hardware effect slots are occupied), the hardware-specific + * driver may return an error when it receives an UPLOAD command. If the

Quoted 7 lines

This part concerns me. It seems to me that devices supporting "uncombinable" effects are in fact not memoryless devices and we should not be introducing this term here. If the goal is to work around limited
number of effect slots in the devices by combining certain effects then it needs to be done at ff-core level as it will be potentially useful for all devices.

Force generated by a conditional effect (referred to as "uncombinable" within ff-memless-next to make the distinction clear) depends on a position of the device. For instance the more a device is deflected from a neutral position the greater force FF_SPRING generates. A truly memoryless device would have to report its position to the driver, have it calculate the appropriate force and send it back to the device. IMHO such a loop would require a very high USB polling rate to play conditional effects with acceptable quality.

We know for a fact that at least many (all?) Logitech devices that support
conditional effects use this "semi-memoryless" approach where FF_CONSTANT
and FF_PERIODIC are handled in the memoryless fashion and conditional effects are uploaded to the device (in a somewhat simplified form). The amount of effects that can be uploaded to a device is limited which is why ff-memless-next uses two steps (UPLOAD/ERASE and START/STOP) to handle these effects.

Quoted 7 lines

Conditional effects - even if they are of the same type - cannot be effectively combined into one because superposition doesn't seem to work here so they have to be processed one by one.

If we ever come across a really memoryless device it should not be particularly difficult to add another callback to ff-memless-next which would emulate conditional effects with constant force.

Thank you for the explanation. This further solidifies for me the idea that handling of such effects that are in fact uploaded to and managed by the device should not be handled by the memoryless core but rather by the driver itself. I.e. such drivers should implement their own play(), upload(), erase(), etc, and decide whether to use a hardware slot for the effect or handle effect in memoryless fashion (if possible). We can open ff-memless to allow such drivers to use parts of memoryless handling.

Quoted 1 line

Thanks.

To bring this to a conclusion we could go from, would this be an acceptable
solution?

- Have the HW-specific driver talk directly to ff-core and reimplement upload(), play(), etc.
- Rewrite "ff-memless-next" so that it is not a self-contained module but a
library of functions.

- Have the driver either:
- Upload an effect to a device directly if the device can fully manage the

effect by itself.

- Use provided timing functions to know when an effect should start, stop,

restart etc...

- Use provided timing AND processing functions to combine effects that can be>
combined into one, calculate periodic waveforms etc?

Quoted 6 lines

I have no problem with throwing my current approach away but before I start
working on a new one I'd like to know which way to go...

Thanks,
Michal

Hi everyone

Allow me to introduce myself. I'm Roland Bosa and I work for Logitech, more specifically the gaming group. I have been tasked to look into gaming device support for Linux and I just started following this list and studying the kernel code related to the Logitech Force Feedback devices. The 'ff-memless-next' module sounds tailor-made for our devices. Please let me know how I can help with its development.

Hi,

"ff-memless-next" was designed with behavior of Logitech devices in mind, however it was always meant as a general replacement for the current "ff- memless". After some followup discussion it's unlikely that it will be mainlined in its current form. See the discussion here "http://www.spinics.net/lists/linux-input/msg31426.html" for more details.

We would however really appreciate some information regarding Logitech devices specifically. Although we have reverse engineered most of things, I believe there are still areas we're not entirely clear about. I realize that you'd probably have to take it up with the legal deparment but if someone at Logitech could at least take a look at what we've found so far at fill in the blanks it'd be most helpful.

Please note that we found numerous bugs and DirectInput specs violations in the Windows driver which might have impacted our understading of how the driver works. "ff-memless-next" and "lg4ff" tries to fix or work around these. A link to out-of-tree update to lg4ff which takes full advantage of "ff-memless- next" is also provided in this thread.

On 05/20/2014 12:00 PM, Michal Malı wrote:
There's a healthy amount of
code in the Windows driver that you would call 'quirks' which deals with deciding how to allocate multiple springs and dampers to a single slot.

Sometimes, even the springs and dampers are being streamed in via the constants force, but that requires (as you pointed out earlier) a fast update rate and some "smartness"

Quoted 4 lines

But 2 Spring effects with different offsets and non-zero effective force can't be combined into a single slot (without streaming them with Constant force), right?

Yes - you cannot *download* two springs to a single slot. You need to choose (allocate) one of them. The winner gets the slot. The losers go somewhere else (they might get discarded, they might get simulated).

Allow me to introduce myself. I'm Roland Bosa and I work for Logitech, more specifically the gaming group. I have been tasked to look into gaming device support for Linux and I just started following this list and studying the kernel code related to the Logitech Force Feedback devices. The 'ff-memless-next' module sounds tailor-made for our devices. Please let me know how I can help with its development.

hopefully bring Linux into scope for force-feedback of AAA game quality.

Mostly this has come from a small group of people reverse engineering the Logitech wheels, which leads to the 'tailor-made' situation. But we'd like the systems/interfaces to be device agnostic.

As you how you can help...? As Michal said having a contact at Logitech to whom we can ask technical questions (off list) would probably be the greatest help. This would clear up any assumptions we have made, and help with decisions going forward.

It may also be the case that Logitech is working with studios/game designers to improve controller performance. If any information can be feed 'forward' to improve the Linux driver, that would be useful too.

IMO, there are two types of games. The "arcade" ones, which have a set of 'canned' force effects, which play whenever an event happens in game. And the "simulation" ones, which base the game on a physics engine. The latter can redirect some variables of their engine to the input layer and typically drive a constant force and maybe a spring/damper too.

For the first type, you might want to keep a centering spring active all the time. Maybe you want to tweak the gain in the game settings. Maybe there's a gain for the centering and one for the special effects. The canned effects are mostly periodics with varying waveform, duration, amplitude and envelope. That's about it.

For the second type, you don't want a centering spring. You typically will drive a constant force effect with the engine, with some sprinkled damping and maybe a slight spring here and there.

I would personally put more weight and effort to get the second type properly implemented. The players of those games demand more realism and they need the subtle force changes to drive better than the competition.

That means having a FF driver that can deal with many force updates per second without choking and a consistent, reproducible force output at the device, maybe even similar across varying devices. This translates into a decoupled design for accepting force updates and sending USB updates, as well as a device-specific layer to "calibrate" and "unify" the force responses across different models.

Sounds like these are the effect files produced by FEdit tool (from MS DirectX SDK), and/or played back by pressing buttons when configuring the Logitech driver on Windows ('wooden bridge', etc)...

Do you know if there is a mechanism for playing these under Linux?

Under Windows do games just send a 'file' the DirectX driver, or do they parse them into individual effects to send?

If format is known/public it shouldn't be hard to write a userland client to play them back.

I assume that most AAA games, would implement these through some middle layer. I think that is probably via Steam using SDL2 haptic API, we have been testing against SDL2's 'testhaptic'.

Do you see another path (which we should be supporting/testing)?

There was some discussion about rate limiting the USB packets to the wheel, and how to deal if app updates too quickly. Is there an upper limit for the wheel itself, or is it just the USB 'pipe' which is the limiting factor?

The file format of an IFR is probably easily deducible. There's a lot of textual clues to parameters and the values are also written out in string form.

I don't have a FEdit file at hand, but I suppose it will be similar.

Quoted 3 lines

I assume that most AAA games, would implement these through some middle layer. I think that is probably via Steam using SDL2 haptic API, we have been testing against SDL2's 'testhaptic'.

I wasn't aware of this layer. I must read up on it. It sounds like a simple way to access force feedback - I guess a game developer should shed some light on this...

Quoted 1 line

Do you see another path (which we should be supporting/testing)?

Nope, not at this time.

Quoted 4 lines

There was some discussion about rate limiting the USB packets to the wheel, and how to deal if app updates too quickly. Is there an upper limit for the wheel itself, or is it just the USB 'pipe' which is the limiting factor?

On the Windows side we send 125 reports/sec. The entire simulation loop runs with a 8ms resolution. I assume this value was chosen for some hardware constraints back in the days, but it has proven to be a good compromise for simulated periodics and physics constraints.

In any case, the USB traffic should be decoupled from the app. Any force updates should only change state in the ff-memless[-next] driver. Any change there should trickle down to a 'slot' representation of the device. If there's any change in the slots, the device is marked as 'dirty' and USB transfers are scheduled to send the latest state to the physical device.

The scheduling should keep track of how many requests are in-flight and delay writing the next output, until the previous one has completed.

Question back to the community: are there APIs in the USB layer to check for presence of in-progress requests? Can one add a 'completion' callback to a request, that gets invoked on completion/cancellation?

Quoted 6 lines · On Tuesday 20 of May 2014 18:17:51 Roland Bosa wrote:

The file format of an IFR is probably easily deducible. There's a lot of textual clues to parameters and the values are also written out in string form.

I don't have a FEdit file at hand, but I suppose it will be similar.

I believe that Elias successfully reverse engineered the effect file format produced by FEdit. There is no support for this kind of prefabricated effects in the Linux FF API.

Quoted 18 lines

Quoted 3 lines

I assume that most AAA games, would implement these through some middle layer. I think that is probably via Steam using SDL2 haptic API, we have been testing against SDL2's 'testhaptic'.

I wasn't aware of this layer. I must read up on it. It sounds like a simple way to access force feedback - I guess a game developer should shed some light on this...

Quoted 1 line

Do you see another path (which we should be supporting/testing)?

Nope, not at this time.

Quoted 4 lines

There was some discussion about rate limiting the USB packets to the wheel, and how to deal if app updates too quickly. Is there an upper limit for the wheel itself, or is it just the USB 'pipe' which is the limiting factor?

Quoted 4 lines

On the Windows side we send 125 reports/sec. The entire simulation loop runs with a 8ms resolution. I assume this value was chosen for some hardware constraints back in the days, but it has proven to be a good compromise for simulated periodics and physics constraints.

Our current code uses 8 msecs delay as well.

Quoted 9 lines

In any case, the USB traffic should be decoupled from the app. Any force updates should only change state in the ff-memless[-next] driver. Any change there should trickle down to a 'slot' representation of the device. If there's any change in the slots, the device is marked as 'dirty' and USB transfers are scheduled to send the latest state to the physical device.

The scheduling should keep track of how many requests are in-flight and delay writing the next output, until the previous one has completed.

The approach I had in mind would keep track of the last effect that made it to the device and the last effect that arrived from userspace. This would be stored for each effect slot. An update would be scheduled at the desired update rate. The updating routine would figure out the state change between last update and "now", send the required data to the device and reschedule itself. The routine could check if there are any USB transfers still running and reschedule itself immediately.

Quoted 3 lines

Question back to the community: are there APIs in the USB layer to check for presence of in-progress requests? Can one add a 'completion' callback to a request, that gets invoked on completion/cancellation?

For instance "usb_submit_urb()" can have a completion handler that is called once the transfer is done. The current code uses "hid_hw_request()" which is asynchronous and doesn't report anything back.

Proper decoupling of the userspace and driver is the only important thing that is missing from the current code.

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Elias, Simon, Michal,

It is unfortunate that we didn't get back to you in 2013 when you asked for help in reverse engineering, oftentimes we have conflicting priorities and a particular request may be left laying around for some time before being addressed. But please, don't hesitate to re-kick us if you feel we are not being reactive.

Let me clearly say that our intentions are to disclose as much information as possible and to help the community in having great support to all our hardware across all platforms. We have zero problem with being asked for information.

Quoted 9 lines · On Tuesday 20 of May 2014 18:17:51 Roland Bosa wrote:

In any case, the USB traffic should be decoupled from the app. Any force updates should only change state in the ff-memless[-next] driver. Any change there should trickle down to a 'slot' representation of the device. If there's any change in the slots, the device is marked as 'dirty' and USB transfers are scheduled to send the latest state to the physical device.

The scheduling should keep track of how many requests are in-flight and delay writing the next output, until the previous one has completed.

The approach I had in mind would keep track of the last effect that made it to the device and the last effect that arrived from userspace. This would be stored for each effect slot. An update would be scheduled at the desired update rate. The updating routine would figure out the state change between last update and "now", send the required data to the device and reschedule itself. The routine could check if there are any USB transfers still running and reschedule itself immediately.

Quoted 3 lines

Question back to the community: are there APIs in the USB layer to check for presence of in-progress requests? Can one add a 'completion' callback to a request, that gets invoked on completion/cancellation?

For instance "usb_submit_urb()" can have a completion handler that is called once the transfer is done. The current code uses "hid_hw_request()" which is asynchronous and doesn't report anything back.

Proper decoupling of the userspace and driver is the only important thing that is missing from the current code.

Quoted 2 lines · Michal Malý

Proper decoupling of the userspace and driver is the only important thing that is missing from the current code.

Also dynamic updating of periodic effects is not yet supported in "ff-memless-next".
This can also be important in simulation games (=second type), e.g. the "rFactor" game.

Quoted 6 lines · On Tuesday 20 of May 2014 18:17:51 Roland Bosa wrote:

The file format of an IFR is probably easily deducible. There's a lot of textual clues to parameters and the values are also written out in string form.

I don't have a FEdit file at hand, but I suppose it will be similar.

I believe that Elias successfully reverse engineered the effect file format produced by FEdit. There is no support for this kind of prefabricated effects in the Linux FF API.

To bring this to a conclusion we could go from, would this be an acceptable
solution?

- Have the HW-specific driver talk directly to ff-core and reimplement upload(),
play(), etc.
- Rewrite "ff-memless-next" so that it is not a self-contained module but a
library of functions.
- Have the driver either:
- Upload an effect to a device directly if the device can fully manage
the
effect by itself.
- Use provided timing functions to know when an effect should start,
stop,
restart etc...
- Use provided timing AND processing functions to combine effects that
can be
combined into one, calculate periodic waveforms etc?

I have no problem with throwing my current approach away but before I start working on a new one I'd like to know which way to go...

Quoted 27 lines

To bring this to a conclusion we could go from, would this be an acceptable
solution?

- Have the HW-specific driver talk directly to ff-core and reimplement upload(),
play(), etc.
- Rewrite "ff-memless-next" so that it is not a self-contained module but a
library of functions.

- Have the driver either:
- Upload an effect to a device directly if the device can fully manage

the
effect by itself.

- Use provided timing functions to know when an effect should start,

stop,
restart etc...

- Use provided timing AND processing functions to combine effects that

can be
combined into one, calculate periodic waveforms etc?

Quoted 2 lines

I have no problem with throwing my current approach away but before I start working on a new one I'd like to know which way to go...

Hi all,
If the driver itself (hid-logitech, via hid-lg4ff for example) is more involved in the creation/timing/management of the effects, does this mean that we end up with code duplicated in lots of places?

Also, does this mean that the 'old' ff-memless system would remain in kernel? If not, who will reworking each driver?

Regarding the question of emulated vs. real effects, can we extend the API so that applications can know which effects are really supported, and enable/disable emulation somehow?

Quoted 3 lines · On Tuesday 20 of May 2014 16:16:12 [email protected] wrote:

Regarding the question of emulated vs. real effects, can we extend the API so that applications can know which effects are really supported, and enable/disable emulation somehow?

I suppose that a few extra flags (FF_PERIODIC_EMULATED etc.) defined in "uapi/linux/input.h" should suffice.

Quoted 7 lines · Michal Malý

Quoted 3 lines · On Tuesday 20 of May 2014 16:16:12 [email protected] wrote:

Regarding the question of emulated vs. real effects, can we extend the API so that applications can know which effects are really supported, and enable/disable emulation somehow?

I suppose that a few extra flags (FF_PERIODIC_EMULATED etc.) defined in "uapi/linux/input.h" should suffice.

@Dmitry:
Now that we're talking about API changes, I would like to propose some additional things in the Linux FF API:

- Possibility to *get* FF state variables, such as the value of the current GAIN, and the current AUTOCENTER:
At the moment, only *setting* is possible.
This poses a problem when implementing proper AUTOCENTER state recovery (upon closing a Windows program) in Wine, because the initial AUTOCENTER state was unknown.
The same applies for GAIN.

- Introduce multiple types of GAIN, apart from the current global GAIN, e.g. GAIN_CONSTANT and GAIN_DAMPER:
This is mainly on request of some users, especially Logitech users: on Windows Logitech additionally supports to set the global Damper and Spring gain.
Maybe it would be nicer to create a global gain for every supported Linux FF effect?

Quoted 5 lines

Regarding the question of emulated vs. real effects, can we extend the API
so that applications can know which effects are really supported, and enable/disable emulation somehow?

I suppose that a few extra flags (FF_PERIODIC_EMULATED etc.) defined in "uapi/linux/input.h" should suffice.

Quoted 7 lines

Quoted 4 lines

Regarding the question of emulated vs. real effects, can we extend the API
so that applications can know which effects are really supported, and enable/disable emulation somehow?

I suppose that a few extra flags (FF_PERIODIC_EMULATED etc.) defined in "uapi/linux/input.h" should suffice.

The only problem is that we probably want to maintain backward compatibility so that older apps still see 'PERIODIC' (even though it is emulated).
--
#define FF_RUMBLE 0x50
#define FF_PERIODIC 0x51
#define FF_CONSTANT 0x52
#define FF_SPRING 0x53
#define FF_FRICTION 0x54
#define FF_DAMPER 0x55
#define FF_INERTIA 0x56
#define FF_RAMP 0x57
--

Do we therefore have to list extra items in our capabilities? --

static const signed short lg4ff_wheel_effects[] = {
	FF_CONSTANT,
	FF_PERIODIC,
	FF_PERIODIC_NOT_EMULATED,
	FF_AUTOCENTER,
	-1
};

--

Simon

include/linux/input/ff-memless-next.h new file +4 -0

+
+/** input_ff_create_mlnx() - Register a device within ff-memless-next and
+ *                           the kernel force feedback system
+ * @dev: Pointer to the struct input_dev associated with the device.

Quoted 10 lines · Michal Malý

include/linux/input/ff-memless-next.h new file +9 -0

+
+/** input_ff_create_mlnx() - Register a device within ff-memless-next and
+ *                           the kernel force feedback system
+ * @dev: Pointer to the struct input_dev associated with the device.
+ * @data: Any device-specific data that shall be passed to the callback.
+ *        function called by ff-memless-next when a force feedback action
+ *        shall be performed.
+ * @control_effect: Pointer to the callback function.
+ * @update_date: Delay in milliseconds between two recalculations of

periodic + * effects, ramp effects and envelopes. Note that

Quoted 4 lines

this value will + * never be lower than (CONFIG_HZ / 1000)
+ 1 regardless of the + * value specified here. This is not
a "hard" rate limiter. + * Userspace still can submit
effects at a rate faster than + * this value.

The update rate change seems useful whether we use new ff implementation or enhance the old one but I would prefer having a separate call to control it.

Port hid-lg4ff to ff-memless-next

Signed-off-by Michal Malý <[email protected]>

Tested-by Tested-by: Elias Vanderstuyft <[email protected]>

This patch series:
1) Adds "ff-memless-next" module [1]
2) Ports all hardware-specific drivers to MLNX's API [2-23]
3) Removes FFML and replaces it with MLNX [24]

Signed-off-by Michal Malý <[email protected]>

v4:
- Add a summary of changes between MLNX and FFML to the last patch
- Remove a stale empty line in hid-sony.c
- Add "Tested-by: Elias Vanderstuyft <[email protected]>" to hid-lg4ff
patch.

v3:
- Rebase against latest linux-next. Fixes conflict in hid-sony.c and max8997_haptic.c
- Updated documentation in ff-memless-next.h. The documentation now
describes
parameters of the callback function and specifically mentions that HW-specific drivers must not keep a reference to mlnx_effect_command
struct
to which a pointer is passed in the callback function.
- Fix a minor brace inconsistency in hid-lgff
I believe that all concerns regarding v2 have been resolved as false
alarms.

v2:
- Add missing msecs to jiffies conversion in ff-memless-next
- lgff: Properly convert force on Y axis from MLNX to device range Support periodic effects for "joystick_ac" device class
- lg3ff: Properly convert forces from MLNX to device range
- Very minor coding style issues fixed

ff-memless-next (MLNX) is a largely improved version of the current ff-memless (FFML) driver. MLNX supports all force feedback effects currently available in the Linux force feedback userspace API. All effects are handled in accordance with Microsoft's DirectInput/XInput. Most notable changes include support for conditional effects, proper handling of all periodic waveforms and improved emulation of rumble effects through periodic effects. MLNX also uses its own kernel API to pass processed effects to hardware-specific drivers instead of abusing "ff_effect" struct. The API is documented in the respective header file.

MLNX has been expanded to be a direct replacement for FFML.

Support for FF_PERIODIC and FF_RAMP has been added to all devices that support FF_CONSTANT as a part of the port to the new API.

This patch series:
1) Adds "ff-memless-next" module [1]
2) Ports all hardware-specific drivers to MLNX's API [2-23]
3) Removes FFML and replaces it with MLNX [24]

Quoted 12 lines · Michal Malý

ff-memless-next (MLNX) is a largely improved version of the current ff-memless (FFML) driver. MLNX supports all force feedback effects currently available in the Linux force feedback userspace API. All effects are handled in accordance with Microsoft's DirectInput/XInput. Most notable changes include support for conditional effects, proper handling of all periodic waveforms and improved emulation of rumble effects through periodic effects. MLNX also uses its own kernel API to pass processed effects to hardware-specific drivers instead of abusing "ff_effect" struct. The API is documented in the respective header file.

MLNX has been expanded to be a direct replacement for FFML.

Quoted 7 lines

Support for FF_PERIODIC and FF_RAMP has been added to all devices that support FF_CONSTANT as a part of the port to the new API.

This patch series:
1) Adds "ff-memless-next" module [1]
2) Ports all hardware-specific drivers to MLNX's API [2-23]
3) Removes FFML and replaces it with MLNX [24]

Dmitry,

what are your plans with this, please?

I personally don't really completely like having two implementations of FF in the kernel; can't it be really done as an extension to ff-memless?