Message ID | 1398524543-15012-2-git-send-email-madcatxster@devoid-pointer.net (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Hi Michal, 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. > + * 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?
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 -- 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
On Wed, May 14, 2014 at 10:35 AM, Michal Malý <madcatxster@devoid-pointer.net> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> 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. It should be noted that some (/many?) applications/games already use the CF with position feedback to emulate behaviour such as springs. The feed back loop is simply not fast enough to do emulation of friction/inertia. I don't believe that the FF layer in the kernel should be 'tricked out' with lots of emulation features. As a game designer (ok... tinkerer) it's a bit of a pain that devices lie about what they can really do - ie. gamepads claiming periodic ability when all they are doing is faking it with rumble. Simon. -- 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
On Wed, May 14, 2014 at 11:11:40AM -0400, simon@mungewell.org wrote: > > > 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. > > It should be noted that some (/many?) applications/games already use the > CF with position feedback to emulate behaviour such as springs. The feed > back loop is simply not fast enough to do emulation of friction/inertia. > > I don't believe that the FF layer in the kernel should be 'tricked out' > with lots of emulation features. > > As a game designer (ok... tinkerer) it's a bit of a pain that devices lie > about what they can really do - ie. gamepads claiming periodic ability > when all they are doing is faking it with rumble. Would it help if kernel would indicate which effects are native and which are emulated? Thanks.
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.
On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malý wrote: > + > +/** input_ff_create_mlnx() - Register a device within ff-memless-next and > + * the kernel force feedback system > + * @dev: Pointer to the struct input_dev associated with the device. > + * @data: Any device-specific data that shall be passed to the callback. > + * function called by ff-memless-next when a force feedback action > + * shall be performed. > + * @control_effect: Pointer to the callback function. > + * @update_date: Delay in milliseconds between two recalculations of periodic > + * effects, ramp effects and envelopes. Note that this value will > + * never be lower than (CONFIG_HZ / 1000) + 1 regardless of the > + * value specified here. This is not a "hard" rate limiter. > + * Userspace still can submit effects at a rate faster than > + * this value. The update rate change seems useful whether we use new ff implementation or enhance the old one but I would prefer having a separate call to control it. Thanks.
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 -- 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
On Wednesday 14 of May 2014 11:14:02 Dmitry Torokhov wrote: > On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malý wrote: > > + > > +/** input_ff_create_mlnx() - Register a device within ff-memless-next and > > + * the kernel force feedback system > > + * @dev: Pointer to the struct input_dev associated with the device. > > + * @data: Any device-specific data that shall be passed to the callback. > > + * function called by ff-memless-next when a force feedback action > > + * shall be performed. > > + * @control_effect: Pointer to the callback function. > > + * @update_date: Delay in milliseconds between two recalculations of > > periodic + * effects, ramp effects and envelopes. Note that > > this value will + * never be lower than (CONFIG_HZ / 1000) > > + 1 regardless of the + * value specified here. This is not > > a "hard" rate limiter. + * Userspace still can submit > > effects at a rate faster than + * this value. > > The update rate change seems useful whether we use new ff implementation > or enhance the old one but I would prefer having a separate call to > control it. OK, that should not be a problem. Please note that the plan is to use this value to do proper "hard" rate limiting in the future. -- 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
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 -- 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
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-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 20 of May 2014 11:32:14 Roland Bosa wrote: > 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. Hi, "ff-memless-next" was designed with behavior of Logitech devices in mind, however it was always meant as a general replacement for the current "ff- memless". After some followup discussion it's unlikely that it will be mainlined in its current form. See the discussion here "http://www.spinics.net/lists/linux-input/msg31426.html" for more details. We would however really appreciate some information regarding Logitech devices specifically. Although we have reverse engineered most of things, I believe there are still areas we're not entirely clear about. I realize that you'd probably have to take it up with the legal deparment but if someone at Logitech could at least take a look at what we've found so far at fill in the blanks it'd be most helpful. Please note that we found numerous bugs and DirectInput specs violations in the Windows driver which might have impacted our understading of how the driver works. "ff-memless-next" and "lg4ff" tries to fix or work around these. A link to out-of-tree update to lg4ff which takes full advantage of "ff-memless- next" is also provided in this thread. Thanks for any help you can get us, 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
> 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. Hello Roland, Let me echo Michal's welcome. As you will see from the 'ff-memless-next' driver we are looking to extend force-feedback support to cover more than just ConstantForce support, and hopefully bring Linux into scope for force-feedback of AAA game quality. Mostly this has come from a small group of people reverse engineering the Logitech wheels, which leads to the 'tailor-made' situation. But we'd like the systems/interfaces to be device agnostic. As you how you can help...? As Michal said having a contact at Logitech to whom we can ask technical questions (off list) would probably be the greatest help. This would clear up any assumptions we have made, and help with decisions going forward. It may also be the case that Logitech is working with studios/game designers to improve controller performance. If any information can be feed 'forward' to improve the Linux driver, that would be useful too. Many thanks, Simon Wood. -- 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
> 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... Hi all, If the driver itself (hid-logitech, via hid-lg4ff for example) is more involved in the creation/timing/management of the effects, does this mean that we end up with code duplicated in lots of places? Also, does this mean that the 'old' ff-memless system would remain in kernel? If not, who will reworking each driver? Regarding the question of emulated vs. real effects, can we extend the API so that applications can know which effects are really supported, and enable/disable emulation somehow? Apologies for asking some many questions, without answering anything... Simon -- 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
On Tuesday 20 of May 2014 16:16:12 simon@mungewell.org wrote: > > 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... > > Hi all, > If the driver itself (hid-logitech, via hid-lg4ff for example) is more > involved in the creation/timing/management of the effects, does this mean > that we end up with code duplicated in lots of places? Hopefully not. I tried to work out some scheme how this would work in my head today and the code duplication among other drivers should be minimal. Basically an equivalent of "play_effects()" - implemented in the HW-specific driver - would by called as needed. Such a function would then use provided helper functions to process combinable effects and check if any uncombinable effects changed state. A proper rate limiting will fit into this scheme nicely as well. The biggest advantage of this design is that the HW-specific driver will be able to either handle an effect all by itself or use the provided "helper" infrastructure. In retrospect I've got agree with Dmitry that the current handling of (semi)memless devices is not very flexible and therefore potentially problematic. It'll require some extra work but we don't have to invent anything entirely new here, we can just rearrange what we've already done in MLNX and package it into a library. > Also, does this mean that the 'old' ff-memless system would remain in > kernel? If not, who will reworking each driver? I suppose that the maintainers would want us to move all FF drivers to this architecture. If we get it right, it shouldn't require a terrible amount of work to port the other drivers. > Regarding the question of emulated vs. real effects, can we extend the API > so that applications can know which effects are really supported, and > enable/disable emulation somehow? I suppose that a few extra flags (FF_PERIODIC_EMULATED etc.) defined in "uapi/linux/input.h" should suffice. 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
On Tue, May 20, 2014 at 10:58 PM, Michal Malý <madcatxster@devoid-pointer.net> wrote: > On Tuesday 20 of May 2014 16:16:12 simon@mungewell.org wrote: >> Regarding the question of emulated vs. real effects, can we extend the API >> so that applications can know which effects are really supported, and >> enable/disable emulation somehow? > > I suppose that a few extra flags (FF_PERIODIC_EMULATED etc.) defined in > "uapi/linux/input.h" should suffice. @Dmitry: Now that we're talking about API changes, I would like to propose some additional things in the Linux FF API: - Possibility to *get* FF state variables, such as the value of the current GAIN, and the current AUTOCENTER: At the moment, only *setting* is possible. This poses a problem when implementing proper AUTOCENTER state recovery (upon closing a Windows program) in Wine, because the initial AUTOCENTER state was unknown. The same applies for GAIN. - Introduce multiple types of GAIN, apart from the current global GAIN, e.g. GAIN_CONSTANT and GAIN_DAMPER: This is mainly on request of some users, especially Logitech users: on Windows Logitech additionally supports to set the global Damper and Spring gain. Maybe it would be nicer to create a global gain for every supported Linux FF effect? Thanks, Elias -- 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
On 05/20/2014 12:00 PM, Michal Malý wrote: > Hi, > > "ff-memless-next" was designed with behavior of Logitech devices in mind, > however it was always meant as a general replacement for the current "ff- > memless". After some followup discussion it's unlikely that it will be > mainlined in its current form. See the discussion here > "http://www.spinics.net/lists/linux-input/msg31426.html" for more details. > > We would however really appreciate some information regarding Logitech devices > specifically. Although we have reverse engineered most of things, I believe > there are still areas we're not entirely clear about. I realize that you'd > probably have to take it up with the legal deparment but if someone at > Logitech could at least take a look at what we've found so far at fill in the > blanks it'd be most helpful. I'm your guy, then. Please send any questions my way and I'll dig out the information you need - with the lawyer's blessings, if need be. > Please note that we found numerous bugs and DirectInput specs violations in > the Windows driver which might have impacted our understading of how the > driver works. "ff-memless-next" and "lg4ff" tries to fix or work around these. A > link to out-of-tree update to lg4ff which takes full advantage of "ff-memless- > next" is also provided in this thread. lg4ff is mostly wheels, from what I saw. We should be able to fold in the G940 (Flight System) as well as other joysticks into the same driver. The underlying model driving the forces of our devices is essentially the same, there are just slight improvements made over the years to accommodate higher resolutions and more powerful micro processors. Each device has a unique number (say 2 or 4) of force 'slots' per axis, which is running a force calculation in firmware. Typically, one of these slots is allocated by the host driver for a constant force, that's streamed to the device (and comprises all constant and periodic forces sent by the 'game' - that's the combined type of your code, as far as I can tell). The other slot may be used for position-based effects (springs, centering spring) as well as velocity-based effects (dampers, friction) - that's the un-combinable type. There's a healthy amount of code in the Windows driver that you would call 'quirks' which deals with deciding how to allocate multiple springs and dampers to a single slot. Sometimes, even the springs and dampers are being streamed in via the constants force, but that requires (as you pointed out earlier) a fast update rate and some "smartness" (I'm getting in hot territory with the lawyers now - let me stop). One of the key features of the design is the decoupling of the USB updates from the force feedback IOCTL's from the 'game'. I don't think this is currently the case with today's drivers. I was able to send force updates to a gamepad faster than the USB update rate, which led to some lost packets which in turn left the device in a inconsistent state - the motors were still rumbling although they should have stopped. If the 'ff-memless-next' driver offers this decoupling, it is a step in the right direction, IMO. I will try to apply the patch mentioned in this thread and see where it leads me... Thanks roland -- 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
On 05/20/2014 12:39 PM, simon@mungewell.org wrote: > hopefully bring Linux into scope for force-feedback of AAA game quality. ^ That's my objective too. > Mostly this has come from a small group of people reverse engineering the > Logitech wheels, which leads to the 'tailor-made' situation. But we'd like > the systems/interfaces to be device agnostic. I'm sure we can consolidate the support into fewer files. > As you how you can help...? As Michal said having a contact at Logitech to > whom we can ask technical questions (off list) would probably be the > greatest help. This would clear up any assumptions we have made, and help > with decisions going forward. Please don't hesitate to contact me. ;-) > It may also be the case that Logitech is working with studios/game > designers to improve controller performance. If any information can be > feed 'forward' to improve the Linux driver, that would be useful too. IMO, there are two types of games. The "arcade" ones, which have a set of 'canned' force effects, which play whenever an event happens in game. And the "simulation" ones, which base the game on a physics engine. The latter can redirect some variables of their engine to the input layer and typically drive a constant force and maybe a spring/damper too. For the first type, you might want to keep a centering spring active all the time. Maybe you want to tweak the gain in the game settings. Maybe there's a gain for the centering and one for the special effects. The canned effects are mostly periodics with varying waveform, duration, amplitude and envelope. That's about it. For the second type, you don't want a centering spring. You typically will drive a constant force effect with the engine, with some sprinkled damping and maybe a slight spring here and there. I would personally put more weight and effort to get the second type properly implemented. The players of those games demand more realism and they need the subtle force changes to drive better than the competition. That means having a FF driver that can deal with many force updates per second without choking and a consistent, reproducible force output at the device, maybe even similar across varying devices. This translates into a decoupled design for accepting force updates and sending USB updates, as well as a device-specific layer to "calibrate" and "unify" the force responses across different models. Does this make sense? thanks roland -- 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
> IMO, there are two types of games. The "arcade" ones, which have a set > of 'canned' force effects, which play whenever an event happens in game. > And the "simulation" ones, which base the game on a physics engine. The > latter can redirect some variables of their engine to the input layer > and typically drive a constant force and maybe a spring/damper too. > > For the first type, you might want to keep a centering spring active all > the time. Maybe you want to tweak the gain in the game settings. Maybe > there's a gain for the centering and one for the special effects. The > canned effects are mostly periodics with varying waveform, duration, > amplitude and envelope. That's about it. Sounds like these are the effect files produced by FEdit tool (from MS DirectX SDK), and/or played back by pressing buttons when configuring the Logitech driver on Windows ('wooden bridge', etc)... Do you know if there is a mechanism for playing these under Linux? Under Windows do games just send a 'file' the DirectX driver, or do they parse them into individual effects to send? If format is known/public it shouldn't be hard to write a userland client to play them back. If this needs to be supported in the kernel that would be more problematic. > For the second type, you don't want a centering spring. You typically > will drive a constant force effect with the engine, with some sprinkled > damping and maybe a slight spring here and there. > > I would personally put more weight and effort to get the second type > properly implemented. The players of those games demand more realism and > they need the subtle force changes to drive better than the competition. I would agree, these are probably more higher 'priority' but I think that the work Elias and Michal have done already implements these fairly well. I assume that most AAA games, would implement these through some middle layer. I think that is probably via Steam using SDL2 haptic API, we have been testing against SDL2's 'testhaptic'. Do you see another path (which we should be supporting/testing)? > That means having a FF driver that can deal with many force updates per > second without choking and a consistent, reproducible force output at > the device, maybe even similar across varying devices. This translates > into a decoupled design for accepting force updates and sending USB > updates, as well as a device-specific layer to "calibrate" and "unify" > the force responses across different models. There was some discussion about rate limiting the USB packets to the wheel, and how to deal if app updates too quickly. Is there an upper limit for the wheel itself, or is it just the USB 'pipe' which is the limiting factor? Simon -- 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
>> Regarding the question of emulated vs. real effects, can we extend the >> API >> so that applications can know which effects are really supported, and >> enable/disable emulation somehow? > > I suppose that a few extra flags (FF_PERIODIC_EMULATED etc.) defined in > "uapi/linux/input.h" should suffice. The only problem is that we probably want to maintain backward compatibility so that older apps still see 'PERIODIC' (even though it is emulated). -- #define FF_RUMBLE 0x50 #define FF_PERIODIC 0x51 #define FF_CONSTANT 0x52 #define FF_SPRING 0x53 #define FF_FRICTION 0x54 #define FF_DAMPER 0x55 #define FF_INERTIA 0x56 #define FF_RAMP 0x57 -- Do we therefore have to list extra items in our capabilities? -- static const signed short lg4ff_wheel_effects[] = { FF_CONSTANT, FF_PERIODIC, FF_PERIODIC_NOT_EMULATED, FF_AUTOCENTER, -1 }; -- Simon -- 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
On Tuesday 20 of May 2014 19:45:44 simon@mungewell.org wrote: > >> Regarding the question of emulated vs. real effects, can we extend the > >> API > >> so that applications can know which effects are really supported, and > >> enable/disable emulation somehow? > > > > I suppose that a few extra flags (FF_PERIODIC_EMULATED etc.) defined in > > "uapi/linux/input.h" should suffice. > > The only problem is that we probably want to maintain backward > compatibility so that older apps still see 'PERIODIC' (even though it is > emulated). > -- > #define FF_RUMBLE 0x50 > #define FF_PERIODIC 0x51 > #define FF_CONSTANT 0x52 > #define FF_SPRING 0x53 > #define FF_FRICTION 0x54 > #define FF_DAMPER 0x55 > #define FF_INERTIA 0x56 > #define FF_RAMP 0x57 > -- > > Do we therefore have to list extra items in our capabilities? > -- > static const signed short lg4ff_wheel_effects[] = { > FF_CONSTANT, > FF_PERIODIC, > FF_PERIODIC_NOT_EMULATED, > FF_AUTOCENTER, > -1 > }; > -- > > Simon Actually I was thinking something like this: "input.h" #define FF_DAMPER 0x55 #define FF_INERTIA 0x56 #define FF_RAMP 0x57 +# define FF_PERIODIC_EMULATED 0x58 +# define FF_RUMBLE_EMULATED 0x59 and in the future "library-like" reimplementation of MLNX: #define EMULATE_PERIODIC BIT(0) #define EMULATE_RUMBLE BIT(1) kfflib_init(..., EMULATE_PERIODIC | EMULATE_RUMBLE); for full emulation. 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
On 05/20/2014 04:30 PM, simon@mungewell.org wrote: > Sounds like these are the effect files produced by FEdit tool (from MS > DirectX SDK), and/or played back by pressing buttons when configuring the > Logitech driver on Windows ('wooden bridge', etc)... Prior to the FEdit tool, there was Immersion Studio [1]. It created IFR files, which were read using a DLL that Immersion provided. This DLL produced arrays of DIEFFECTs, which had specific durations and start offsets. By starting the entire array, you would get the desired effect. Most of the original effects in the Logitech Control Panel were done that way (by yours truly, as a matter of fact). To "sell" the effect, a sound-effect was queued concurrently with the force effect. (Trivia: part of the "Wooden bridge" sound effect was made by smashing a cigarette lighter against real wooden clogs of a co-worker, then slowing down the audio a bit.) In 2003, all of these effects were 'hardcoded' in a series of arrays of arrays of DI_EFFECTs. This allowed us to drop the Immersion loader DLL and create them on the fly. > Do you know if there is a mechanism for playing these under Linux? I don't - I'm fairly new to the Linux platform itself. > Under Windows do games just send a 'file' the DirectX driver, or do they > parse them into individual effects to send? With the IFR approach, you call a function in a library in userland with the filename, and it returns an array of effects. With the FEdit tool, you call a function on the IDirectInputDevice and calls a given callback the the loaded effects.[2] At the end of the day, you end up with a series of user-land effect structures. It's up to the 'game' to download and start them on a given device. > If format is known/public it shouldn't be hard to write a userland client > to play them back. The file format of an IFR is probably easily deducible. There's a lot of textual clues to parameters and the values are also written out in string form. I don't have a FEdit file at hand, but I suppose it will be similar. > I assume that most AAA games, would implement these through some middle > layer. I think that is probably via Steam using SDL2 haptic API, we have > been testing against SDL2's 'testhaptic'. I wasn't aware of this layer. I must read up on it. It sounds like a simple way to access force feedback - I guess a game developer should shed some light on this... > Do you see another path (which we should be supporting/testing)? Nope, not at this time. > There was some discussion about rate limiting the USB packets to the > wheel, and how to deal if app updates too quickly. Is there an upper limit > for the wheel itself, or is it just the USB 'pipe' which is the limiting > factor? On the Windows side we send 125 reports/sec. The entire simulation loop runs with a 8ms resolution. I assume this value was chosen for some hardware constraints back in the days, but it has proven to be a good compromise for simulated periodics and physics constraints. In any case, the USB traffic should be decoupled from the app. Any force updates should only change state in the ff-memless[-next] driver. Any change there should trickle down to a 'slot' representation of the device. If there's any change in the slots, the device is marked as 'dirty' and USB transfers are scheduled to send the latest state to the physical device. The scheduling should keep track of how many requests are in-flight and delay writing the next output, until the previous one has completed. Question back to the community: are there APIs in the USB layer to check for presence of in-progress requests? Can one add a 'completion' callback to a request, that gets invoked on completion/cancellation? Thanks roland -- [1] http://www.immersion.com/developers/index.php?option=com_content&view=article&id=423&Itemid=684 [2] http://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.idirectinputdevice8.idirectinputdevice8.enumeffectsinfile(v=vs.85).aspx -- 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
On Tuesday 20 of May 2014 18:17:51 Roland Bosa wrote: > > The file format of an IFR is probably easily deducible. There's a lot of > textual clues to parameters and the values are also written out in > string form. > > I don't have a FEdit file at hand, but I suppose it will be similar. I believe that Elias successfully reverse engineered the effect file format produced by FEdit. There is no support for this kind of prefabricated effects in the Linux FF API. > > I assume that most AAA games, would implement these through some middle > > layer. I think that is probably via Steam using SDL2 haptic API, we have > > been testing against SDL2's 'testhaptic'. > > I wasn't aware of this layer. I must read up on it. It sounds like a > simple way to access force feedback - I guess a game developer should > shed some light on this... > > > > Do you see another path (which we should be supporting/testing)? > > Nope, not at this time. > > > There was some discussion about rate limiting the USB packets to the > > wheel, and how to deal if app updates too quickly. Is there an upper limit > > for the wheel itself, or is it just the USB 'pipe' which is the limiting > > factor? > > On the Windows side we send 125 reports/sec. The entire simulation loop > runs with a 8ms resolution. I assume this value was chosen for some > hardware constraints back in the days, but it has proven to be a good > compromise for simulated periodics and physics constraints. Our current code uses 8 msecs delay as well. > In any case, the USB traffic should be decoupled from the app. Any force > updates should only change state in the ff-memless[-next] driver. Any > change there should trickle down to a 'slot' representation of the > device. If there's any change in the slots, the device is marked as > 'dirty' and USB transfers are scheduled to send the latest state to the > physical device. > > The scheduling should keep track of how many requests are in-flight and > delay writing the next output, until the previous one has completed. The approach I had in mind would keep track of the last effect that made it to the device and the last effect that arrived from userspace. This would be stored for each effect slot. An update would be scheduled at the desired update rate. The updating routine would figure out the state change between last update and "now", send the required data to the device and reschedule itself. The routine could check if there are any USB transfers still running and reschedule itself immediately. > Question back to the community: are there APIs in the USB layer to check > for presence of in-progress requests? Can one add a 'completion' > callback to a request, that gets invoked on completion/cancellation? For instance "usb_submit_urb()" can have a completion handler that is called once the transfer is done. The current code uses "hid_hw_request()" which is asynchronous and doesn't report anything back. Proper decoupling of the userspace and driver is the only important thing that is missing from the current code. 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
Elias, Simon, Michal, It is unfortunate that we didn't get back to you in 2013 when you asked for help in reverse engineering, oftentimes we have conflicting priorities and a particular request may be left laying around for some time before being addressed. But please, don't hesitate to re-kick us if you feel we are not being reactive. Let me clearly say that our intentions are to disclose as much information as possible and to help the community in having great support to all our hardware across all platforms. We have zero problem with being asked for information. Many thanks, -nestor On Wed, May 21, 2014 at 4:13 AM, Michal Malý <madcatxster@devoid-pointer.net> wrote: > > On Tuesday 20 of May 2014 18:17:51 Roland Bosa wrote: > > > > The file format of an IFR is probably easily deducible. There's a lot of > > textual clues to parameters and the values are also written out in > > string form. > > > > I don't have a FEdit file at hand, but I suppose it will be similar. > > I believe that Elias successfully reverse engineered the effect file format > produced by FEdit. There is no support for this kind of prefabricated effects > in the Linux FF API. > > > > I assume that most AAA games, would implement these through some middle > > > layer. I think that is probably via Steam using SDL2 haptic API, we have > > > been testing against SDL2's 'testhaptic'. > > > > I wasn't aware of this layer. I must read up on it. It sounds like a > > simple way to access force feedback - I guess a game developer should > > shed some light on this... > > > > > > > Do you see another path (which we should be supporting/testing)? > > > > Nope, not at this time. > > > > > There was some discussion about rate limiting the USB packets to the > > > wheel, and how to deal if app updates too quickly. Is there an upper limit > > > for the wheel itself, or is it just the USB 'pipe' which is the limiting > > > factor? > > > > On the Windows side we send 125 reports/sec. The entire simulation loop > > runs with a 8ms resolution. I assume this value was chosen for some > > hardware constraints back in the days, but it has proven to be a good > > compromise for simulated periodics and physics constraints. > > Our current code uses 8 msecs delay as well. > > > In any case, the USB traffic should be decoupled from the app. Any force > > updates should only change state in the ff-memless[-next] driver. Any > > change there should trickle down to a 'slot' representation of the > > device. If there's any change in the slots, the device is marked as > > 'dirty' and USB transfers are scheduled to send the latest state to the > > physical device. > > > > The scheduling should keep track of how many requests are in-flight and > > delay writing the next output, until the previous one has completed. > > The approach I had in mind would keep track of the last effect that made it to > the device and the last effect that arrived from userspace. This would be > stored for each effect slot. An update would be scheduled at the desired update > rate. The updating routine would figure out the state change between last > update and "now", send the required data to the device and reschedule itself. > The routine could check if there are any USB transfers still running and > reschedule itself immediately. > > > Question back to the community: are there APIs in the USB layer to check > > for presence of in-progress requests? Can one add a 'completion' > > callback to a request, that gets invoked on completion/cancellation? > > For instance "usb_submit_urb()" can have a completion handler that is called > once the transfer is done. The current code uses "hid_hw_request()" which is > asynchronous and doesn't report anything back. > > Proper decoupling of the userspace and driver is the only important thing that > is missing from the current code. > > 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 -- 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
On Wed, May 21, 2014 at 4:13 AM, Michal Malý <madcatxster@devoid-pointer.net> wrote: > On Tuesday 20 of May 2014 18:17:51 Roland Bosa wrote: >> In any case, the USB traffic should be decoupled from the app. Any force >> updates should only change state in the ff-memless[-next] driver. Any >> change there should trickle down to a 'slot' representation of the >> device. If there's any change in the slots, the device is marked as >> 'dirty' and USB transfers are scheduled to send the latest state to the >> physical device. >> >> The scheduling should keep track of how many requests are in-flight and >> delay writing the next output, until the previous one has completed. > > The approach I had in mind would keep track of the last effect that made it to > the device and the last effect that arrived from userspace. This would be > stored for each effect slot. An update would be scheduled at the desired update > rate. The updating routine would figure out the state change between last > update and "now", send the required data to the device and reschedule itself. > The routine could check if there are any USB transfers still running and > reschedule itself immediately. I've got another/(a more detailed?) idea about this: We can use round-robin scheduling for the slots, and use a priority queue for e.g. LED data or data that doesn't fit in the slot-methodology and doesn't permit in-between packets to be lost. And I believe that ff-memless-next should generate a periodic force with a constant/defined sample-period/update-rate, while the layer between ff-memless-next and USB transfers, i.e. the round-robin and priority queue scheduler, should send the dirty slots as soon as possible, i.e. when the USB pipe is clear or when some custom #maxAllowedPacketsInUsbBuffer (optimized for somewhere between latency and throughput) is not exceeded by the kernel USB queue. Now the question is, can we query the state of the kernel USB queue? Optionally, this method of packet scheduling could be used by other kernel drivers (even non-FF drivers) as well, and can further increase flexibility of ff-memless-next and the HW-specific drivers, and it will reduce code duplication. >> Question back to the community: are there APIs in the USB layer to check >> for presence of in-progress requests? Can one add a 'completion' >> callback to a request, that gets invoked on completion/cancellation? > > For instance "usb_submit_urb()" can have a completion handler that is called > once the transfer is done. The current code uses "hid_hw_request()" which is > asynchronous and doesn't report anything back. > > Proper decoupling of the userspace and driver is the only important thing that > is missing from the current code. Also dynamic updating of periodic effects is not yet supported in "ff-memless-next". This can also be important in simulation games (=second type), e.g. the "rFactor" game. Elias -- 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
On Wed, May 21, 2014 at 4:13 AM, Michal Malý <madcatxster@devoid-pointer.net> wrote: > On Tuesday 20 of May 2014 18:17:51 Roland Bosa wrote: >> >> The file format of an IFR is probably easily deducible. There's a lot of >> textual clues to parameters and the values are also written out in >> string form. >> >> I don't have a FEdit file at hand, but I suppose it will be similar. > > I believe that Elias successfully reverse engineered the effect file format > produced by FEdit. There is no support for this kind of prefabricated effects > in the Linux FF API. Of course I did, Simon, what did you expect? :P Here you are: http://www.winehq.org/pipermail/wine-devel/2014-February/103108.html It contains a description of the DInput effect file format (.ffe), a working Python script to load these files and dump their contents, as well as a bunch of example files and tests/results. The FFE file format is binary RIFF, if you're interested. But I prefer not to include such things in the Linux kernel, I believe this is the task of the userspace application. I'm planning to implement this function into Wine, but maybe SDL would benefit from similar functionality too (using an open file-format instead, of course)? Anyway, this is off-topic. Elias -- 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
On Wed, May 21, 2014 at 12:17 PM, Nestor Lopez Casado <nlopezcasad@logitech.com> wrote: > Elias, Simon, Michal, > > It is unfortunate that we didn't get back to you in 2013 when you > asked for help in reverse engineering, oftentimes we have conflicting > priorities and a particular request may be left laying around for some > time before being addressed. But please, don't hesitate to re-kick us > if you feel we are not being reactive. > > Let me clearly say that our intentions are to disclose as much > information as possible and to help the community in having great > support to all our hardware across all platforms. We have zero problem > with being asked for information. OK, thanks for your reply. Don't worry, I understand ;) Elias -- 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
On Wed, May 21, 2014 at 3:35 PM, Elias Vanderstuyft <elias.vds@gmail.com> wrote: > On Wed, May 21, 2014 at 4:13 AM, Michal Malý > <madcatxster@devoid-pointer.net> wrote: >> Proper decoupling of the userspace and driver is the only important thing that >> is missing from the current code. > > Also dynamic updating of periodic effects is not yet supported in > "ff-memless-next". > This can also be important in simulation games (=second type), e.g. > the "rFactor" game. Oh, and I forgot some other things that need to be mentioned: - Trigger-button is not yet implemented, as far as I know - Custom force effects, in Linux it is called FF_CUSTOM. (however I think we can neglect this effect for now) - Infinite iterations in the Linux FF API is not supported. @Roland: Now I understand why Logitech Windows drivers have bugs in the periodic implementation of the DInput specs: Logitech seems to have based their drivers on the Immersion Studio visualisation of the to-be-generated periodic effects, and these visualisations are not conform with the DInput specs of MSDN. Take a quick look at the MSDN specs for e.g. SawtoothUp: http://msdn.microsoft.com/en-us/library/windows/desktop/ee418719%28v=vs.85%29.aspx Now open the Immersion Studio (demo) and create a standard SawtoothUp effect, and look at the visualisation... It's wrong, right? Same applies for SawtoothDown and Triangle. Elias -- 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
On Tue, May 20, 2014 at 11:38 PM, Roland Bosa <rbosa@logitech.com> wrote: > On 05/20/2014 12:00 PM, Michal Mal? wrote: > There's a healthy amount of > code in the Windows driver that you would call 'quirks' which deals with > deciding how to allocate multiple springs and dampers to a single slot. But 2 Spring effects with different offsets and non-zero effective force can't be combined into a single slot (without streaming them with Constant force), right? > Sometimes, even the springs and dampers are being streamed in via the > constants force, but that requires (as you pointed out earlier) a fast > update rate and some "smartness" OK, is this method used when all force-slots are already full? Or is it only used for some specific (restricted) devices, such as devices with only 2 force slots? And in this case, is the position of the device monitored at a speed higher than 8ms, in order to keep the feedback-loop stable? Thanks, Elias -- 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
>> But 2 Spring effects with different offsets and non-zero effective >> force can't be combined into a single slot (without streaming them >> with Constant force), right? > > Yes - you cannot *download* two springs to a single slot. You need to > choose (allocate) one of them. The winner gets the slot. The losers go > somewhere else (they might get discarded, they might get simulated). In reverse engineering, I thought that a single slot could hold two rotational angles/points (at which a springs would start) and that that the direction could be set so that both acting in the same direction with different forces. -- Byte 2 - 0x_1 Byte 3 - Clockwise angle, nominally on left (0x00..0xFF - 0x00 is fully left) Byte 4 - Anti-Clockwise angle, nominally on right(0x00..0xFF) Byte 5 - L/R Proportion force, upper nibble clockwise + lower nibble anti-clockwise (each 0x0..0xF) Byte 6 - Reverse Direction; upper nibble clockwise + lower nibble anti-clockwise (each 0x0..0x1) Byte 7 - Force (0x00..0xFF) -- Ie. turning from fully left (00) with no force, you could hit a 'weak' spring (at 40) and then a 'stronger' spring (at 80). So to some degree you /can/ merge springs... but I'm not saying that you should :-). Simon -- 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
On Tue, May 20, 2014 at 11:26 PM, Elias Vanderstuyft <elias.vds@gmail.com> wrote: > On Tue, May 20, 2014 at 10:58 PM, Michal Malý > <madcatxster@devoid-pointer.net> wrote: >> On Tuesday 20 of May 2014 16:16:12 simon@mungewell.org wrote: >>> Regarding the question of emulated vs. real effects, can we extend the API >>> so that applications can know which effects are really supported, and >>> enable/disable emulation somehow? >> >> I suppose that a few extra flags (FF_PERIODIC_EMULATED etc.) defined in >> "uapi/linux/input.h" should suffice. > > @Dmitry: > Now that we're talking about API changes, I would like to propose some > additional things in the Linux FF API: > > - Possibility to *get* FF state variables, such as the value of the > current GAIN, and the current AUTOCENTER: > At the moment, only *setting* is possible. > This poses a problem when implementing proper AUTOCENTER state > recovery (upon closing a Windows program) in Wine, because the initial > AUTOCENTER state was unknown. > The same applies for GAIN. > > - Introduce multiple types of GAIN, apart from the current global > GAIN, e.g. GAIN_CONSTANT and GAIN_DAMPER: > This is mainly on request of some users, especially Logitech users: on > Windows Logitech additionally supports to set the global Damper and > Spring gain. > Maybe it would be nicer to create a global gain for every supported > Linux FF effect? And Roland Bosa (from Logitech) also agrees with the following addition/modification to the Linux FF API: - Infinite iterations, or in Linux FF terms: playback of an effect with an event count of infinity. Right now, an event count of zero stops the effect, while the maximum count is INT_MAX. An event count value of '-1' can be used to indicate infinity. (However note that it is somewhat inconsistent with the infinite effect "duration" we already support: in that case '0' is used) Is this feasible? (in terms of backward compatibility) Thanks, Elias -- 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
diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig index a11ff74..3780962 100644 --- a/drivers/input/Kconfig +++ b/drivers/input/Kconfig @@ -38,6 +38,17 @@ config INPUT_FF_MEMLESS To compile this driver as a module, choose M here: the module will be called ff-memless. +config INPUT_FF_MEMLESS_NEXT + tristate "New version of support for memoryless force-feedback devices" + help + Say Y here to enable a new version of support for memoryless force + feedback devices. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called ff-memless-next. + config INPUT_POLLDEV tristate "Polled input device skeleton" help diff --git a/drivers/input/Makefile b/drivers/input/Makefile index 5ca3f63..b4f11f5 100644 --- a/drivers/input/Makefile +++ b/drivers/input/Makefile @@ -8,6 +8,7 @@ obj-$(CONFIG_INPUT) += input-core.o input-core-y := input.o input-compat.o input-mt.o ff-core.o obj-$(CONFIG_INPUT_FF_MEMLESS) += ff-memless.o +obj-$(CONFIG_INPUT_FF_MEMLESS_NEXT) += ff-memless-next.o obj-$(CONFIG_INPUT_POLLDEV) += input-polldev.o obj-$(CONFIG_INPUT_SPARSEKMAP) += sparse-keymap.o obj-$(CONFIG_INPUT_MATRIXKMAP) += matrix-keymap.o diff --git a/drivers/input/ff-memless-next.c b/drivers/input/ff-memless-next.c new file mode 100644 index 0000000..24619e9 --- /dev/null +++ b/drivers/input/ff-memless-next.c @@ -0,0 +1,1037 @@ +/* + * Force feedback support for memoryless devices + * + * This module is based on "ff-memless" orignally written by Anssi Hannula. + * It is extended to support all force feedback effects currently supported + * by the Linux input stack. + * Logic of emulation of FF_RUMBLE through FF_PERIODIC provided by + * Elias Vanderstuyft <elias.vds@gmail.com> + * + * Copyright(c) 2014 Michal "MadCatX" Maly <madcatxster@devoid-pointer.net> + * + */ + +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + +#include <linux/slab.h> +#include <linux/module.h> +#include <linux/mutex.h> +#include <linux/spinlock.h> +#include <linux/jiffies.h> +#include <linux/fixp-arith.h> +#include <linux/input/ff-memless-next.h> + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Michal \"MadCatX\" Maly"); +MODULE_DESCRIPTION("Force feedback support for memoryless force feedback devices"); + +#define FF_MAX_EFFECTS 16 +#define FF_MIN_EFFECT_LENGTH ((MSEC_PER_SEC / CONFIG_HZ) + 1) +#define FF_EFFECT_STARTED 1 +#define FF_EFFECT_PLAYING 2 +#define FF_EFFECT_EMULATED 3 + +enum mlnx_emulate { + EMUL_NOTHING, /* Do not emulate anything */ + EMUL_RUMBLE, /* Emulate FF_RUMBLE with FF_PERIODIC */ + EMUL_PERIODIC /* Emulate FF_PERIODIC with FF_RUMBLE */ +}; + +struct mlnx_effect { + struct ff_effect effect; + unsigned long flags; + unsigned long begin_at; + unsigned long stop_at; + unsigned long updated_at; + unsigned long attack_stop; + unsigned long fade_begin; + int repeat; +}; + +struct mlnx_device { + u8 combinable_playing; + u8 rumble_playing; + unsigned long update_rate_jiffies; + void *private; + struct mlnx_effect effects[FF_MAX_EFFECTS]; + u16 gain; + struct timer_list timer; + struct input_dev *dev; + enum mlnx_emulate emul; + + int (*control_effect)(struct input_dev *, void *, + const struct mlnx_effect_command *); +}; + +static s32 mlnx_calculate_x_force(const s32 level, + const u16 direction) +{ + s32 new = (level * -fixp_sin(direction)) >> FRAC_N; + pr_debug("x force: %d\n", new); + return new; +} + +static s32 mlnx_calculate_y_force(const s32 level, + const u16 direction) +{ + s32 new = (level * fixp_cos(direction)) >> FRAC_N; + pr_debug("y force: %d\n", new); + return new; +} + +static bool mlnx_is_combinable(const struct ff_effect *effect) +{ + switch (effect->type) { + case FF_CONSTANT: + case FF_PERIODIC: + case FF_RAMP: + return true; + default: + return false; + } +} + +static bool mlnx_is_conditional(const struct ff_effect *effect) +{ + switch (effect->type) { + case FF_DAMPER: + case FF_FRICTION: + case FF_INERTIA: + case FF_SPRING: + return true; + default: + return false; + } +} + +static void mlnx_clr_emulated(struct mlnx_effect *mlnxeff) +{ + __clear_bit(FF_EFFECT_EMULATED, &mlnxeff->flags); +} + +static void mlnx_clr_playing(struct mlnx_effect *mlnxeff) +{ + __clear_bit(FF_EFFECT_PLAYING, &mlnxeff->flags); +} + +static void mlnx_clr_started(struct mlnx_effect *mlnxeff) +{ + __clear_bit(FF_EFFECT_STARTED, &mlnxeff->flags); +} + +static bool mlnx_is_emulated(const struct mlnx_effect *mlnxeff) +{ + return test_bit(FF_EFFECT_EMULATED, &mlnxeff->flags); +} + +static bool mlnx_is_rumble(const struct ff_effect *effect) +{ + return effect->type == FF_RUMBLE; +} + +static bool mlnx_is_playing(const struct mlnx_effect *mlnxeff) +{ + return test_bit(FF_EFFECT_PLAYING, &mlnxeff->flags); +} + +static bool mlnx_is_started(const struct mlnx_effect *mlnxeff) +{ + return test_bit(FF_EFFECT_STARTED, &mlnxeff->flags); +} + +static bool mlnx_test_set_playing(struct mlnx_effect *mlnxeff) +{ + return test_and_set_bit(FF_EFFECT_PLAYING, &mlnxeff->flags); +} + +static const struct ff_envelope *mlnx_get_envelope(const struct ff_effect *effect) +{ + static const struct ff_envelope empty; + + switch (effect->type) { + case FF_CONSTANT: + return &effect->u.constant.envelope; + case FF_PERIODIC: + return &effect->u.periodic.envelope; + case FF_RAMP: + return &effect->u.ramp.envelope; + default: + return ∅ + } +} + +/* Some devices might have a limit on how many uncombinable effects + * can be played at once */ +static int mlnx_upload_conditional(struct mlnx_device *mlnxdev, + const struct ff_effect *effect) +{ + struct mlnx_effect_command ecmd = { + .cmd = MLNX_UPLOAD_UNCOMB, + .u.uncomb.id = effect->id, + .u.uncomb.effect = effect + }; + return mlnxdev->control_effect(mlnxdev->dev, mlnxdev->private, &ecmd); +} + +static int mlnx_erase_conditional(struct mlnx_device *mlnxdev, + const struct ff_effect *effect) +{ + struct mlnx_effect_command ecmd = { + .cmd = MLNX_ERASE_UNCOMB, + .u.uncomb.id = effect->id, + .u.uncomb.effect = effect + }; + return mlnxdev->control_effect(mlnxdev->dev, mlnxdev->private, &ecmd); +} + +static void mlnx_set_envelope_times(struct mlnx_effect *mlnxeff) +{ + const struct ff_effect *effect = &mlnxeff->effect; + const struct ff_envelope *envelope = mlnx_get_envelope(effect); + + if (envelope->attack_length) { + unsigned long j = msecs_to_jiffies(envelope->attack_length); + mlnxeff->attack_stop = mlnxeff->begin_at + j; + } + if (effect->replay.length && envelope->fade_length) { + unsigned long j = msecs_to_jiffies(envelope->fade_length); + mlnxeff->fade_begin = mlnxeff->stop_at - j; + } +} + +static void mlnx_set_trip_times(struct mlnx_effect *mlnxeff, + const unsigned long now) +{ + const struct ff_effect *effect = &mlnxeff->effect; + const u16 replay_delay = effect->replay.delay; + const u16 replay_length = effect->replay.length; + + mlnxeff->begin_at = now + msecs_to_jiffies(replay_delay); + mlnxeff->stop_at = mlnxeff->begin_at + msecs_to_jiffies(replay_length); + mlnxeff->updated_at = mlnxeff->begin_at; +} + +static void mlnx_start_effect(struct mlnx_effect *mlnxeff) +{ + const unsigned long now = jiffies; + + mlnx_set_trip_times(mlnxeff, now); + mlnx_set_envelope_times(mlnxeff); + __set_bit(FF_EFFECT_STARTED, &mlnxeff->flags); +} + +static void mlnx_stop_effect(struct mlnx_device *mlnxdev, + const struct mlnx_effect *mlnxeff) +{ + switch (mlnxeff->effect.type) { + case FF_PERIODIC: + if (mlnx_is_emulated(mlnxeff)) { + if (--mlnxdev->rumble_playing == 0) { + const struct mlnx_effect_command c = { + .cmd = MLNX_STOP_RUMBLE + }; + mlnxdev->control_effect(mlnxdev->dev, + mlnxdev->private, &c); + } + return; + } + case FF_CONSTANT: + case FF_RAMP: + if (--mlnxdev->combinable_playing == 0) { + const struct mlnx_effect_command c = { + .cmd = MLNX_STOP_COMBINED + }; + mlnxdev->control_effect(mlnxdev->dev, mlnxdev->private, + &c); + } + return; + case FF_RUMBLE: + if (mlnx_is_emulated(mlnxeff)) { + if (--mlnxdev->combinable_playing == 0) { + const struct mlnx_effect_command c = { + .cmd = MLNX_STOP_COMBINED + }; + mlnxdev->control_effect(mlnxdev->dev, + mlnxdev->private, &c); + } + } else { + if (--mlnxdev->rumble_playing == 0) { + const struct mlnx_effect_command c = { + .cmd = MLNX_STOP_RUMBLE + }; + mlnxdev->control_effect(mlnxdev->dev, + mlnxdev->private, &c); + } + } + return; + case FF_DAMPER: + case FF_FRICTION: + case FF_INERTIA: + case FF_SPRING: + { + const struct mlnx_effect_command c = { + .cmd = MLNX_STOP_UNCOMB, + .u.uncomb.id = mlnxeff->effect.id, + .u.uncomb.effect = &mlnxeff->effect + }; + mlnxdev->control_effect(mlnxdev->dev, mlnxdev->private, &c); + return; + } + default: + return; + } +} + +static int mlnx_restart_effect(struct mlnx_device *mlnxdev, + struct mlnx_effect *mlnxeff) +{ + const struct ff_effect *effect = &mlnxeff->effect; + const unsigned long now = jiffies; + + if (mlnx_is_combinable(effect)) { + if (effect->replay.delay) + mlnx_stop_effect(mlnxdev, mlnxeff); + else { + if (mlnx_is_emulated(mlnxeff)) + mlnxdev->rumble_playing--; + else + mlnxdev->combinable_playing--; + } + } else if (mlnx_is_rumble(effect)) { + if (effect->replay.delay) + mlnx_stop_effect(mlnxdev, mlnxeff); + else { + if (mlnx_is_emulated(mlnxeff)) + mlnxdev->combinable_playing--; + else + mlnxdev->rumble_playing--; + } + } else if (mlnx_is_conditional(effect)) { + int ret; + if (effect->replay.delay) + mlnx_stop_effect(mlnxdev, mlnxeff); + + ret = mlnx_upload_conditional(mlnxdev, &mlnxeff->effect); + if (ret) + return ret; + } + + mlnx_set_trip_times(mlnxeff, now); + mlnx_set_envelope_times(mlnxeff); + + return 0; +} + +static s32 mlnx_apply_envelope(const struct mlnx_effect *mlnxeff, + const s32 level) +{ + const struct ff_effect *effect = &mlnxeff->effect; + const struct ff_envelope *envelope = mlnx_get_envelope(effect); + const unsigned long now = jiffies; + const s32 alevel = abs(level); + + /* Effect has an envelope with nonzero attack time */ + if (envelope->attack_length && time_before(now, mlnxeff->attack_stop)) { + const s32 clength = jiffies_to_msecs(now - mlnxeff->begin_at); + const s32 alength = envelope->attack_length; + const s32 dlevel = (alevel - envelope->attack_level) + * clength / alength; + return level < 0 ? -(dlevel + envelope->attack_level) : + (dlevel + envelope->attack_level); + } else if (envelope->fade_length && time_before_eq(mlnxeff->fade_begin, now)) { + const s32 clength = jiffies_to_msecs(now - mlnxeff->fade_begin); + const s32 flength = envelope->fade_length; + const s32 dlevel = (envelope->fade_level - alevel) + * clength / flength; + return level < 0 ? -(dlevel + alevel) : (dlevel + alevel); + } + + return level; +} + +static s32 mlnx_calculate_periodic(struct mlnx_effect *mlnxeff, const s32 level) +{ + const struct ff_effect *effect = &mlnxeff->effect; + const unsigned long now = jiffies; + const u16 period = effect->u.periodic.period; + const u16 phase = effect->u.periodic.phase; + const s16 offset = effect->u.periodic.offset; + s32 new = level; + u16 t = (jiffies_to_msecs(now - mlnxeff->begin_at) + phase) % period; + + switch (effect->u.periodic.waveform) { + case FF_SINE: + { + u16 degrees = (360 * t) / period; + new = ((level * fixp_sin(degrees)) >> FRAC_N) + offset; + break; + } + case FF_SQUARE: + { + u16 degrees = (360 * t) / period; + new = level * (degrees < 180 ? 1 : -1) + offset; + break; + } + case FF_SAW_UP: + new = 2 * level * t / period - level + offset; + break; + case FF_SAW_DOWN: + new = level - 2 * level * t / period + offset; + break; + case FF_TRIANGLE: + { + new = (2 * abs(level - (2 * level * t) / period)); + new = new - abs(level) + offset; + break; + } + case FF_CUSTOM: + pr_debug("Custom waveform is not handled by this driver\n"); + return level; + default: + pr_err("Invalid waveform\n"); + return level; + } + + /* Ensure that the offset did not make the value exceed s16 range */ + new = clamp(new, -0x7fff, 0x7fff); + pr_debug("level: %d, t: %u\n", new, t); + return new; +} + +static s32 mlnx_calculate_ramp(const struct mlnx_effect *mlnxeff) +{ + const struct ff_effect *effect = &mlnxeff->effect; + const struct ff_envelope *envelope = mlnx_get_envelope(effect); + const unsigned long now = jiffies; + const u16 length = effect->replay.length; + const s16 mean = (effect->u.ramp.start_level + effect->u.ramp.end_level) / 2; + const u16 t = jiffies_to_msecs(now - mlnxeff->begin_at); + s32 start = effect->u.ramp.start_level; + s32 end = effect->u.ramp.end_level; + s32 new; + + if (envelope->attack_length && time_before(now, mlnxeff->attack_stop)) { + const s32 clength = jiffies_to_msecs(now - mlnxeff->begin_at); + const s32 alength = envelope->attack_length; + s32 attack_level; + if (end > start) + attack_level = mean - envelope->attack_level; + else + attack_level = mean + envelope->attack_level; + start = (start - attack_level) * clength / alength + + attack_level; + } else if (envelope->fade_length && time_before_eq(mlnxeff->fade_begin, now)) { + const s32 clength = jiffies_to_msecs(now - mlnxeff->fade_begin); + const s32 flength = envelope->fade_length; + s32 fade_level; + if (end > start) + fade_level = mean + envelope->fade_level; + else + fade_level = mean - envelope->fade_level; + end = (fade_level - end) * clength / flength + end; + } + + new = ((end - start) * t) / length + start; + new = clamp(new, -0x7fff, 0x7fff); + pr_debug("RAMP level: %d, t: %u\n", new, t); + return new; +} + +static void mlnx_destroy(struct ff_device *dev) +{ + struct mlnx_device *mlnxdev = dev->private; + del_timer_sync(&mlnxdev->timer); + + kfree(mlnxdev->private); +} + +static unsigned long mlnx_get_envelope_update_time(const struct mlnx_effect *mlnxeff, + const unsigned long update_rate_jiffies) +{ + const struct ff_effect *effect = &mlnxeff->effect; + const struct ff_envelope *envelope = mlnx_get_envelope(effect); + const unsigned long now = jiffies; + unsigned long fade_next; + + /* Effect has an envelope with nonzero attack time */ + if (envelope->attack_length && time_before(now, mlnxeff->attack_stop)) { + if (time_before(mlnxeff->updated_at + update_rate_jiffies, mlnxeff->attack_stop)) + return mlnxeff->updated_at + update_rate_jiffies; + + return mlnxeff->attack_stop; + } + + /* Effect has an envelope with nonzero fade time */ + if (mlnxeff->effect.replay.length) { + if (!envelope->fade_length) + return mlnxeff->stop_at; + + /* Schedule the next update when the fade begins */ + if (time_before(mlnxeff->updated_at, mlnxeff->fade_begin)) + return mlnxeff->fade_begin; + + /* Already fading */ + fade_next = mlnxeff->updated_at + update_rate_jiffies; + + /* Schedule update when the effect stops */ + if (time_after(fade_next, mlnxeff->stop_at)) + return mlnxeff->stop_at; + /* Schedule update at the next checkpoint */ + return fade_next; + } + + /* There is no envelope */ + + /* Prevent the effect from being started twice */ + if (mlnxeff->begin_at == now && mlnx_is_playing(mlnxeff)) + return now - 1; + + return mlnxeff->begin_at; +} + +static unsigned long mlnx_get_update_time(struct mlnx_effect *mlnxeff, + const unsigned long update_rate_jiffies) +{ + const unsigned long now = jiffies; + unsigned long time, update_periodic; + + switch (mlnxeff->effect.type) { + /* Constant effect does not change with time, but it can have + * an envelope and a duration */ + case FF_CONSTANT: + return mlnx_get_envelope_update_time(mlnxeff, + update_rate_jiffies); + /* Periodic and ramp effects have to be periodically updated */ + case FF_PERIODIC: + case FF_RAMP: + time = mlnx_get_envelope_update_time(mlnxeff, + update_rate_jiffies); + if (mlnx_is_emulated(mlnxeff)) + update_periodic = mlnxeff->stop_at; + else + update_periodic = mlnxeff->updated_at + + update_rate_jiffies; + + /* Periodic effect has to be updated earlier than envelope + * or envelope update time is in the past */ + if (time_before(update_periodic, time) || time_before(time, now)) + return update_periodic; + /* Envelope needs to be updated */ + return time; + case FF_RUMBLE: + if (mlnx_is_emulated(mlnxeff)) + return mlnxeff->updated_at + update_rate_jiffies; + case FF_DAMPER: + case FF_FRICTION: + case FF_INERTIA: + case FF_SPRING: + default: + if (time_after_eq(mlnxeff->begin_at, now)) + return mlnxeff->begin_at; + + return mlnxeff->stop_at; + } +} + +static void mlnx_schedule_playback(struct mlnx_device *mlnxdev) +{ + struct mlnx_effect *mlnxeff; + const unsigned long now = jiffies; + int events = 0; + int i; + unsigned long earliest = 0; + unsigned long time; + + /* Iterate over all effects and determine the earliest + * time when we have to attend to any */ + for (i = 0; i < FF_MAX_EFFECTS; i++) { + mlnxeff = &mlnxdev->effects[i]; + + if (!mlnx_is_started(mlnxeff)) + continue; /* Effect is not started, skip it */ + + if (mlnx_is_playing(mlnxeff)) + time = mlnx_get_update_time(mlnxeff, + mlnxdev->update_rate_jiffies); + else + time = mlnxeff->begin_at; + + pr_debug("Update time for effect %d: %lu\n", i, time); + + /* Scheduled time is in the future and is either + * before the current earliest time or it is + * the first valid time value in this pass */ + if (time_before_eq(now, time) && + (++events == 1 || time_before(time, earliest))) + earliest = time; + } + + if (events) { + pr_debug("Events: %d, earliest: %lu\n", events, earliest); + mod_timer(&mlnxdev->timer, earliest); + } else { + pr_debug("No events, deactivating timer\n"); + del_timer(&mlnxdev->timer); + } +} + +static u16 mlnx_calculate_rumble_direction(const u32 total_mag, const u16 total_dir, + const u32 new_mag, const u16 new_dir) +{ + if (!new_mag) + return total_dir; + if (!total_mag) + return new_dir; + return (((total_dir >> 1) * total_mag + + (new_dir >> 1) * new_mag) / + (total_mag + new_mag)) << 1; +} + +static void mlnx_add_force(struct mlnx_effect *mlnxeff, s32 *cfx, s32 *cfy, + const u16 gain) +{ + const struct ff_effect *effect = &mlnxeff->effect; + u16 direction; + s32 level; + + pr_debug("Processing effect type %d, ID %d\n", + mlnxeff->effect.type, mlnxeff->effect.id); + + direction = mlnxeff->effect.direction * 360 / 0xffff; + pr_debug("Direction deg: %u\n", direction); + + switch (mlnxeff->effect.type) { + case FF_CONSTANT: + level = mlnx_apply_envelope(mlnxeff, effect->u.constant.level); + break; + case FF_PERIODIC: + level = mlnx_apply_envelope(mlnxeff, + effect->u.periodic.magnitude); + level = mlnx_calculate_periodic(mlnxeff, level); + break; + case FF_RAMP: + level = mlnx_calculate_ramp(mlnxeff); + break; + default: + pr_err("Effect %d not handled by mlnx_add_force\n", + mlnxeff->effect.type); + return; + } + + *cfx += mlnx_calculate_x_force(level, direction) * gain / 0xffff; + *cfy += mlnx_calculate_y_force(level, direction) * gain / 0xffff; +} + +static void mlnx_add_rumble(const struct mlnx_effect *mlnxeff, u32 *strong_mag, + u32 *weak_mag, u16 *strong_dir, + u16 *weak_dir, const u16 gain) +{ + const struct ff_effect *eff = &mlnxeff->effect; + const struct ff_rumble_effect *reff = &mlnxeff->effect.u.rumble; + const u32 new_strong_mag = (u32)reff->strong_magnitude * gain / 0xffffU; + const u32 new_weak_mag = (u32)reff->weak_magnitude * gain / 0xffffU; + + *strong_dir = mlnx_calculate_rumble_direction(*strong_mag, *strong_dir, + new_strong_mag, + eff->direction); + *weak_dir = mlnx_calculate_rumble_direction(*weak_mag, *weak_dir, + new_weak_mag, + eff->direction); + *strong_mag += new_strong_mag; + *weak_mag += new_weak_mag; +} + +static void mlnx_add_emul_periodic(const struct mlnx_effect *mlnxeff, + u32 *strong_mag, u32 *weak_mag, + u16 *strong_dir, u16 *weak_dir, + const u16 gain) +{ + const struct ff_effect *eff = &mlnxeff->effect; + const u32 level = (u32)abs(mlnx_apply_envelope(mlnxeff, + eff->u.periodic.magnitude)) * gain / 0x7fffU; + + *strong_dir = mlnx_calculate_rumble_direction(*strong_mag, *strong_dir, + level, eff->direction); + *weak_dir = mlnx_calculate_rumble_direction(*weak_mag, *weak_dir, + level, eff->direction); + + *strong_mag += level; + *weak_mag += level; +} + +static void mlnx_add_emul_rumble(const struct mlnx_effect *mlnxeff, s32 *cfx, + s32 *cfy, const u16 gain, + const unsigned long now, + const unsigned long update_rate_jiffies) +{ + const struct ff_effect *effect = &mlnxeff->effect; + const u16 strong = effect->u.rumble.strong_magnitude; + const u16 weak = effect->u.rumble.weak_magnitude; + /* To calculate 't', we pretend that mlnxeff->begin_at == 0, thus t == now. */ + /* This will synchronise all simultaneously playing emul rumble effects, */ + /* otherwise non-deterministic phase-inversions could occur depending on */ + /* upload time, which could lead to undesired cancellation of these effects. */ + const unsigned long t = now % (4UL * update_rate_jiffies); + s32 level = 0; + bool direction_up; + bool direction_left; + + if (strong) + level += (strong / 4) * (t < 2UL * update_rate_jiffies ? 1 : -1); + if (weak) + level += (weak / 4) * (t < 2UL * update_rate_jiffies ? + (t < 1UL * update_rate_jiffies ? 1 : -1) : + (t < 3UL * update_rate_jiffies ? 1 : -1)); + direction_up = (effect->direction > 0x3fffU && effect->direction <= 0xbfffU); + direction_left = (effect->direction <= 0x7fffU); + + pr_debug("Emulated cf: %d, t: %lu, n: %lu, begin: %lu, diff: %lu j: %lu\n", + level, t, now, mlnxeff->begin_at, now - mlnxeff->begin_at, + update_rate_jiffies); + level = (level * gain) / 0xffff; + *cfx += direction_left ? -level : level; + *cfy += direction_up ? -level : level; +} + +static void mlnx_play_effects(struct mlnx_device *mlnxdev) +{ + const u16 gain = mlnxdev->gain; + const unsigned long now = jiffies; + int i; + s32 cfx = 0; + s32 cfy = 0; + u32 strong_mag = 0; + u32 weak_mag = 0; + u16 strong_dir = 0; + u16 weak_dir = 0; + + for (i = 0; i < FF_MAX_EFFECTS; i++) { + struct mlnx_effect *mlnxeff = &mlnxdev->effects[i]; + + if (!mlnx_is_started(mlnxeff)) { + pr_debug("Effect %hd/%d not started\n", + mlnxeff->effect.id, i); + continue; + } + + if (time_before(now, mlnxeff->begin_at)) { + pr_debug("Effect %hd/%d begins at a later time\n", + mlnxeff->effect.id, i); + continue; + } + + if (time_before_eq(mlnxeff->stop_at, now) && mlnxeff->effect.replay.length) { + pr_debug("Effect %hd/%d has to be stopped\n", + mlnxeff->effect.id, i); + + mlnx_clr_playing(mlnxeff); + if (--mlnxeff->repeat > 0) + mlnx_restart_effect(mlnxdev, mlnxeff); + else { + mlnx_stop_effect(mlnxdev, mlnxeff); + mlnx_clr_started(mlnxeff); + mlnx_clr_emulated(mlnxeff); + if (mlnx_is_conditional(&mlnxeff->effect)) + mlnx_erase_conditional(mlnxdev, &mlnxeff->effect); + } + + continue; + } + + switch (mlnxeff->effect.type) { + case FF_PERIODIC: + if (mlnxdev->emul == EMUL_PERIODIC) { + if (!mlnx_test_set_playing(mlnxeff)) { + mlnxdev->rumble_playing++; + pr_debug("Starting emul periodic, total rumble %u\n", + mlnxdev->rumble_playing); + } + __set_bit(FF_EFFECT_EMULATED, &mlnxeff->flags); + mlnx_add_emul_periodic(mlnxeff, &strong_mag, &weak_mag, + &strong_dir, &weak_dir, gain); + break; + } + case FF_CONSTANT: + case FF_RAMP: + if (!mlnx_test_set_playing(mlnxeff)) { + mlnxdev->combinable_playing++; + pr_debug("Starting combinable effect, total %u\n", + mlnxdev->combinable_playing); + } + mlnx_add_force(mlnxeff, &cfx, &cfy, gain); + break; + case FF_RUMBLE: + if (mlnxdev->emul == EMUL_RUMBLE) { + if (!mlnx_test_set_playing(mlnxeff)) { + mlnxdev->combinable_playing++; + pr_debug("Starting emul rumble, total comb %u\n", + mlnxdev->combinable_playing); + } + __set_bit(FF_EFFECT_EMULATED, &mlnxeff->flags); + mlnx_add_emul_rumble(mlnxeff, &cfx, &cfy, gain, now, + mlnxdev->update_rate_jiffies); + } else { + if (!mlnx_test_set_playing(mlnxeff)) { + mlnxdev->rumble_playing++; + pr_debug("Starting rumble effect, total %u\n", + mlnxdev->rumble_playing); + } + mlnx_add_rumble(mlnxeff, &strong_mag, &weak_mag, + &strong_dir, &weak_dir, gain); + } + break; + case FF_DAMPER: + case FF_FRICTION: + case FF_INERTIA: + case FF_SPRING: + if (!mlnx_test_set_playing(mlnxeff)) { + const struct mlnx_effect_command ecmd = { + .cmd = MLNX_START_UNCOMB, + .u.uncomb.id = i, + .u.uncomb.effect = &mlnxeff->effect + }; + mlnxdev->control_effect(mlnxdev->dev, + mlnxdev->private, &ecmd); + } + break; + default: + pr_debug("Unhandled type of effect\n"); + } + mlnxeff->updated_at = now; + } + + if (mlnxdev->combinable_playing) { + const struct mlnx_effect_command ecmd = { + .cmd = MLNX_START_COMBINED, + .u.simple_force = { + .x = clamp(cfx, -0x7fff, 0x7fff), + .y = clamp(cfy, -0x7fff, 0x7fff) + } + }; + mlnxdev->control_effect(mlnxdev->dev, mlnxdev->private, &ecmd); + } + if (mlnxdev->rumble_playing) { + const struct mlnx_effect_command ecmd = { + .cmd = MLNX_START_RUMBLE, + .u.rumble_force = { + .strong = clamp(strong_mag, (u32)0, (u32)0xffffU), + .weak = clamp(weak_mag, (u32)0, (u32)0xffffU), + .strong_dir = clamp(strong_dir, (u16)0, (u16)0xffffU), + .weak_dir = clamp(weak_dir, (u16)0, (u16)0xffffU) + } + }; + mlnxdev->control_effect(mlnxdev->dev, mlnxdev->private, &ecmd); + } + + mlnx_schedule_playback(mlnxdev); +} + +static void mlnx_set_gain(struct input_dev *dev, u16 gain) +{ + struct mlnx_device *mlnxdev = dev->ff->private; + int i; + + mlnxdev->gain = gain; + + for (i = 0; i < FF_MAX_EFFECTS; i++) { + struct mlnx_effect *eff = &mlnxdev->effects[i]; + if (eff == NULL) + continue; + if (mlnx_is_playing(eff)) { + if (mlnx_is_combinable(&eff->effect)) { + mlnx_clr_playing(eff); + if (mlnx_is_emulated(eff)) + --mlnxdev->rumble_playing; + else + --mlnxdev->combinable_playing; + } else if (mlnx_is_rumble(&eff->effect)) { + mlnx_clr_playing(eff); + if (mlnx_is_emulated(eff)) + --mlnxdev->combinable_playing; + else + --mlnxdev->rumble_playing; + } + } + } + + mlnx_play_effects(mlnxdev); +} + +static int mlnx_startstop(struct input_dev *dev, int effect_id, int repeat) +{ + struct mlnx_device *mlnxdev = dev->ff->private; + struct mlnx_effect *mlnxeff = &mlnxdev->effects[effect_id]; + int ret; + + if (repeat > 0) { + pr_debug("Starting effect ID %d\n", effect_id); + mlnxeff->repeat = repeat; + + if (!mlnx_is_started(mlnxeff)) { + /* Check that device has a free effect slot */ + if (mlnx_is_conditional(&mlnxeff->effect)) { + ret = mlnx_upload_conditional(mlnxdev, &mlnxeff->effect); + if (ret) { + /* Device effect slots are all occupied */ + pr_debug("No free effect slot for EID %d\n", effect_id); + return ret; + } + } + mlnx_start_effect(mlnxeff); + } + } else { + pr_debug("Stopping effect ID %d\n", effect_id); + if (mlnx_is_started(mlnxeff)) { + if (mlnx_is_playing(mlnxeff)) { + mlnx_clr_playing(mlnxeff); + mlnx_stop_effect(mlnxdev, mlnxeff); + } + mlnx_clr_started(mlnxeff); + mlnx_clr_emulated(mlnxeff); + + if (mlnx_is_conditional(&mlnxeff->effect)) + return mlnx_erase_conditional(mlnxdev, &mlnxeff->effect); + } else { + pr_debug("Effect ID %d already stopped\n", effect_id); + return 0; + } + } + mlnx_play_effects(mlnxdev); + + return 0; +} + +static void mlnx_timer_fired(unsigned long data) +{ + struct input_dev *dev = (struct input_dev *)data; + unsigned long flags; + + spin_lock_irqsave(&dev->event_lock, flags); + mlnx_play_effects(dev->ff->private); + spin_unlock_irqrestore(&dev->event_lock, flags); +} + +static int mlnx_upload(struct input_dev *dev, struct ff_effect *effect, + struct ff_effect *old) +{ + struct mlnx_device *mlnxdev = dev->ff->private; + struct mlnx_effect *mlnxeff = &mlnxdev->effects[effect->id]; + const u16 length = effect->replay.length; + const u16 delay = effect->replay.delay; + int ret, fade_from; + + /* Effect's timing is below kernel timer resolution */ + if (length && length < FF_MIN_EFFECT_LENGTH) + effect->replay.length = FF_MIN_EFFECT_LENGTH; + if (delay && delay < FF_MIN_EFFECT_LENGTH) + effect->replay.delay = FF_MIN_EFFECT_LENGTH; + + /* Periodic effects must have a non-zero period */ + if (effect->type == FF_PERIODIC) { + if (!effect->u.periodic.period) + return -EINVAL; + } + /* Ramp effects cannot be infinite */ + if (effect->type == FF_RAMP && !length) + return -EINVAL; + + if (mlnx_is_combinable(effect)) { + const struct ff_envelope *envelope = mlnx_get_envelope(effect); + + /* Infinite effects cannot fade */ + if (!length && envelope->fade_length > 0) + return -EINVAL; + /* Fade length cannot be greater than effect duration */ + fade_from = (int)length - (int)envelope->fade_length; + if (fade_from < 0) + return -EINVAL; + /* Envelope cannot start fading before it finishes attacking */ + if (fade_from < envelope->attack_length && fade_from > 0) + return -EINVAL; + } + + + spin_lock_irq(&dev->event_lock); + mlnxeff->effect = *effect; /* Keep internal copy of the effect */ + /* Check if the effect being modified is playing */ + if (mlnx_is_started(mlnxeff)) { + if (mlnx_is_playing(mlnxeff)) { + mlnx_clr_playing(mlnxeff); + ret = mlnx_restart_effect(mlnxdev, mlnxeff); + + if (ret) { + /* Restore the original effect */ + if (old) + mlnxeff->effect = *old; + spin_unlock_irq(&dev->event_lock); + return ret; + } + } + + mlnx_schedule_playback(mlnxdev); + } + + spin_unlock_irq(&dev->event_lock); + + return 0; +} + +int input_ff_create_mlnx(struct input_dev *dev, void *data, + int (*control_effect)(struct input_dev *, void *, const struct mlnx_effect_command *), + const u16 update_rate) +{ + struct mlnx_device *mlnxdev; + int ret; + const u16 min_update_rate = update_rate < FF_MIN_EFFECT_LENGTH ? + FF_MIN_EFFECT_LENGTH : update_rate; + + mlnxdev = kzalloc(sizeof(*mlnxdev), GFP_KERNEL); + if (!mlnxdev) + return -ENOMEM; + + mlnxdev->dev = dev; + mlnxdev->private = data; + mlnxdev->control_effect = control_effect; + mlnxdev->gain = 0xffff; + mlnxdev->update_rate_jiffies = msecs_to_jiffies(min_update_rate); + input_set_capability(dev, EV_FF, FF_GAIN); + setup_timer(&mlnxdev->timer, mlnx_timer_fired, (unsigned long)dev); + + /* Set up effect emulation if needed */ + if (test_bit(FF_PERIODIC, dev->ffbit) && + !test_bit(FF_RUMBLE, dev->ffbit)) { + set_bit(FF_RUMBLE, dev->ffbit); + mlnxdev->emul = EMUL_RUMBLE; + pr_debug("Emulating RUMBLE with PERIODIC\n"); + } else if (test_bit(FF_RUMBLE, dev->ffbit) && + !test_bit(FF_PERIODIC, dev->ffbit)) { + set_bit(FF_PERIODIC, dev->ffbit); + set_bit(FF_SINE, dev->ffbit); + set_bit(FF_SQUARE, dev->ffbit); + set_bit(FF_TRIANGLE, dev->ffbit); + set_bit(FF_SAW_DOWN, dev->ffbit); + set_bit(FF_SAW_UP, dev->ffbit); + mlnxdev->emul = EMUL_PERIODIC; + pr_debug("Emulating PERIODIC with RUMBLE\n"); + } else { + mlnxdev->emul = EMUL_NOTHING; + pr_debug("No effect emulation is necessary\n"); + } + + ret = input_ff_create(dev, FF_MAX_EFFECTS); + if (ret) { + kfree(mlnxdev); + return ret; + } + + + dev->ff->private = mlnxdev; + dev->ff->upload = mlnx_upload; + dev->ff->set_gain = mlnx_set_gain; + dev->ff->destroy = mlnx_destroy; + dev->ff->playback = mlnx_startstop; + + pr_debug("Device successfully registered.\n"); + return 0; +} +EXPORT_SYMBOL_GPL(input_ff_create_mlnx); diff --git a/include/linux/input/ff-memless-next.h b/include/linux/input/ff-memless-next.h new file mode 100644 index 0000000..7522451 --- /dev/null +++ b/include/linux/input/ff-memless-next.h @@ -0,0 +1,162 @@ +#include <linux/input.h> + +/** 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 + * 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. */ + MLNX_START_UNCOMB, + /* Stop uncombinable effect. This command is sent when an uncombinable + * effect is stopped. */ + MLNX_STOP_UNCOMB, + /* Upload uncombinable effect to device. This command is sent when the + * effect is started from userspace. It is up to the hardware-specific + * driver to handle this situation. + */ + MLNX_UPLOAD_UNCOMB, + /* Remove uncombinable effect from device, This command is sent when + * and uncombinable effect has finished playing and will not be + * restarted. + */ + MLNX_ERASE_UNCOMB +}; + +/** struct mlnx_simple_force - holds constant forces along X and Y axis + * @x: Force along X axis. Negative value denotes force pulling to the left, + * positive value denotes force pulling to the right. + * @y: Force along Y axis. Negative value denotes force denotes force pulling + * away from the user, positive value denotes force pulling towards + * the user. + */ +struct mlnx_simple_force { + const s32 x; + const s32 y; +}; + +/** struct mlnx_rumble_force - holds information about rumble effect + * @strong: Magnitude of the strong vibration. + * @weak: Magnitude of the weak vibration. + * @strong_dir: Direction of the strong vibration expressed in the same way + * as the direction of force feedback effect in struct ff_effect. + * @weak_dir: Direction of the weak vibration, same as above applies. + */ +struct mlnx_rumble_force { + const u32 strong; + const u32 weak; + const u16 strong_dir; + const u16 weak_dir; +}; + +/** struct mlnx_uncomb_effect - holds information about uncombinable effect + * @id: Id of the effect assigned by ff-core. + * @effect: Pointer to the uncombinable effect stored in ff-memless-next module + * Hardware-specific driver must not alter this. + */ +struct mlnx_uncomb_effect { + const int id; + const struct ff_effect *effect; +}; + +/** struct mlnx_commands - describes what action shall the force feedback + * device perform + * @cmd: Type of the action. + * @u: Data associated with the action. + */ +struct mlnx_effect_command { + const enum mlnx_commands cmd; + union { + const struct mlnx_simple_force simple_force; + const struct mlnx_rumble_force rumble_force; + const struct mlnx_uncomb_effect uncomb; + } u; +}; + +/** input_ff_create_mlnx() - Register a device within ff-memless-next and + * the kernel force feedback system + * @dev: Pointer to the struct input_dev associated with the device. + * @data: Any device-specific data that shall be passed to the callback. + * function called by ff-memless-next when a force feedback action + * shall be performed. + * @control_effect: Pointer to the callback function. + * @update_date: Delay in milliseconds between two recalculations of periodic + * effects, ramp effects and envelopes. Note that this value will + * never be lower than (CONFIG_HZ / 1000) + 1 regardless of the + * value specified here. This is not a "hard" rate limiter. + * Userspace still can submit effects at a rate faster than + * this value. + */ +int input_ff_create_mlnx(struct input_dev *dev, void *data, + int (*control_effect)(struct input_dev *, void *, const struct mlnx_effect_command *), + const u16 update_rate); + +/** int control_effect() - Callback to the HW-specific driver. + * @struct input_dev *: Pointer to the struct input_dev of the device that is + * is being controlled. + * @void *: Pointer to any device-specific data set by the HW-specific driver. + * This data will be free'd automatically by ff-memless-next when the + * device is destroyed. + * @const struct mlnx_effect_command *: + * Action the device shall perform. Note that this pointer is valid + * only within the context of the callback function. If the HW-specific + * driver needs any data from this structure after the callback + * function returns, it must copy it. + */