Re: [PATCH v4 01/24] input: Add ff-memless-next module

[Elias Vanderstuyft]

On Wed, May 14, 2014 at 10:35 AM, Michal MalÃ
<madcatxster@xxxxxxxxxxxxxxxxxx> wrote:
> Hi Dmitry,
>
> thank you for reviewing this.
>
> On Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote:
>> On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malà wrote:
>> > +
>> > +/** 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/