(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? */
On Tue, Mar 29, 2011 at 1:57 PM, Vincent Pelletier plr.vincent@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
-
Daniel Remenak -
Vincent Pelletier