[Bug 40658] New: Joystick POW hat switch rotated for JOYDEVDRIVER=(js) while JOYDEVDRIVER=(event) is Ok
https://bugs.winehq.org/show_bug.cgi?id=40658 Bug ID: 40658 Summary: Joystick POW hat switch rotated for JOYDEVDRIVER=(js) while JOYDEVDRIVER=(event) is Ok Product: Wine Version: 1.9.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-dinput Assignee: wine-bugs(a)winehq.org Reporter: otty(a)gmx.net Distribution: --- I have a Saitek AV8R-01 joystick with a POV hat switch. When using the JOYDEVDRIVER=(event) device (dinput/joystick_linuxinput.c), the orientation is Ok both in the Wine Control Panel (control.exe) Joystick test POV area and in the games, i.e when moving the hat switch horizontally to the right the indicator moves towards the right, when moving the hat switch vertically up, the indicator moves up. Hoever the JOYDEVDRIVER=(js) device (dinput/joystick_linux.c) has its orientation mixed up: * when moving the hat switch horizontally to the right the indicator moves down. * when moving the hat switch vertically up, the indicator moves left. This happens on wine-1.9.9 on Ubuntu 14.04 (LTS) installed from http://ppa.launchpad.net/wine/wine-builds/ubuntu trusty main, but is also present in earlier versions, e.g. 1.6.1 Unfortunately I need to use the (js) device as I cannot get the game to recognise the rudder and thrust axes with the (event) device. (BTW, does the (event) device recognize the [HKEY_CURRENT_USER\Software\Wine\DirectInput] registry key in the same way as teh (js) device?) BR, -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 otty(a)gmx.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |otty(a)gmx.net --- Comment #1 from otty(a)gmx.net --- Created attachment 54550 --> https://bugs.winehq.org/attachment.cgi?id=54550 bug 40658 fix -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #2 from otty(a)gmx.net --- I have compiled wine-1.9.10-206-g698d411 and exchanged the POV x and y axis in dlls/dinput/joystick_linux.c around line 734 - see attached patch. This corrects the problem. BR, O -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware --- Comment #3 from Bruno Jesus <00cpxxx(a)gmail.com> --- Is the problem also present in wine control panel? Because you say it works with event driver but you don't say you can reproduce in the control panel with the js driver. I ask because I could help testing with a Xbox 360 controller or a PS2 controller so using the control panel would be trivial to reproduce. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #4 from otty(a)gmx.net --- (In reply to Bruno Jesus from comment #3)
Is the problem also present in wine control panel? Because you say it works with event driver but you don't say you can reproduce in the control panel with the js driver. I ask because I could help testing with a Xbox 360 controller or a PS2 controller so using the control panel would be trivial to reproduce.
I see the same behaviour in the wine control panel/joystick test as in the game. There is a discrepancy in the POV rotation between the (js) and the (event) driver, with the (event) driver giving the correct result. The (js) driver can be fixed by the patch provided previously, exchanging the x and y orientation. Br, -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #5 from Bruno Jesus <00cpxxx(a)gmail.com> --- If I apply your patch from comment 1 it breaks my Xbox 360 gamepad, so there is something deeper to do here. There should be something else to check to determine that in your controller the POV is rotated. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #6 from Bruno Jesus <00cpxxx(a)gmail.com> --- Please run the following commnand in an unpatched wine with both (js) and (event) drivers enabled for your joystick. WINEDEBUG=+dinput wine control > /tmp/log.txt Open the joystick config and press the POV buttons to generate some log events. And then attach the file /tmp/log.txt. It could have some clues about what is wrong; -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #7 from otty(a)gmx.net --- Created attachment 62083 --> https://bugs.winehq.org/attachment.cgi?id=62083 logs of patched and unpatched 3.12 when operating Saitek AV8R POV switch Content: Archive: logs_40658_wine3.13_patched.zip Length Date Time Name --------- ---------- ----- ---- 0 2018-08-16 19:04 tmp/ 3589906 2018-08-16 19:06 tmp/js-3.13_log.txt 1870358 2018-08-16 18:36 tmp/js-patched_log.txt 977689 2018-08-16 19:03 tmp/event-3.13_log.txt 892834 2018-08-16 18:38 tmp/event-patched_log.txt --------- ------- 7330787 5 files -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #8 from otty(a)gmx.net --- (In reply to Bruno Jesus from comment #6)
Please run the following commnand in an unpatched wine with both (js) and (event) drivers enabled for your joystick.
WINEDEBUG=+dinput wine control > /tmp/log.txt
Open the joystick config and press the POV buttons to generate some log events.
And then attach the file /tmp/log.txt. It could have some clues about what is wrong;
After a long time, I finally found a couple of hours during my vacation to build a Ubunti Biarch version 3.13 and generate the requested logs. (problem and patch are identical to 1.19) Registry settings are the following: [HKEY_CURRENT_USER\Software\Wine\DirectInput] "Saitek AV8R Joystick (js)"="X,Y,Z,Rz,Rx,POV1" "Saitek AV8R Joystick (event)"="X,Y,Z,Rz,Rx,POV1" [HKEY_CURRENT_USER\Software\Wine\DirectInput\Joysticks] "Saitek AV8R Joystick (event)"="disabled" For the logs, I moved the AV8R POV switch in the following pattern: left - forward - right -backward Except for the unpatched (js) variant, the status indicator in the control.exe moved as expected. For the unpatched (js) variant, the following status was observed in control.exe: forward - left - right - bottom BR, -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 otty(a)gmx.net changed: What |Removed |Added ---------------------------------------------------------------------------- Version|1.9.9 |3.13 --- Comment #9 from otty(a)gmx.net --- Additional Question: what is the GUID of the AV8R joystick device - in the BoBII game it seems the joystick axes can be assigned based on the joystick GUID? In the log it seems that mouse, keyboard, etc. get the same GUID 9e573ed9-7734-0000-8d4a-23903fb6bdf7, while each joystick axis gets a separate GUID: 0009:trace:dinput:find_joystick_devices Found a joystick on /dev/input/js0: Saitek AV8R Joystick (js) with 7 axes and 14 buttons 0009:trace:dinput:fill_joystick_dideviceinstanceW 1100 0x33e7b0 0009:trace:dinput:joydev_enum_deviceW Enumerating the linux Joystick device: /dev/input/js0 (Saitek AV8R Joystick (js)) 0009:trace:dinput:IDirectInputWImpl_EnumDevices - checking device 3 ('Wine Linux joystick driver') 0009:trace:dinput:IDirectInputWImpl_EnumDevices (this=0x16c5d8,0x0004 'DI8DEVCLASS_GAMECTRL',0x7d83a310,0x7d85bb40,0x0001) 0009:trace:dinput:_dump_EnumDevices_dwFlags flags: DIEDFL_ATTACHEDONLY 0009:trace:dinput:IDirectInputWImpl_EnumDevices - checking device 0 ('Wine mouse driver') 0009:trace:dinput:IDirectInputWImpl_EnumDevices - checking device 0 ('Wine mouse driver') 0009:trace:dinput:IDirectInputWImpl_EnumDevices - checking device 1 ('Wine keyboard driver') 0009:trace:dinput:IDirectInputWImpl_EnumDevices - checking device 1 ('Wine keyboard driver') 0009:trace:dinput:IDirectInputWImpl_EnumDevices - checking device 2 ('Wine Linux-input joystick driver') 0009:trace:dinput:IDirectInputWImpl_EnumDevices - checking device 3 ('Wine Linux joystick driver') 0009:trace:dinput:fill_joystick_dideviceinstanceW 1100 0x33e7b0 0009:trace:dinput:joydev_enum_deviceW Enumerating the linux Joystick device: /dev/input/js0 (Saitek AV8R Joystick (js)) 0009:trace:dinput:IDirectInput7WImpl_CreateDeviceEx (0x16c5d8)->({9e573ed9-7734-0000-8d4a-23903fb6bdf7}, (null), 0x16c9c8, (nil)) 0009:trace:dinput:mousedev_create_device 0x16c5d8 {9e573ed9-7734-0000-8d4a-23903fb6bdf7} (null) 0x16c9c8 1 0009:trace:dinput:keyboarddev_create_device 0x16c5d8 {9e573ed9-7734-0000-8d4a-23903fb6bdf7} (null) 0x16c9c8 1 0009:trace:dinput:joydev_create_device 0x16c5d8 {9e573ed9-7734-0000-8d4a-23903fb6bdf7} (null) 0x16c9c8 1 0009:trace:dinput:joydev_create_device 0x16c5d8 {9e573ed9-7734-0000-8d4a-23903fb6bdf7} (null) 0x16c9c8 1 0009:trace:dinput:alloc_device {9e573ed9-7734-0000-8d4a-23903fb6bdf7} 0x16c5d8 0x33e58c 0 0009:trace:dinput:setup_dinput_options "Saitek AV8R Joystick (js)" = "X,Y,Z,Rz,Rx,POV1" 0009:trace:dinput:IDirectInputAImpl_AddRef (0x16c5d8) incrementing from 1 0009:trace:dinput:fill_joystick_dideviceinstanceW 1100 0x33e0e0 0009:trace:dinput:_dump_DIDATAFORMAT Dumping DIDATAFORMAT structure: 0009:trace:dinput:_dump_DIDATAFORMAT - dwSize: 24 0009:trace:dinput:_dump_DIDATAFORMAT - dwObjsize: 16 0009:trace:dinput:_dump_DIDATAFORMAT - dwFlags: 0x00000001 (DIDF_ABSAXIS) 0009:trace:dinput:_dump_DIDATAFORMAT - dwDataSize: 272 0009:trace:dinput:_dump_DIDATAFORMAT - dwNumObjs: 20 0009:trace:dinput:_dump_DIDATAFORMAT - Object 0: 0009:trace:dinput:_dump_DIDATAFORMAT * GUID: {a36d02e0-c9f3-11cf-bfc7-444553540000} ('GUID_XAxis') 0009:trace:dinput:_dump_DIDATAFORMAT * dwOfs: 0 0009:trace:dinput:_dump_DIDATAFORMAT * dwType: 0x00000002 0009:trace:dinput:_dump_DIDATAFORMAT Type: DIDFT_ABSAXIS / Instance: 0 0009:trace:dinput:_dump_DIDATAFORMAT * dwFlags: 0x00000000 0009:trace:dinput:_dump_DIDATAFORMAT 0009:trace:dinput:_dump_DIDATAFORMAT - Object 1: 0009:trace:dinput:_dump_DIDATAFORMAT * GUID: {a36d02e1-c9f3-11cf-bfc7-444553540000} ('GUID_YAxis') 0009:trace:dinput:_dump_DIDATAFORMAT * dwOfs: 4 0009:trace:dinput:_dump_DIDATAFORMAT * dwType: 0x00000102 0009:trace:dinput:_dump_DIDATAFORMAT Type: DIDFT_ABSAXIS / Instance: 1 0009:trace:dinput:_dump_DIDATAFORMAT * dwFlags: 0x00000000 0009:trace:dinput:_dump_DIDATAFORMAT In dlls/dinput/joystick_linux.c it looks as if the GUID is fixed for all joystick types: static const GUID DInput_Wine_Joystick_GUID = { /* 9e573ed9-7734-11d2-8d4a-23903fb6bdf7 */ 0x9e573ed9, 0x7734, 0x11d2, {0x8d, 0x4a, 0x23, 0x90, 0x3f, 0xb6, 0xbd, 0xf7} }; -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 Paul <geoff.pvgn1(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |geoff.pvgn1(a)gmail.com --- Comment #10 from Paul <geoff.pvgn1(a)gmail.com> --- Hi. Ran into this apparently old issue after dusting off a T.Flight Hotas X from Thrustmaster. Same exact behavior with the hat switch through the js0 interface as described above. Present in vanilla wine 5.0.3 and 6.3 in Gentoo, in 32 and 64 bit clean prefixes. In game (tested in Everspace) and in wine control panel, the joystick's event interface (/dev/input/event8) registers proper cardinal directions for the hat switch. Switching to the js interface (/dev/input/js0), the hat switch's X and Y axes are swapped. As a fix, I can swap the mapping in jstest-gtk, and js0 will behave properly in wine. Not ideal, since I'd be swapping it back and forth. My preference for the js0 interface is because I can adjust deadzones through jstest-gtk and jscal. The counterpart event program "evdev-joystick" doesn't seem to actually affect the deadzone. I'd pursue the event program's issues, but since js0 works fine outside of wine, I'd consider this issue an easier bridge to cross. The joystick has seven axes (identified in jscal as 0, 1, 2, 5, 6, 16, 17) , including the two representing the single hat switch on it. The hat axes are 16 (x axis) and 17 (y axis). I can successfully remap axes on the joystick through instructions at: https://wiki.winehq.org/Useful_Registry_Keys However, it doesn't affect the hat switch's orientation. I patched wine 6.3, using the patch here as a base, and it fixed the hat switch cardinals. According to comment #5 it looks like it breaks other controllers, so that may not be the solution. I am attaching logs from WINEDEBUG=+dinput wine control for the unpatched and patched cases. I am also attaching the udevadm info for the joystick. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #11 from Paul <geoff.pvgn1(a)gmail.com> --- Created attachment 69565 --> https://bugs.winehq.org/attachment.cgi?id=69565 "wine control" unpatched wine 6.3 with t.flight hotas x -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #12 from Paul <geoff.pvgn1(a)gmail.com> --- Created attachment 69566 --> https://bugs.winehq.org/attachment.cgi?id=69566 "wine control" patched wine 6.3 with t.flight hotas x -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #13 from Paul <geoff.pvgn1(a)gmail.com> --- Created attachment 69567 --> https://bugs.winehq.org/attachment.cgi?id=69567 udevadm info for hotas x -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 Rémi Bernon <rbernon(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon(a)codeweavers.com --- Comment #14 from Rémi Bernon <rbernon(a)codeweavers.com> --- The legacy dinput joystick backends are now gone, could you please check if this is still wrong with current Wine HEAD? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #15 from Paul <geoff.pvgn1(a)gmail.com> --- (In reply to Rémi Bernon from comment #14)
The legacy dinput joystick backends are now gone, could you please check if this is still wrong with current Wine HEAD?
I just built Wine from latest today (10/13/2021) on Gentoo. With the latest, I see only one joystick option through Wine 'control' now. I tested one-by-one with the T.master HOTAS X, and the newer T.master HOTAS 4. Seeing as the option to select the (js0) device is no longer present in Head, I can't answer to the question of it being fixed. I can say that with the HOTAS X, all analog axes and buttons are reported correctly, however the HAT switch's Y-axis is inverted for some reason. Its X-axis is correct. With the T.master HOTAS 4, one axis is not being reported, and the HAT switch has the same inverted Y-axis. The HAT's X-axis is correct. The unreported analog axis is: type 3 (EV_ABS), code 7 (ABS_RUDDER) as reported by 'evtest.' Because I don't see any suffix for the driver device node in Wine control, I don't know what software to use in linux to calibrate and adjust deadzones. I also don't know what losing the "legacy dinput joystick backends" means for legacy windows software on Wine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #16 from Rémi Bernon <rbernon(a)codeweavers.com> --- Thanks, Wine is now using SDL library by default to access controllers and joysticks, so it's not possible to tell exactly which Linux subsystem it is using, but most likely evdev, if it is available. If SDL support is disabled (through the registry) or not compiled in, Wine is using evdev directly instead. Regarding the Y axis inversion, it would be awesome if you could provide a WINEDEBUG=+plugplay,+hid,+hidp,+hid_report,+dinput log, combined with the "evtest" output recorded at the same time, and pressing a few HAT switch direction. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #17 from Paul <geoff.pvgn1(a)gmail.com> --- Created attachment 70807 --> https://bugs.winehq.org/attachment.cgi?id=70807 WINEDEBUG=+plugplay,+hid,+hidp,+hid_report,+dinput wine control -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #18 from Paul <geoff.pvgn1(a)gmail.com> --- Created attachment 70808 --> https://bugs.winehq.org/attachment.cgi?id=70808 evtest t.master hostas x -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #19 from Paul <geoff.pvgn1(a)gmail.com> --- (In reply to Rémi Bernon from comment #16)
Thanks, Wine is now using SDL library by default to access controllers and joysticks, so it's not possible to tell exactly which Linux subsystem it is using, but most likely evdev, if it is available.
If SDL support is disabled (through the registry) or not compiled in, Wine is using evdev directly instead.
Regarding the Y axis inversion, it would be awesome if you could provide a WINEDEBUG=+plugplay,+hid,+hidp,+hid_report,+dinput log, combined with the "evtest" output recorded at the same time, and pressing a few HAT switch direction.
Attachments uploaded per request. It also looks like the SDL devs are getting off their butts and fixing the calibration issues inherent in their code: https://github.com/libsdl-org/SDL/issues/3781 Perhaps the js driver can finally be put to rest. Before now, it was the only one that would accept and reflect calibrations to correct the deadzones arbitrarily put in place. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #20 from Rémi Bernon <rbernon(a)codeweavers.com> --- Thanks, I'll have a look. FWIW dinput has some builtin deadzone and saturation calibration features, it should be implemented but it's not persistent yet or easily configurable either, only programmatically accessible by any any application which may set it. We could think of having it persistent and exposed in joy.cpl to ease the setup of Wine joysticks. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #21 from Paul <geoff.pvgn1(a)gmail.com> --- (In reply to Rémi Bernon from comment #20)
Thanks, I'll have a look.
FWIW dinput has some builtin deadzone and saturation calibration features, it should be implemented but it's not persistent yet or easily configurable either, only programmatically accessible by any any application which may set it.
We could think of having it persistent and exposed in joy.cpl to ease the setup of Wine joysticks.
I see. Since the consensus seems to be that the application should be controlling the deadzone, I'd be all for leaving it up to that, conditionally to whether the app does it well! A good point was made at the link I offered, which is if the application employs any math to calculate a variable deadzone, then a presence of a lower-level deadzone would skew the results. My only goal in using the js device node was to use 'jscal' to actually eliminate the built-in deadzones at the time. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #22 from Rémi Bernon <rbernon(a)codeweavers.com> --- I've sent https://source.winehq.org/patches/data/217348 and https://source.winehq.org/patches/data/217347 which should hopefully solve the two issues mentioned above. The Y axis fix at least is quite obvious, I'm less sure about the missing RUDDER axis though, maybe it's something that isn't mapped in SDL. You can also try by disabling SDL, so that Wine directly uses evdev. This can be done by setting the "Enable SDL" option to 0, as described in https://wiki.winehq.org/Useful_Registry_Keys, and if that still doesn't work, a log with the same WINEDEBUG options as above would be really helpful! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #23 from Paul <geoff.pvgn1(a)gmail.com> --- (In reply to Rémi Bernon from comment #22)
I've sent https://source.winehq.org/patches/data/217348 and https://source.winehq.org/patches/data/217347 which should hopefully solve the two issues mentioned above.
The Y axis fix at least is quite obvious, I'm less sure about the missing RUDDER axis though, maybe it's something that isn't mapped in SDL.
You can also try by disabling SDL, so that Wine directly uses evdev. This can be done by setting the "Enable SDL" option to 0, as described in https://wiki.winehq.org/Useful_Registry_Keys, and if that still doesn't work, a log with the same WINEDEBUG options as above would be really helpful!
OK, I used the very same wine head for this round of tests. I noticed a few problems with this new SDL/event dependency choice of wine. In the past (wine 6.12, etc.) I could use the regedit instructions from: https://wiki.winehq.org/Useful_Registry_Keys "axes mapping" could reorganize the axes of the HOTAS 4 so I could once again use the rudder (the kernel driver for it isn't mature due to few people knowing how to get it out of the sony PS4 compatibility and into PC output, and the driver identifies more axes than it actually has, throwing other software off) Using the instructions to enable/disable SDL, this particular registry key doesn't produce any change in axes. Specifically, in the past, this would work, and now does not (yes in today's tests I changed the name of the device to reflect what wine identifies. This is from an older prefix): [Software\\Wine\\DirectInput] 1615525022 #time=1d716fc2425fc64 "Thrustmaster T.Flight Hotas 4 (event)"="X,Y,Z,-,-,Rx,-,Ry,POV1" Further, once SDL is disabled in the registry, the input device name is reduced to an ambiguous "Thrustmaster" which would be a problem if there were more than one Thrustmaster device connected. In each test with and without SDL, I sampled each axis, with the rudder axis the last. One last thing, with SDL disabled, the HAT has correct directions. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #24 from Paul <geoff.pvgn1(a)gmail.com> --- Created attachment 70821 --> https://bugs.winehq.org/attachment.cgi?id=70821 SDL enabled $WINEDEBUG=+plugplay,+hid,+hidp,+hid_report,+dinput wine control -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #25 from Paul <geoff.pvgn1(a)gmail.com> --- Created attachment 70822 --> https://bugs.winehq.org/attachment.cgi?id=70822 evtest t.master hotas 4 in tandem with sdlenabled report -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #26 from Paul <geoff.pvgn1(a)gmail.com> --- Created attachment 70823 --> https://bugs.winehq.org/attachment.cgi?id=70823 SDL disabled $WINEDEBUG=+plugplay,+hid,+hidp,+hid_report,+dinput wine control -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #27 from Paul <geoff.pvgn1(a)gmail.com> --- Created attachment 70824 --> https://bugs.winehq.org/attachment.cgi?id=70824 evtest t.master hotas 4 in tandem with sdldisabled report -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 Julian Rüger <jr98(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98(a)gmx.net -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #28 from Rémi Bernon <rbernon(a)codeweavers.com> --- Looks like the SDL backend is hitting the absolute axis limit, but the evdev backend maps the ABS_RUDDER axis correctly and dinput is picking it. Also note that joy.cpl can currently only display up to 6 axes, so the although the rudder axis is apparently supported (with SDL disabled), it's not displayed there. We'd have a improve the control panel interface for it to be. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #29 from Rémi Bernon <rbernon(a)codeweavers.com> --- Regarding the axis mapping, it's indeed not supported anymore. Maybe we could restore something like it in the new dinput HID joystick, but I'm not sure it's a good idea to do it there, it would be better to have all the axis properly mapped in the first place. Then SDL already has some sort of mapping for gamepad controllers, and we do some evdev to HID mapping in winebus.sys, so maybe it's better to do it there. It's not going to be possible to have a per-application mapping in that case though. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #30 from Paul <geoff.pvgn1(a)gmail.com> --- (In reply to Rémi Bernon from comment #29)
Regarding the axis mapping, it's indeed not supported anymore. Maybe we could restore something like it in the new dinput HID joystick, but I'm not sure it's a good idea to do it there, it would be better to have all the axis properly mapped in the first place.
Then SDL already has some sort of mapping for gamepad controllers, and we do some evdev to HID mapping in winebus.sys, so maybe it's better to do it there. It's not going to be possible to have a per-application mapping in that case though.
Right, it didn't take long in my research to figure out there was an axis limit in most abstraction layers, hence the registry edit removing them from wine's sight. I think if I could connect with someone in charge of the driver, that could be settled. Seems like a lot of effort for a sim input device, though. I'm convinced the proper way should be by masking the useless axes at the kernel level, but the event nodes make it much more difficult than the old jsX nodes. Seems like it's getting more and more difficult to modify things on the software side to work with flawed hardware, which exists in the world, and must be tolerated at times. I remember conversations like this when the first modern touchscreens came out. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #31 from Rémi Bernon <rbernon(a)codeweavers.com> --- I'm definitely not opposed to make the axis mapping configurable somehow, to help with bogus devices and users, just that doing it in DInput like it was done before doesn't seem right anymore. Wine now exposes any host joystick as an HID device internally, and DInput is only one of the many ways to access them. Applications may use HID APIs directly, and I know several middleware are doing it instead of DInput which is kind of considered as legacy. So having a customizable mapping in winebus.sys instead, for when where we convert evdev axes to HID usages makes more sense, it's just not implemented yet. Of course, that won't cover cases where Wine simply acts as a pass-through, like with hidraw devices, or where the mapping is already done elsewhere, like with SDL. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #32 from Rémi Bernon <rbernon(a)codeweavers.com> --- Of course that should read "help the users", not help with bogus users. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #33 from Paul <geoff.pvgn1(a)gmail.com> --- (In reply to Rémi Bernon from comment #31)
I'm definitely not opposed to make the axis mapping configurable somehow, to help with bogus devices and users, just that doing it in DInput like it was done before doesn't seem right anymore.
Wine now exposes any host joystick as an HID device internally, and DInput is only one of the many ways to access them. Applications may use HID APIs directly, and I know several middleware are doing it instead of DInput which is kind of considered as legacy.
So having a customizable mapping in winebus.sys instead, for when where we convert evdev axes to HID usages makes more sense, it's just not implemented yet.
Of course, that won't cover cases where Wine simply acts as a pass-through, like with hidraw devices, or where the mapping is already done elsewhere, like with SDL.
I admit that would take care of the current situation. Per-application mapping should be a non-issue with separate prefixes, as is recommended, and should be further encouraged by distro wikis. I've run across apps that used raw input (Everspace I think it was?). The only way to correct it was through the device node, which loops us back to the beginning of the discourse. Of course, hearing wine implement SDL in this way brings me back to all the terrible times, as an end user, I had trying to make sense of their wiki. This lists some up-to-date tools, though I'm not sure how relevant this will be to wine. https://github.com/gabomdq/SDL_GameControllerDB
Of course that should read "help the users", not help with bogus users.
Yeah, we shouldn't help them, stupid non-sentient wannabe humans. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #34 from Rémi Bernon <rbernon(a)codeweavers.com> --- I sent https://source.winehq.org/patches/data/217914, https://source.winehq.org/patches/data/217915, https://source.winehq.org/patches/data/217916 and https://source.winehq.org/patches/data/217917 to help with SDL axis limit, and hopefully addressing the remaining issues here, then I believe the bug could be marked as resolved. I also opened https://bugs.winehq.org/show_bug.cgi?id=51908 to track the addition of a custom axis mapping to winebus.sys evdev backend. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 Rémi Bernon <rbernon(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=51908 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40658 --- Comment #35 from Paul <geoff.pvgn1(a)gmail.com> --- (In reply to Rémi Bernon from comment #34)
I sent https://source.winehq.org/patches/data/217914, https://source.winehq.org/patches/data/217915, https://source.winehq.org/patches/data/217916 and https://source.winehq.org/patches/data/217917 to help with SDL axis limit, and hopefully addressing the remaining issues here, then I believe the bug could be marked as resolved.
I also opened https://bugs.winehq.org/show_bug.cgi?id=51908 to track the addition of a custom axis mapping to winebus.sys evdev backend.
Let me know when/how to test the head so we can mark this solved. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla