On 05/20/2014 02:27 AM, Michal Malý wrote: > 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. >> >> Thanks. > > To bring this to a conclusion we could go from, would this be an acceptable > solution? > > - Have the HW-specific driver talk directly to ff-core and reimplement > upload(), > play(), etc. > - Rewrite "ff-memless-next" so that it is not a self-contained module but a > library of functions. > - Have the driver either: > - Upload an effect to a device directly if the device can fully manage the > effect by itself. > - Use provided timing functions to know when an effect should start, stop, > restart etc... > - Use provided timing AND processing functions to combine effects that can > be > combined into one, calculate periodic waveforms etc? > > I have no problem with throwing my current approach away but before I start > working on a new one I'd like to know which way to go... > > Thanks, > Michal
Hi everyone Allow me to introduce myself. I'm Roland Bosa and I work for Logitech, more specifically the gaming group. I have been tasked to look into gaming device support for Linux and I just started following this list and studying the kernel code related to the Logitech Force Feedback devices. The 'ff-memless-next' module sounds tailor-made for our devices. Please let me know how I can help with its development. Thanks Roland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
