Message-ID: <1818063.tFLKhAd1oy@sigyn>
Date:	Wed, 14 May 2014 10:35:25 +0200
From:	Michal Malý <madcatxster@...oid-pointer.net>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	jkosina@...e.cz, elias.vds@...il.com, anssi.hannula@....fi,
	simon@...gewell.org
Subject: Re: [PATCH v4 01/24] input: Add ff-memless-next module

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.

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

Because "combined" effect consists of two vectors pointing along X and Y axes 
whereas "rumble" effect is a rotation speed of a rumble motor and the direction 
of rotation. Naturally these effects have to be handled in a different fashion. 
It is also possible to have a device with both rumble motors and FF actuator. 
Having such a distinction also makes it easier to handle emulation of rumble 
effects through constant force and vice versa.

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists