[RFC] dinput: Length can actually be 0.

[Daniel Remenak]

On Tue, Mar 29, 2011 at 1:57 PM, Vincent Pelletier
<plr.vincent at gmail.com> wrote:
> (Sorry for sending to wine-patches initially, it was intended for wnie-devel.)
>
> This fixes force feedback devices slamming for 10ms at full strength, as
> attack is an absolute value, not a factor of effect level.
>
> Daniel Remenak told me that 0-length envelopes (attack and/or fade, not sure
> which combination) cause the effect to be not played (possibly played with 0-
> level) on devices using the Linux iforce driver. This is the reason of the
> comment in the code.
>
> But to other drivers, such as hid-ff, this code causes the device to jump as
> full strength, which was reported (to me directly) for example when playing
> "Live for Speed"[1] with a steering wheel having strong force feedback
> (Logitech G27).
>
> My question: Is it acceptable to risk some regression for iforce driver (until
> bug is identified) to fix other devices ?
> I guess iforce devices also suffer from the too-strong attack/fade effect.
>
> [1] http://www.lfs.net (demo available, I didn't try it)
> ---
>  dlls/dinput/effect_linuxinput.c |   11 +++++------
>  1 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/dlls/dinput/effect_linuxinput.c b/dlls/dinput/effect_linuxinput.c
> index fbc5994..0154f49 100644
> --- a/dlls/dinput/effect_linuxinput.c
> +++ b/dlls/dinput/effect_linuxinput.c
> @@ -606,13 +606,12 @@ static HRESULT WINAPI
> LinuxInputEffectImpl_SetParameters(
>         else env = NULL;
>
>        if (peff->lpEnvelope == NULL) {
> -           /* if this type had an envelope, reset it
> -            * note that length can never be zero, so we set it to something
> minuscule */
> +           /* if this type had an envelope, reset it */
>            if (env) {
> -               env->attack_length = 0x10;
> -               env->attack_level = 0x7FFF;
> -               env->fade_length = 0x10;
> -               env->fade_level = 0x7FFF;
> +               env->attack_length = 0;
> +               env->attack_level = 0;
> +               env->fade_length = 0;
> +               env->fade_level = 0;
>            }
>        } else {
>            /* did we get passed an envelope for a type that doesn't even have
> one? */
> --
> 1.7.4.1
>

My 2 cents:

This patch reflects the original intent of the code.  The current
values are effectively a workaround for poor behavior from the iforce
driver (at least in combination with the Wingman Force), which (six
years ago) was the only reasonably reliable FF driver on linux.  It
was not clear to me at the time whether it was a driver problem or a
more general evdev issue.

This patch correctly fixes one part of bug 9221 (the part about acting
"like a pneumatic hammer").  As a side effect, it also disables most
FF on devices using the iforce driver.

Today, HID FF devices are far more common than iforce devices (which
AFAIK have not been manufactured since the very early 2000s).  The HID
driver works well (has for years), and works as documented (for
instance, that patch works, as it should).  I think making FF usable
for HID devices is worth it; perhaps it will even spur someone to fix
envelope support for the iforce driver.

Regards,
Daniel Remenak