From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752940AbaENIfc (ORCPT ); Wed, 14 May 2014 04:35:32 -0400 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 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 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> User-Agent: KMail/4.13 (Linux/3.14.1-1-my-rd; KDE/4.13.0; x86_64; ; ) In-Reply-To: <20140514063806.GC13621@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> 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 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. > > + * hardware-specific driver returns 0, the upload is considered > > successful. + * START_UNCOMB and STOP_UNCOMB commands cannot fail and the > > device must always + * start the playback of the requested effect if 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 send an > > ERASE command for an effect that is + * playing (= has been started with > > START_UNCOMB command). > > > > + */ > > + > > +enum mlnx_commands { > > + /* Start or update a combined effect. This command is sent whenever > > + * a FF_CONSTANT, FF_PERIODIC or FF_RAMP is started, stopped or > > + * updated by userspace, when the applied envelopes are recalculated > > + * 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 directions > > + * 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. */ > > Why do we have make a distinction between rumble and all other effects? Because "combined" effect consists of two vectors pointing along X and Y axes whereas "rumble" effect is a rotation speed of a rumble motor and the direction of rotation. Naturally these effects have to be handled in a different fashion. It is also possible to have a device with both rumble motors and FF actuator. Having such a distinction also makes it easier to handle emulation of rumble effects through constant force and vice versa. Michal