[RFC] dinput: Length can actually be 0.

[Vincent Pelletier]

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