All of lore.kernel.org
 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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
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: 83+ 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:01 ` Michal Malý
2014-04-26 15:02 ` [PATCH v4 01/24] input: Add ff-memless-next module Michal Malý
2014-04-26 15:02   ` Michal Malý
2014-05-14  6:38   ` Dmitry Torokhov
2014-05-14  6:38     ` Dmitry Torokhov
2014-05-14  8:35     ` Michal Malý [this message]
2014-05-14  8:35       ` Michal Malý
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 18:05         ` Dmitry Torokhov
2014-05-14 19:38         ` Michal Malý
2014-05-14 19:38           ` Michal Malý
2014-05-20  9:27         ` Michal Malý
2014-05-20  9:27           ` Michal Malý
2014-05-20 18:32           ` Roland Bosa
2014-05-20 18:32             ` Roland Bosa
2014-05-20 19:00             ` Michal Malý
2014-05-20 19:00               ` Michal Malý
2014-05-20 21:38               ` Roland Bosa
2014-05-20 21:38                 ` Roland Bosa
2014-05-21 14:53                 ` Elias Vanderstuyft
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 10:17                         ` Nestor Lopez Casado
2014-05-21 14:08                         ` Elias Vanderstuyft
2014-05-21 13:35                       ` Elias Vanderstuyft
2014-05-21 13:35                         ` Elias Vanderstuyft
2014-05-21 14:22                         ` Elias Vanderstuyft
2014-05-21 14:22                           ` Elias Vanderstuyft
2014-05-21 14:05                       ` 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-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-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   ` 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   ` 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-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-04-29 15:59   ` simon
2014-05-12  9:14 ` Jiri Kosina
2014-05-12  9:14   ` Jiri Kosina
2014-05-12  9:26   ` Michal Malý
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.