On Wed, May 14, 2014 at 10:35 AM, Michal Malý <madcatxster@xxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
