[Bug 9720] New: deadzone regression on eventX input devices

http://bugs.winehq.org/show_bug.cgi?id=9720

Summary: deadzone regression on eventX input devices
           Product: Wine
           Version: 0.9.45.
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: P2
         Component: wine-directx-dinput
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

I don't know exactly with which Wine version this has been introduced
since I jumped from 0.9.42 to 0.9.45, so this may be in-between.

Previously (e.g with 0.9.42) there was no default deadzone using a
'/dev/input/eventX' input device (joystick/wheel), which was good. It
was similar to the behavior on MS-Windows (at least according to my
experience).

Now with Wine 0.9.45 there is a default deadzone which is really bad,
it effectively render my controller unusable. It is especially bad
with a driving wheel controller (really really bad), but it's bad even
with an analog stick joypad (I started using /dev/input/eventX instead
of /dev/input/js0 just because of that when I used such a pad). To be
honest I wonder why someone would even want a deadzone on his
joystick, it renders any fine control impossible.

If there is a way to turn off the deadzone (except from modifying the
source code) please someone tell me, but if it exists it should be
easily accessible (like in the winecfg utility) and turned off by
default (if only to reflect MS-Windows behavior).

Please tell me if you intend to keep this default deadzone anyway, so
that I know I'll have to edit Wine's source code every time I upgrade,
it's not a problem for me since I already have to do that to get force
feedback working anyway but I would be very sorry for the common folks
that just want to play.

Thanks for reading.

[Bug 9720] deadzone regression on eventX input devices

http://bugs.winehq.org/show_bug.cgi?id=9720

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |enhancement
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1

--- Comment #1 from Vitaliy Margolen   2007-09-19 12:29:56 ---
This is intended behavior. That information comes from the device itself and it
is configurable by both system, and your game.
> I started using /dev/input/eventX instead of /dev/input/js0

You should always be using evdev instead of old joydev.

[Bug 9720] deadzone regression on eventX input devices

http://bugs.winehq.org/show_bug.cgi?id=9720

--- Comment #2 from Gerald Folcher   2007-09-19 13:19:08 ---
I'm sorry then, I was under the impression it didn't come from my
device because I get no deadzone when testing the relevent
/dev/input/eventX device with the 'evtest' utility (from the "ff-utils":
http://sourceforge.net/project/showfiles.php?group_id=44724&package_id=9...
)

Does this mean that this 'evtest' utility doesn't read this deadzone
setting ? Any hint on setting it off/0 ? (I searched a bit for the
info but still found nothing helpful)
> > I started using /dev/input/eventX instead of /dev/input/js0
>
> You should always be using evdev instead of old joydev.

Yes of course now I use only the /dev/input/eventX especially since I
need force-feedback.

[Bug 9720] deadzone regression on eventX input devices

http://bugs.winehq.org/show_bug.cgi?id=9720

--- Comment #3 from Gerald Folcher   2007-09-20 07:24:09 ---
Correct me if I'm wrong but I think there's no way/tool to change
these deadzones under Linux. In this case then shouldn't Wine avoid
using this info to initialize deadzones if there is no way for a Linux
user to change these values ?

