linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michal Malý" <madcatxster@devoid-pointer.net>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	jkosina@suse.cz, elias.vds@gmail.com, anssi.hannula@iki.fi,
	simon@mungewell.org
Subject: Re: [PATCH v4 01/24] input: Add ff-memless-next module
Date: Wed, 14 May 2014 10:35:25 +0200	[thread overview]
Message-ID: <1818063.tFLKhAd1oy@sigyn> (raw)
In-Reply-To: <20140514063806.GC13621@core.coreip.homeip.net>

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

  reply	other threads:[~2014-05-14  8:35 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-26 15:01 [PATCH v4 00/24] input: Introduce ff-memless-next as an improved replacement for ff-memless Michal Malý
2014-04-26 15:02 ` [PATCH v4 01/24] input: Add ff-memless-next module Michal Malý
2014-05-14  6:38   ` Dmitry Torokhov
2014-05-14  8:35     ` Michal Malý [this message]
2014-05-14 11:26       ` Elias Vanderstuyft
2014-05-14 15:11       ` simon
2014-05-14 17:58         ` Dmitry Torokhov
2014-05-14 18:05       ` Dmitry Torokhov
2014-05-14 19:38         ` Michal Malý
2014-05-20  9:27         ` Michal Malý
2014-05-20 18:32           ` Roland Bosa
2014-05-20 19:00             ` Michal Malý
2014-05-20 21:38               ` Roland Bosa
2014-05-21 14:53                 ` Elias Vanderstuyft
     [not found]                   ` <537D28E3.3000401@logitech.com>
2014-05-21 22:42                     ` simon
2014-05-20 19:39             ` simon
2014-05-20 22:04               ` Roland Bosa
2014-05-20 23:30                 ` simon
2014-05-21  1:17                   ` Roland Bosa
2014-05-21  2:13                     ` Michal Malý
2014-05-21 10:17                       ` Nestor Lopez Casado
2014-05-21 14:08                         ` Elias Vanderstuyft
2014-05-21 13:35                       ` Elias Vanderstuyft
2014-05-21 14:22                         ` Elias Vanderstuyft
2014-05-21 14:05                       ` Elias Vanderstuyft
2014-05-20 20:16           ` simon
2014-05-20 20:58             ` Michal Malý
2014-05-20 21:26               ` Elias Vanderstuyft
2014-05-22  9:48                 ` Elias Vanderstuyft
2014-05-20 23:45               ` simon
2014-05-21  0:08                 ` Michal Malý
2014-05-14 18:14   ` Dmitry Torokhov
2014-05-14 19:40     ` Michal Malý
2014-04-26 15:02 ` [PATCH v4 02/24] input: Port arizona-haptics to ff-memless-next Michal Malý
2014-04-26 15:02 ` [PATCH v4 03/24] input: Port twl4030-vibra " Michal Malý
2014-04-26 15:02 ` [PATCH v4 04/24] input: Port twl6040-vibra " Michal Malý
2014-04-26 15:02 ` [PATCH v4 05/24] input: Port max8997_haptic " Michal Malý
2014-04-26 15:02 ` [PATCH v4 06/24] input: Port pm8xxx-vibrator " Michal Malý
2014-04-26 15:02 ` [PATCH v4 07/24] hid: Port hid-axff " Michal Malý
2014-04-26 15:02 ` [PATCH v4 08/24] hid: Port hid-emsff " Michal Malý
2014-04-26 15:02 ` [PATCH v4 09/24] hid: Port hid-dr " Michal Malý
2014-04-26 15:02 ` [PATCH v4 10/24] hid: Port hid-gaff " Michal Malý
2014-04-26 15:02 ` [PATCH v4 11/24] hid: Port hid-holtekff " Michal Malý
2014-04-26 15:02 ` [PATCH v4 12/24] hid: Port hid-lgff " Michal Malý
2014-04-26 15:02 ` [PATCH v4 13/24] hid: Port hid-lg3ff " Michal Malý
2014-04-26 15:02 ` [PATCH v4 14/24] hid: Port hid-pl " Michal Malý
2014-04-26 15:02 ` [PATCH v4 15/24] hid: Port hid-sjoy " Michal Malý
2014-04-26 15:02 ` [PATCH v4 16/24] hid: Port hid-sony " Michal Malý
2014-04-26 15:02 ` [PATCH v4 17/24] hid: Port hid-tmff " Michal Malý
2014-04-26 15:02 ` [PATCH v4 18/24] hid: Port hid-wiimote-modules " Michal Malý
2014-04-26 15:02 ` [PATCH v4 19/24] hid: Port hid-zpff " Michal Malý
2014-04-26 15:02 ` [PATCH v4 20/24] input: Port gamecon " Michal Malý
2014-04-26 15:02 ` [PATCH v4 21/24] input: Port xpad " Michal Malý
2014-04-26 15:02 ` [PATCH v4 22/24] hid: Port hid-lg2ff " Michal Malý
2014-04-26 15:02 ` [PATCH v4 23/24] hid: Port hid-lg4ff " Michal Malý
2014-04-29 16:05   ` simon
2014-04-26 15:02 ` [PATCH v4 24/24] input: Replace ff-memless with ff-memless-next Michal Malý
2014-04-29 15:59 ` [PATCH v4 00/24] input: Introduce ff-memless-next as an improved replacement for ff-memless simon
2014-05-12  9:14 ` Jiri Kosina
2014-05-12  9:26   ` Michal Malý

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1818063.tFLKhAd1oy@sigyn \
    --to=madcatxster@devoid-pointer.net \
    --cc=anssi.hannula@iki.fi \
    --cc=dmitry.torokhov@gmail.com \
    --cc=elias.vds@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=simon@mungewell.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).