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: Tue, 20 May 2014 11:27:21 +0200 Message-ID: <2965006.XKYHWj9YzJ@sigyn> References: <1398524543-15012-1-git-send-email-madcatxster@devoid-pointer.net> <1818063.tFLKhAd1oy@sigyn> <20140514180558.GB30089@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 devoid-pointer.net ([31.31.77.140]:33026 "EHLO smtp.devoid-pointer.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751092AbaETJ10 convert rfc822-to-8bit (ORCPT ); Tue, 20 May 2014 05:27:26 -0400 In-Reply-To: <20140514180558.GB30089@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 On Wednesday 14 of May 2014 11:05:58 Dmitry Torokhov wrote: > 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 adde= d > > > > together. > > > > + * Only one combined effect can be playing a= t a > > > > time. > > > > + * Effects that can be added together to cre= ate a > > > > combined + * effect are FF_CONSTANT, FF_PERIO= DIC and > > > > FF_RAMP. + * Uncombinable effect - An effect that cannot be com= bined > > > > with > > > > another effect. + * All conditional effec= ts - > > > > FF_DAMPER, FF_FRICTION, + * FF_INERTIA an= d > > > > 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. Handlin= g 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 UP= LOAD > > > > command to notify the hardware-specific + * driver that the use= rspace > > > > 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 com= mand. + > > > > * > > > > The actual playback shall commence when START_UNCOMB command is > > > > received. > > > > + * Opposite to the UPLOAD command is the ERASE command which t= ells + > > > > * > > > > 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 b= ut the > > > > device + * shall still be ready to resume the playback immediat= ely. > > > > + * > > > > + * 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 receiv= es an > > > > UPLOAD command. If the > > >=20 > > > 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 effect= s then > > > it needs to be done at ff-core level as it will be potentially us= eful > > > for all devices. > >=20 > > Force generated by a conditional effect (referred to as "uncombinab= le" > > 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. > >=20 > > We know for a fact that at least many (all?) Logitech devices that = support > > conditional effects use this "semi-memoryless" approach where FF_CO= NSTANT > > and FF_PERIODIC are handled in the memoryless fashion and condition= al > > 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. > >=20 > > 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. > >=20 > > If we ever come across a really memoryless device it should not be > > particularly difficult to add another callback to ff-memless-next w= hich > > would emulate conditional effects with constant force. >=20 > Thank you for the explanation. This further solidifies for me the ide= a > that handling of such effects that are in fact uploaded to and manage= d > by the device should not be handled by the memoryless core but rather= by > 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 c= an > open ff-memless to allow such drivers to use parts of memoryless > handling. >=20 > Thanks. To bring this to a conclusion we could go from, would this be an accept= able=20 solution? - Have the HW-specific driver talk directly to ff-core and reimplement = upload(),=20 play(), etc. - Rewrite "ff-memless-next" so that it is not a self-contained module b= ut a=20 library of functions. - Have the driver either: - Upload an effect to a device directly if the device can fully manag= e the=20 effect by itself. - Use provided timing functions to know when an effect should start, = stop,=20 restart etc... - Use provided timing AND processing functions to combine effects tha= t can be=20 combined into one, calculate periodic waveforms etc? I have no problem with throwing my current approach away but before I s= tart=20 working on a new one I'd like to know which way to go... Thanks, 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