(Btw, no, the Windows game does not provide a deadzone configuration,
but there's no such deadzone problem under MS-Windows)

Go figure, it seems my driving wheel device (or is it the driver ?)
report some "flat" value even on the pedals (accelerator and brake)
axes (I think it's what is used to set the deadzone, right ?). What
sense does it makes to have a deadzone on a pedal ? Yet one is
reported, and now used by Wine, at least in this case I would say
these values are bogus and should not be used. (And I won't argue
about the pure evilness of a deadzone on the wheel itself).

I don't understand how all this works, but taking some very wild
guesses: if it's hardwired in the device then it's really bad to use
this info without providing a configuration option to not use it. If
it comes from the driver but there's no way for the user to change
these values that's bad too, thought in this case it may be useable,
but only some day in the future, eventually.

Now if you can (you can't) point me to a way to configure/turn off
these deadzone values you win :)

Thanks for reading, and I hope I don't sound too annoying, I'm still
thankful for the work you all do on Wine.

[Bug 9720] deadzone regression on eventX input devices

http://bugs.winehq.org/show_bug.cgi?id=9720

--- Comment #4 from Gerald Folcher   2007-09-24 12:24:58 ---
Well, after thinking about it I think I understand and agree that
Wine's development shouldn't be hindered just because there exists no
tool yet to set these deadzone values to 0.

Also Wine shouldn't have to implement a way to configure this, it
should be left to some external generic system tool, even if it does
not exist yet. It would be unnecessary feature bloat.

Once such a tool exists there will be no more problem, and any effort
put into making it configurable in Wine would be rendered useless. In
the mean time one can always use a previous Wine version if (s)he
can't touch code.

So, yes I really changed my mind (I'm not trying to be sarcastic just
in case anybody wonder). I don't like feature bloat and I realize I
suggested just that, so if anybody is still reading this you can close
this non-bug in peace, as far as I'm concerned of course.

Thanks for eventually reading :)

[Bug 9720] deadzone regression on eventX input devices

http://bugs.winehq.org/show_bug.cgi?id=9720

--- Comment #5 from Vitaliy Margolen   2007-09-24 14:45:48 ---
Patch already sent but not applied yet:
http://www.winehq.org/pipermail/wine-patches/2007-September/044303.html

[Bug 9720] deadzone regression on eventX input devices

http://bugs.winehq.org/show_bug.cgi?id=9720

--- Comment #6 from Gerald Folcher   2007-09-24 19:57:41 ---
Well thanks ! That's quite a surprise, looks like I imagined this
bug/request were not gonna be taken seriously but I was wrong. Sorry
for imagining things.

By looking at the patch file it doesn't look like a feature bloat
either (I did imagine such a thing would've required much more code).

Thanks a lot !

Btw, If I am supposed to try the patch and report if it works as
expected I would gladly try it but I don't know how to use the feature
(does it require to add a "key" in the registry ? Where to put it ? Is
it HKEY_CURRENT_USER/Software/Wine/DirectInput/DefaultDeadZone = 0 ??)

[Bug 9720] deadzone regression on eventX input devices

http://bugs.winehq.org/show_bug.cgi?id=9720

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|[e-mail]        |[e-mail]

--- Comment #7 from Vitaliy Margolen   2007-09-24 20:02:14 ---
That is a source patch, you suppose to apply it on Wine source. However that
patch won't apply without few other patches. I will rediff and send it in.
Hopefully it will make it into 0.9.46.

Reassigning to myself.

[Bug 9720] deadzone regression on eventX input devices

http://bugs.winehq.org/show_bug.cgi?id=9720

--- Comment #8 from Gerald Folcher   2007-09-24 21:10:55 ---
Yes I know it's a patch :) I was just wondering, once applied and Wine
recompiled, if there was something to add in Wine's registry for the
deadzones to be set to 0.

If you would like me to try the patch(es) just tell me. Otherwise I'm
fine waiting.

Thanks again :)

( Shameless plug: (Re)See also my other bug/request: #9221 :D )

[Bug 9720] deadzone regression on eventX input devices

http://bugs.winehq.org/show_bug.cgi?id=9720

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #9 from Vitaliy Margolen   2007-09-25 08:30:45 ---
Patches committed - closing.

[Bug 9720] deadzone regression on eventX input devices

http://bugs.winehq.org/show_bug.cgi?id=9720

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #10 from Vitaliy Margolen   2007-09-25 08:31:43 ---
And yes, it is the same as the other joystick driver:
[HKEY_CURRENT_USER\Software\Wine\DirectInput]
DefaultDeadZone=0

[Bug 9720] deadzone regression on eventX input devices

http://bugs.winehq.org/show_bug.cgi?id=9720

Christopher Krakowiak  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]
                   |                            |m

--- Comment #11 from Christopher Krakowiak   2007-12-03 16:24:16 ---
My Logitech Cordless Rumblepad was working perfectly including force
feedback(with evdev driver) (wine 0.9.48,0.9.49) in Need For Speed Hot Pursuit
2 unt wine 0.9.50 was relased. In 0.9.50 i have very strange deadzones(and
random resetting of axes like ood function 'autofire :P'), with bith input
handlers(/dev/input/js0 and /dev/input/event2). I was chmoding devices to make
sure, they are not used. I made regression test for "git bisect start
dlls/dinput" setting 0.9.49 as good, and 0.9.50 as bed.

"$ git bisect good
Bisecting: 0 revisions left to test after this
[1ed3a815edc0edca2c077a1a2795414fca187cf7] dinput: Fix dead zone handling"

Now all works perfectly.

[Bug 9720] deadzone regression on eventX input devices

http://bugs.winehq.org/show_bug.cgi?id=9720

--- Comment #12 from Vitaliy Margolen   2007-12-03 19:59:35 ---
(In reply to comment #11)
Open new bug. This bug is resolved.