From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal =?ISO-8859-1?Q?Mal=FD?= Subject: Re: [PATCH v4 01/24] input: Add ff-memless-next module Date: Wed, 14 May 2014 10:35:25 +0200 Message-ID: <1818063.tFLKhAd1oy@sigyn> References: <1398524543-15012-1-git-send-email-madcatxster@devoid-pointer.net> <1398524543-15012-2-git-send-email-madcatxster@devoid-pointer.net> <20140514063806.GC13621@core.coreip.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from smtp.devoid-pointer.net ([31.31.77.140]:60794 "EHLO smtp.devoid-pointer.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751989AbaENIf3 convert rfc822-to-8bit (ORCPT ); Wed, 14 May 2014 04:35:29 -0400 In-Reply-To: <20140514063806.GC13621@core.coreip.homeip.net> Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Dmitry Torokhov 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 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=FD wrote: > > + > > +/** DEFINITION OF TERMS > > + * > > + * Combined effect - An effect whose force is a superposition of f= orces > > + * generated by all effects that can be added to= gether. > > + * 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 combine= d with > > another effect. + * All conditional effects - > > FF_DAMPER, FF_FRICTION, + * FF_INERTIA and > > FF_SPRING are uncombinable. + * Number of > > uncombinable effects playing simultaneously + * = =20 > > depends on the capabilities of the hardware. + * Rumble effect - An > > effect generated by device's rumble motors instead of + * = =20 > > 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 eff= ects > > 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-spe= cific > > driver at appropriate time. + * ff-memless-next provides the UPLOAD > > command to notify the hardware-specific + * driver that the userspa= ce is > > about to request playback of an uncombinable + * effect. The > > hardware-specific driver shall take all steps needed to make + * th= e > > device ready to play the effect when it receives the UPLOAD command= =2E + * > > The actual playback shall commence when START_UNCOMB command is rec= eived. > > + * Opposite to the UPLOAD command is the ERASE command which tells= + * > > the hardware-specific driver that the playback has finished and tha= t + * > > the effect will not be restarted. STOP_UNCOMB command tells > > + * the hardware-specific driver that the playback shall stop but t= he > > 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), t= he > > hardware-specific + * driver may return an error when it receives a= n > > 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 shou= ld > not be introducing this term here. If the goal is to work around limi= ted > number of effect slots in the devices by combining certain effects th= en > it needs to be done at ff-core level as it will be potentially useful > for all devices. =46orce generated by a conditional effect (referred to as "uncombinable= " within ff-memless-next to make the distinction clear) depends on a position of= the=20 device. For instance the more a device is deflected from a neutral posi= tion the=20 greater force FF_SPRING generates. A truly memoryless device would have= to=20 report its position to the driver, have it calculate the appropriate fo= rce and=20 send it back to the device. IMHO such a loop would require a very high = USB=20 polling rate to play conditional effects with acceptable quality. We know for a fact that at least many (all?) Logitech devices that supp= ort=20 conditional effects use this "semi-memoryless" approach where FF_CONSTA= NT and=20 =46F_PERIODIC are handled in the memoryless fashion and conditional eff= ects are=20 uploaded to the device (in a somewhat simplified form). The amount of e= ffects=20 that can be uploaded to a device is limited which is why ff-memless-nex= t uses=20 two steps (UPLOAD/ERASE and START/STOP) to handle these effects. Conditional effects - even if they are of the same type - cannot be eff= ectively=20 combined into one because superposition doesn't seem to work here so th= ey have=20 to be processed one by one. If we ever come across a really memoryless device it should not be=20 particularly difficult to add another callback to ff-memless-next which= would=20 emulate conditional effects with constant force. > > + * hardware-specific driver returns 0, the upload is considered > > successful. + * START_UNCOMB and STOP_UNCOMB commands cannot fail a= nd the > > device must always + * start the playback of the requested effect i= f 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 sen= d an > > ERASE command for an effect that is + * playing (=3D has been start= ed with > > START_UNCOMB command). > >=20 > > + */ > > + > > +enum mlnx_commands { > > + /* Start or update a combined effect. This command is sent whenev= er > > + * a FF_CONSTANT, FF_PERIODIC or FF_RAMP is started, stopped or > > + * updated by userspace, when the applied envelopes are recalcula= ted > > + * 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 direct= ions > > + * 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. */ >=20 > Why do we have make a distinction between rumble and all other effect= s? Because "combined" effect consists of two vectors pointing along X and = Y axes=20 whereas "rumble" effect is a rotation speed of a rumble motor and the d= irection=20 of rotation. Naturally these effects have to be handled in a different = fashion.=20 It is also possible to have a device with both rumble motors and FF act= uator.=20 Having such a distinction also makes it easier to handle emulation of r= umble=20 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