[Bug 58743] New: Saitek Joystick has a twist stick for rudder. Registry is configured for Rz but 'wine control' shows Rx.
http://bugs.winehq.org/show_bug.cgi?id=58743 Bug ID: 58743 Summary: Saitek Joystick has a twist stick for rudder. Registry is configured for Rz but 'wine control' shows Rx. Product: Wine Version: 9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: registry Assignee: wine-bugs(a)winehq.org Reporter: bgoodwin91006(a)charter.net Distribution: --- I am using the current stable version of Linux Mint 22.1 Wine; wine-9.0 (Ubuntu 9.0~repack-4build3) My 'Saitek ST290 Pro' joystick has a twist stick to act as rudder or steering control in addition to the usual X,Y,and Z(throttle) inputs. I need the twist axis to be mapped to the Rz axis so I configured a wine registry entry for this setup. When I run 'wine control', It shows x,y,and z working correctly but the stick twist shows up as Rx. The twist does not work in the game 'FA-18 PSF' as proof that the stick is not mapped to Rz. It has worked in the past (several years ago) on this game. My registry setting is HKCU-Software-Wine-DirectInput-Saitek-Saitek Pro 290 "=" X,Y,Z,Rz,POV1 I have tried pointing the generic 'joysticks-default' entry to saitek, I have tried various variations of the comma separated x,y,z.etc entries for my joystick (spaces,no spaces), I tried deleting the generic joysticks entry making my Saitek entry the only joystick entry under DirectInput. I tried making the Saitek entry as a sub entry under the generic joysticks entry. It appears that wine is ignoring my registry entry. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58743 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 --- Comment #1 from Austin English <austinenglish(a)gmail.com> --- Wine 9.0 is nearly 2 years old at this point and no longer supported. Please retest in 10.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.
http://bugs.winehq.org/show_bug.cgi?id=58743 Mike Mestnik <cheako+winehq@mikemestnik.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cheako+winehq@mikemestnik.n | |et --- Comment #2 from Mike Mestnik <cheako+winehq@mikemestnik.net> --- @Austin English please don't ask people to retest with newer versions unless you know there have been changes that are relevant. @bgoodwin I'm assuming this is a HID device. In that case it's important to know a few things. HID(either USB or BT) specifically makes no mention of what button and axis IDs mean, the IDs used "by each device" are essentially random from both wine's and the applications perspective! It's the application's, and not wine's, responsibility to take the vendor:product pair and turn that into a map of what the HID IDs are/mean. Thus there will never be a solution to this issue. Reading the HID specification closely reveals that device manufacturers are barred from having unused IDs, each device shale make use of IDs from 0 to `n` where `n` comes from id-max in the HID descriptor. With this constraint it's impossible for device manufacturers to standardize the IDs. For example an 8bit nes controller would have buttons A,B,select,start while another gamepad without select and start would need to use IDs 2 and 3 for something else. Thus you'll need to find out how to configure whatever game you are playing with the correct ID mapping. For SDL applications you can set `SDL_GAMECONTROLLERCONFIG` env var. For DirectInput and XInput there are control panel "views"... I say to just ignore these, I don't have proof but my assumption is that they don't match what the game uses/sees. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58743 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware --- Comment #3 from Ken Sharp <imwellcushtymelike@gmail.com> --- There's been thousands of changes since Wine 9.0, asking someone to upgrade and re-test is STANDARD.
It's the application's, and not wine's, responsibility to take the vendor:product pair and turn that into a map of what the HID IDs are/mean
So you're saying it's not a Wine bug?
I don't have proof but my assumption
So you don't actually know? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58743 --- Comment #4 from Mike Mestnik <cheako+winehq@mikemestnik.net> --- Correct it's not a wine issue... Even if in windows DirectInput and XInput offer this as a feature/service it's for sure broken. For example is a gamepad has start but not select it's unclear to me how MS would reflect this fact to the application. Even if there is a method, imagine another gamepad with select, but not start... Do you start to see the issue? Games and applications should have profiles for each hardware device, instead of SDL/MS/and now wine trying to handle everything in a transparent and generic way. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58743 --- Comment #5 from Mike Mestnik <cheako+winehq@mikemestnik.net> --- something may be standard and still wrong. This issue is demonstrably an application or at extreme and SDL one. I can know that and not know anything about how microsoft implements it's ABIs. So asking to restest with a newer version, is %110 the incorrect reply. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58743 Zeb Figura <z.figura12@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com --- Comment #6 from Zeb Figura <z.figura12@gmail.com> --- (In reply to Ken Sharp from comment #3)
There's been thousands of changes since Wine 9.0, asking someone to upgrade and re-test is STANDARD.
It's common practice, but I'm not convinced it's a good idea. Thousands of changes doesn't always translate to thousands of changes to the relevant area, and asking users to constantly retest can wear on their patience. Though in this case I can confidently say there's been a number of changes to the HID stack.
@bgoodwin I'm assuming this is a HID device. In that case it's important to know a few things. HID(either USB or BT) specifically makes no mention of what button and axis IDs mean, the IDs used "by each device" are essentially random from both wine's and the applications perspective!
That's... not true? Where did you get that impression? Axis semantics are encoded as HID usages, e.g. X, Y, Z, RX, SLIDER, DIAL, WHEEL. Buttons indeed don't have marked usages, but that's not at all relevant to the report. Moreover, this is a bug specifically about Wine remapping not working. This is completely misunderstanding the point.
Thus you'll need to find out how to configure whatever game you are playing with the correct ID mapping. For SDL applications you can set `SDL_GAMECONTROLLERCONFIG` env var. For DirectInput and XInput there are control panel "views"... I say to just ignore these, I don't have proof but my assumption is that they don't match what the game uses/sees.
Did you actually read the original report? This is exactly what they're doing, except they're using an equivalent Wine feature instead.
It's the application's, and not wine's, responsibility to take the vendor:product pair and turn that into a map of what the HID IDs are/mean. Thus there will never be a solution to this issue.
I don't think this is true, and in fact I think it's often a bad idea for applications to do this. What most applications do instead, which is better, is to allow controllers to be configured/remapped within the application. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58743 --- Comment #7 from Austin English <austinenglish@gmail.com> --- (In reply to Zeb Figura from comment #6)
(In reply to Ken Sharp from comment #3)
There's been thousands of changes since Wine 9.0, asking someone to upgrade and re-test is STANDARD.
It's common practice, but I'm not convinced it's a good idea. Thousands of changes doesn't always translate to thousands of changes to the relevant area, and asking users to constantly retest can wear on their patience. Though in this case I can confidently say there's been a number of changes to the HID stack.
Note that my comment wasn't asking for a retest because time had passed, but because the bug was filed against a very old version. I really don't think we should accept bugs from older versions (unless they are also tested against a current wine version). That said, this is really a topic for wine-devel@, not bugzilla.. I used to ping old bugs asking for a retest while reviewing bugs with no download and without activity for at least 2 years, but I haven't had time for that in a while. -- 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)
-
WineHQ Bugzilla -
WineHQ Bugzilla