From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Torokhov Subject: Re: [PATCH v4 01/24] input: Add ff-memless-next module Date: Wed, 14 May 2014 11:05:58 -0700 Message-ID: <20140514180558.GB30089@core.coreip.homeip.net> 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> <1818063.tFLKhAd1oy@sigyn> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mail-pb0-f54.google.com ([209.85.160.54]:52497 "EHLO mail-pb0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750987AbaENSGD (ORCPT ); Wed, 14 May 2014 14:06:03 -0400 Content-Disposition: inline In-Reply-To: <1818063.tFLKhAd1oy@sigyn> Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Michal =?iso-8859-1?Q?Mal=FD?= 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 On Wed, May 14, 2014 at 10:35:25AM +0200, Michal Mal=FD wrote: > Hi Dmitry, >=20 > thank you for reviewing this. >=20 > 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= 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 creat= e a > > > combined + * effect are FF_CONSTANT, FF_PERIODI= C and > > > FF_RAMP. + * Uncombinable effect - An effect that cannot be combi= ned 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 on= e effect, > > > at + * least not in a clear and obvious manner. Therefore these e= ffects > > > 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-s= pecific > > > driver at appropriate time. + * ff-memless-next provides the UPLO= AD > > > command to notify the hardware-specific + * driver that the users= pace 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 comma= nd. + * > > > The actual playback shall commence when START_UNCOMB command is r= eceived. > > > + * Opposite to the UPLOAD command is the ERASE command which tel= ls + * > > > the hardware-specific driver that the playback has finished and t= hat + * > > > 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 immediatel= y. > > > + * > > > + * In case it is not possible to make the device ready to play a= n > > > 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 sh= ould > > not be introducing this term here. If the goal is to work around li= mited > > 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 usef= ul > > for all devices. >=20 > 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=20 > device. For instance the more a device is deflected from a neutral po= sition the=20 > greater force FF_SPRING generates. A truly memoryless device would ha= ve to=20 > report its position to the driver, have it calculate the appropriate = force and=20 > send it back to the device. IMHO such a loop would require a very hig= h USB=20 > polling rate to play conditional effects with acceptable quality. >=20 > We know for a fact that at least many (all?) Logitech devices that su= pport=20 > conditional effects use this "semi-memoryless" approach where FF_CONS= TANT and=20 > FF_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= effects=20 > that can be uploaded to a device is limited which is why ff-memless-n= ext uses=20 > two steps (UPLOAD/ERASE and START/STOP) to handle these effects. >=20 > Conditional effects - even if they are of the same type - cannot be e= ffectively=20 > combined into one because superposition doesn't seem to work here so = they have=20 > to be processed one by one. >=20 > If we ever come across a really memoryless device it should not be=20 > particularly difficult to add another callback to ff-memless-next whi= ch would=20 > emulate conditional effects with constant force. Thank you for the explanation. This further solidifies for me the idea that handling of such effects that are in fact uploaded to and managed by the device should not be handled by the memoryless core but rather b= y the driver itself. I.e. such drivers should implement their own play(), upload(), erase(), etc, and decide whether to use a hardware slot for the effect or handle effect in memoryless fashion (if possible). We can open ff-memless to allow such drivers to use parts of memoryless handling. Thanks. --=20 Dmitry -- 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