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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751629AbaENTiZ (ORCPT ); Wed, 14 May 2014 15:38:25 -0400 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 From: Michal =?ISO-8859-1?Q?Mal=FD?= 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 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> User-Agent: KMail/4.13 (Linux/3.14.1-1-my-rd; KDE/4.13.0; x86_64; ; ) In-Reply-To: <20140514180558.GB30089@core.coreip.homeip.net> 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-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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ư wrote: > > 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. > > 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 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 can > 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 thing that is uploaded to the device are parameters of the force to be generated. Other parameters - such as timing - still have to be managed by the driver. Any driver supporting conditional effects would then have to reimplement at least the timing logic. Another thing of concern is rate limiting. During our testing we have discovered that some games can fire off FF commands at a very fast rate - much faster than USB polling rate of a device. This eventually overfills the USB submit queue and messes everything up. A proper way to fix this would be to limit the rate at which the driver sends HW requests. We already have a few ideas as to how to implement this in ff-memless-next. If we had the driver use ff-memless-next to manage one category of effects and use its own logic to 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 conditional effects through to the HW-specific driver that then takes care of everything. A practical example of how this works can be found in an experimental port of "hid-lg4ff" driver to ff-memless-next by Edwin Velds (https://github.com/edwin-v/linux-hid-lg4ff-next). The only thing that ff-memless-next does is that it tells the HW-specific driver that such an effect such start or stop playing. The reasoning above made me implement the support for conditional effects in the way I did. As much as I agree that we're not dealing with purely memoryless devices here, I believe that most more advanced FFB wheels/sticks are in fact "semi-memoryless" and will therefore benefit from the approach used in ff-memless-next. Michal