From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932195AbaENL0p (ORCPT ); Wed, 14 May 2014 07:26:45 -0400 Received: from mail-vc0-f169.google.com ([209.85.220.169]:37780 "EHLO mail-vc0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754939AbaENL0l convert rfc822-to-8bit (ORCPT ); Wed, 14 May 2014 07:26:41 -0400 MIME-Version: 1.0 In-Reply-To: <1818063.tFLKhAd1oy@sigyn> 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> Date: Wed, 14 May 2014 13:26:40 +0200 Message-ID: Subject: Re: [PATCH v4 01/24] input: Add ff-memless-next module From: Elias Vanderstuyft To: Dmitry Torokhov Cc: =?UTF-8?B?TWljaGFsIE1hbMO9?= , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, Jiri Kosina , Anssi Hannula , Simon Wood Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 14, 2014 at 10:35 AM, 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. And I should add that even the conditional effects themselves are handled semi-memless by the Logitech devices: the effects' time parameters are handled in a memless way: the scheduling has to be done by the driver, and is not uploaded to the device. Compare this with a fully non-memless device, an example of a driver that handles such devices: "hid-pidff.c" Here, all effect data is sent directly to the device, also the time-related parameters. Elias