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 21:38:19 +0200 Message-ID: <1439423.NODVhUYV2m@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]:60845 "EHLO smtp.devoid-pointer.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751108AbaENTiX convert rfc822-to-8bit (ORCPT ); Wed, 14 May 2014 15:38:23 -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, edwin@velds.nl 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. Well, these effects are not exactly managed by the device. The only thi= ng that=20 is uploaded to the device are parameters of the force to be generated. = Other=20 parameters - such as timing - still have to be managed by the driver. A= ny=20 driver supporting conditional effects would then have to reimplement at= least=20 the timing logic. Another thing of concern is rate limiting. During our testing we have=20 discovered that some games can fire off FF commands at a very fast rate= - much=20 faster than USB polling rate of a device. This eventually overfills the= USB=20 submit queue and messes everything up. A proper way to fix this would b= e to=20 limit the rate at which the driver sends HW requests. We already have a= few=20 ideas as to how to implement this in ff-memless-next. If we had the dri= ver use=20 ff-memless-next to manage one category of effects and use its own logic= to=20 manage the rest it'd be next to impossible to do this properly. It should also be noted that ff-memless-next almost passes the conditio= nal=20 effects through to the HW-specific driver that then takes care of every= thing. A=20 practical example of how this works can be found in an experimental por= t of=20 "hid-lg4ff" driver to ff-memless-next by Edwin Velds (https://github.co= m/edwin-v/linux-hid-lg4ff-next). The only thing that ff-memless-next do= es is that it=20 tells the HW-specific driver that such an effect such start or stop pla= ying. The reasoning above made me implement the support for conditional effec= ts in=20 the way I did. As much as I agree that we're not dealing with purely=20 memoryless devices here, I believe that most more advanced FFB wheels/s= ticks=20 are in fact "semi-memoryless" and will therefore benefit from the appro= ach used=20 in ff-memless-next. 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