On Wed, May 14, 2014 at 10:35 AM, Michal Malý
[off-list ref] wrote:

Hi Dmitry,

thank you for reviewing this.

On Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote:

quoted

On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malý wrote:

quoted

+
+/** 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
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.

And I should add that even the conditional effects themselves are
handled semi-memless by the Logitech devices:
the effects' time parameters are handled in a memless way: the
scheduling has to be done by the driver, and is not uploaded to the
device.

Compare this with a fully non-memless device, an example of a driver
that handles such devices: "hid-pidff.c"
Here, all effect data is sent directly to the device, also the
time-related parameters.

Elias