Fwd: [v4 2/4] winejoystick.drv/joystick_osx.c: fixes Slider mapping
Sorry, keep hitting reply instead of reply-all to make sure the list-serve has a copy. ---------- Forwarded message ---------- From: DavidL <david.dljunk(a)gmail.com> Date: Tue, Jun 14, 2016 at 12:05 AM Subject: Re: [v4 2/4] winejoystick.drv/joystick_osx.c: fixes Slider mapping To: Ken Thomases <ken(a)codeweavers.com> As far as I can tell, both. It both arbitrarily picks which is first for any given run (so yes I can definitely confirm that bug report's description) and the game seems to read input from both inputs regardless of which is first - although which is first does still affect the game. I created virtual joystick in Controllermate which I mapped my physical joystick to but mapping X to Y and Y to X, so that when I pulled back on the yoke it would give both an X reading and a Y reading at the same time if it were reading input from both the virtual and physical joystick. In game, that's what happened, even when the trace logs said it was only recording information from one joystick (and in one case, Red Baron, it was explicitly reading from both in the trace log). Which joystick was found first would affect behavior somewhat (hard to describe, basically how out of whack the motions became!), but regardless I could get it sometimes explicitly, sometimes implicitly to read multiple inputs. Maybe this is an anomaly with virtual joysticks. Not sure, shouldn't be. On Mon, Jun 13, 2016 at 11:41 PM, Ken Thomases <ken(a)codeweavers.com> wrote:
On Jun 14, 2016, at 1:23 AM, DavidL <david.dljunk(a)gmail.com> wrote:
On Mon, Jun 13, 2016 at 2:46 PM, Ken Thomases <ken(a)codeweavers.com> wrote:
Is there reason to expect that these elements (sliders, dials, wheels) will be listed after the "proper" axes (x, y, z, etc.) in the children array? Since the proper axes are specific and these elements should only be mapped to unused axes, I think they should be enumerated in a separate pass after everything else has had a shot. Note that collect_joystick_elements() is recursive, so it's not right to do it in a separate loop within collect_joystick_elements(). Probably, you'll want to call it twice from open_joystick(), with a flag to indicate which mode it should operate in.
This where the Microsoft source documentation get *really* fuzzy. There are all sorts of possible mappings in the rare case where there is both a HID/Dinput Z-axis and a slider/dial/wheel. Microsoft gave 4-5 different variations of how it could go and in some of these mappings, the slider would take precedence over the reported HID Z-axis when mapping to the Winmm Z-axis such that slider -> WinmmZ is correct and the HID Z-axis is then ignored. So I decided to follow the Linux Winmm version and simply have whichever element is listed by the joystick first, wins. If it is the axis, it's the axis, if it is the slider, it's the slider. This actually is one of the ways Microsoft says to decide proper HID mappings to Winmm (and it seems like that for the elements within a joystick, the elements are always reported in the same order such that a user shouldn't experience the axes mappings changing each time they start up Wine/reconnect a device*). There is no 1 correct mapping for all cases. I guess ideally we would have a way of allowing the user to remap the joystick axes in the registry (maybe that would work even now? I don't know - I've seen some emails on that already in the wine-devel list serve but I don't know what the status of that kind of capability is) but even Microsoft states on of their pages that this is a pretty rare corner case.
OK, fine by me.
*Note: in my testing this is *not* the same for OS X (I guess macOS now) reporting back devices - which human interface device is reported first seems to be random in my testing when I had both a virtual and physical joystick setup. Historically Winmm games would only take input from the first reported device - under Mac-Wine, I've noticed the games seem to be taking input from both my physical and virtual joysticks (sometimes regardless of what the game was saying it was doing!). This has both good and bad potential and is not necessarily behavior we should spend effort trying to get rid of. Not sure how the Linux version behaves in this situation in terms of joystick order and input from multiple sources.
It was taking input from both joysticks in the same run? At the same time? If so, can you figure out how that's happening? It really shouldn't, as near as I can see.
Or was it just arbitrarily picking which was first and therefore active for any given run? If this, then it's < https://bugs.winehq.org/show_bug.cgi?id=38997>, more or less.
-Ken
On Jun 14, 2016, at 2:06 AM, DavidL <david.dljunk(a)gmail.com> wrote:
On Mon, Jun 13, 2016 at 11:41 PM, Ken Thomases <ken(a)codeweavers.com <mailto:ken(a)codeweavers.com>> wrote: On Jun 14, 2016, at 1:23 AM, DavidL <david.dljunk(a)gmail.com <mailto:david.dljunk(a)gmail.com>> wrote:
*Note: in my testing this is *not* the same for OS X (I guess macOS now) reporting back devices - which human interface device is reported first seems to be random in my testing when I had both a virtual and physical joystick setup. Historically Winmm games would only take input from the first reported device - under Mac-Wine, I've noticed the games seem to be taking input from both my physical and virtual joysticks (sometimes regardless of what the game was saying it was doing!). This has both good and bad potential and is not necessarily behavior we should spend effort trying to get rid of. Not sure how the Linux version behaves in this situation in terms of joystick order and input from multiple sources.
It was taking input from both joysticks in the same run? At the same time? If so, can you figure out how that's happening? It really shouldn't, as near as I can see.
Or was it just arbitrarily picking which was first and therefore active for any given run? If this, then it's <https://bugs.winehq.org/show_bug.cgi?id=38997 <https://bugs.winehq.org/show_bug.cgi?id=38997>>, more or less.
As far as I can tell, both. It both arbitrarily picks which is first for any given run (so yes I can definitely confirm that bug report's description) and the game seems to read input from both inputs regardless of which is first - although which is first does still affect the game. I created virtual joystick in Controllermate which I mapped my physical joystick to but mapping X to Y and Y to X, so that when I pulled back on the yoke it would give both an X reading and a Y reading at the same time if it were reading input from both the virtual and physical joystick. In game, that's what happened, even when the trace logs said it was only recording information from one joystick (and in one case, Red Baron, it was explicitly reading from both in the trace log). Which joystick was found first would affect behavior somewhat (hard to describe, basically how out of whack the motions became!), but regardless I could get it sometimes explicitly, sometimes implicitly to read multiple inputs. Maybe this is an anomaly with virtual joysticks. Not sure, shouldn't be.
Yeah, it might be an issue with the virtual joystick. Does Apple's HID Calibrator sample code show any similar symptoms? Alternatively, is there any chance that the game was using both winmm and dinput, and the two had enumerated the devices in a different order? We could try to fix these bugs by sorting devices by cookie value in both dlls. -Ken
On Tue, Jun 14, 2016 at 1:02 AM, Ken Thomases <ken(a)codeweavers.com> wrote:
On Jun 14, 2016, at 2:06 AM, DavidL <david.dljunk(a)gmail.com> wrote:
On Mon, Jun 13, 2016 at 11:41 PM, Ken Thomases <ken(a)codeweavers.com> wrote:
On Jun 14, 2016, at 1:23 AM, DavidL <david.dljunk(a)gmail.com> wrote:
*Note: in my testing this is *not* the same for OS X (I guess macOS now) reporting back devices - which human interface device is reported first seems to be random in my testing when I had both a virtual and physical joystick setup. Historically Winmm games would only take input from the first reported device - under Mac-Wine, I've noticed the games seem to be taking input from both my physical and virtual joysticks (sometimes regardless of what the game was saying it was doing!). This has both good and bad potential and is not necessarily behavior we should spend effort trying to get rid of. Not sure how the Linux version behaves in this situation in terms of joystick order and input from multiple sources.
It was taking input from both joysticks in the same run? At the same time? If so, can you figure out how that's happening? It really shouldn't, as near as I can see.
Or was it just arbitrarily picking which was first and therefore active for any given run? If this, then it's < https://bugs.winehq.org/show_bug.cgi?id=38997>, more or less.
As far as I can tell, both. It both arbitrarily picks which is first for any given run (so yes I can definitely confirm that bug report's description) and the game seems to read input from both inputs regardless of which is first - although which is first does still affect the game. I created virtual joystick in Controllermate which I mapped my physical joystick to but mapping X to Y and Y to X, so that when I pulled back on the yoke it would give both an X reading and a Y reading at the same time if it were reading input from both the virtual and physical joystick. In game, that's what happened, even when the trace logs said it was only recording information from one joystick (and in one case, Red Baron, it was explicitly reading from both in the trace log). Which joystick was found first would affect behavior somewhat (hard to describe, basically how out of whack the motions became!), but regardless I could get it sometimes explicitly, sometimes implicitly to read multiple inputs. Maybe this is an anomaly with virtual joysticks. Not sure, shouldn't be.
Yeah, it might be an issue with the virtual joystick. Does Apple's HID Calibrator sample code show any similar symptoms?
Apple's HID Calibrator Tool simply returns a collection of windows for each connected HID. The Calibrator doesn't tell you the order of the devices as far as I can tell (and the virtual joystick does not look any different from a normal joystick). That said, looking at the HID Calibrator code, they do sort the device list by USB location (kIOHIDLocationIDKey), so we could order them by that (see below).
Alternatively, is there any chance that the game was using both winmm and dinput, and the two had enumerated the devices in a different order?
Actually I think this may have been a result of poor testing methodology on my part. I'll keep testing but more recent testing is showing the games are only paying attention to one joystick. After the Winmm joystick driver enumerates all the possible joysticks connected to the system, X-wing Alliance chooses the first and only reports that from then on. Interestingly Red Baron 3D allows up two joysticks to continue to be reported by the trace logs. However, it still seems to only pay attention to the first*. I'll keep checking just in case, but I think the previous results that the games were listening to two simultaneous inputs was operator error - I had an axis controlling two axes in the virtual joystick. *I think it was meant to allow for separate Rudder pedals. According to the manual, the game should allow for separate pedal input, but looking online I don't think they implemented it correctly as people in Windows couldn't get them to work without remapping them into a single device with the stick using controller software. At least I don't think it's a Wine issue.
We could try to fix these bugs by sorting devices by cookie value in both dlls.
Yeah I think the random order bug can be fixed by sorting by kIOHIDLocationIDKey. Actually looking at the dinput code Andrew Eikum used kIOHIDLocationIDKey in his force feedback patch, though I'm not entirely sure to what end. But it seems like it is what we would want to use to sort devices: http://lists.apple.com/archives/usb/2005/Nov/msg00085.html I've attached the Apple version of sorting devices by location for reference. (part of the sample code) The array of devices in HID_Utilities.c are sorted in the function HIDRebuildDevices using the function CFDeviceArrayComparatorFunction, which calls the function IOHIDDevice_GetLocationID in IOHIDDevice_.c. Seems fairly straightforward ... what do you think?
-Ken
On Wed, Jun 15, 2016 at 2:10 AM, DavidL <david.dljunk(a)gmail.com> wrote:
On Tue, Jun 14, 2016 at 1:02 AM, Ken Thomases <ken(a)codeweavers.com> wrote:
On Jun 14, 2016, at 2:06 AM, DavidL <david.dljunk(a)gmail.com> wrote:
On Mon, Jun 13, 2016 at 11:41 PM, Ken Thomases <ken(a)codeweavers.com> wrote:
On Jun 14, 2016, at 1:23 AM, DavidL <david.dljunk(a)gmail.com> wrote:
*Note: in my testing this is *not* the same for OS X (I guess macOS now) reporting back devices - which human interface device is reported first seems to be random in my testing when I had both a virtual and physical joystick setup. Historically Winmm games would only take input from the first reported device - under Mac-Wine, I've noticed the games seem to be taking input from both my physical and virtual joysticks (sometimes regardless of what the game was saying it was doing!). This has both good and bad potential and is not necessarily behavior we should spend effort trying to get rid of. Not sure how the Linux version behaves in this situation in terms of joystick order and input from multiple sources.
It was taking input from both joysticks in the same run? At the same time? If so, can you figure out how that's happening? It really shouldn't, as near as I can see.
Or was it just arbitrarily picking which was first and therefore active for any given run? If this, then it's < https://bugs.winehq.org/show_bug.cgi?id=38997>, more or less.
As far as I can tell, both. It both arbitrarily picks which is first for any given run (so yes I can definitely confirm that bug report's description) and the game seems to read input from both inputs regardless of which is first - although which is first does still affect the game. I created virtual joystick in Controllermate which I mapped my physical joystick to but mapping X to Y and Y to X, so that when I pulled back on the yoke it would give both an X reading and a Y reading at the same time if it were reading input from both the virtual and physical joystick. In game, that's what happened, even when the trace logs said it was only recording information from one joystick (and in one case, Red Baron, it was explicitly reading from both in the trace log). Which joystick was found first would affect behavior somewhat (hard to describe, basically how out of whack the motions became!), but regardless I could get it sometimes explicitly, sometimes implicitly to read multiple inputs. Maybe this is an anomaly with virtual joysticks. Not sure, shouldn't be.
Yeah, it might be an issue with the virtual joystick. Does Apple's HID Calibrator sample code show any similar symptoms?
Apple's HID Calibrator Tool simply returns a collection of windows for each connected HID. The Calibrator doesn't tell you the order of the devices as far as I can tell (and the virtual joystick does not look any different from a normal joystick). That said, looking at the HID Calibrator code, they do sort the device list by USB location (kIOHIDLocationIDKey), so we could order them by that (see below).
Alternatively, is there any chance that the game was using both winmm and dinput, and the two had enumerated the devices in a different order?
Actually I think this may have been a result of poor testing methodology on my part. I'll keep testing but more recent testing is showing the games are only paying attention to one joystick. After the Winmm joystick driver enumerates all the possible joysticks connected to the system, X-wing Alliance chooses the first and only reports that from then on. Interestingly Red Baron 3D allows up two joysticks to continue to be reported by the trace logs. However, it still seems to only pay attention to the first*. I'll keep checking just in case, but I think the previous results that the games were listening to two simultaneous inputs was operator error - I had an axis controlling two axes in the virtual joystick.
*I think it was meant to allow for separate Rudder pedals. According to the manual, the game should allow for separate pedal input, but looking online I don't think they implemented it correctly as people in Windows couldn't get them to work without remapping them into a single device with the stick using controller software. At least I don't think it's a Wine issue.
Another side note: X-wing Alliance is at least partially setup to listen to Dinput (even asks you to install DirectX if you want to calibrate your joystick), but it ends up only listening to Winmm for joysticks in the game as far as I can tell (at least through Wine).
We could try to fix these bugs by sorting devices by cookie value in both dlls.
Yeah I think the random order bug can be fixed by sorting by kIOHIDLocationIDKey. Actually looking at the dinput code Andrew Eikum used kIOHIDLocationIDKey in his force feedback patch, though I'm not entirely sure to what end. But it seems like it is what we would want to use to sort devices:
http://lists.apple.com/archives/usb/2005/Nov/msg00085.html
I've attached the Apple version of sorting devices by location for reference. (part of the sample code) The array of devices in HID_Utilities.c are sorted in the function HIDRebuildDevices using the function CFDeviceArrayComparatorFunction, which calls the function IOHIDDevice_GetLocationID in IOHIDDevice_.c. Seems fairly straightforward ... what do you think?
-Ken
On Wed, Jun 15, 2016 at 2:45 AM, DavidL <david.dljunk(a)gmail.com> wrote:
On Wed, Jun 15, 2016 at 2:10 AM, DavidL <david.dljunk(a)gmail.com> wrote:
On Tue, Jun 14, 2016 at 1:02 AM, Ken Thomases <ken(a)codeweavers.com> wrote:
On Jun 14, 2016, at 2:06 AM, DavidL <david.dljunk(a)gmail.com> wrote:
On Mon, Jun 13, 2016 at 11:41 PM, Ken Thomases <ken(a)codeweavers.com> wrote:
On Jun 14, 2016, at 1:23 AM, DavidL <david.dljunk(a)gmail.com> wrote:
*Note: in my testing this is *not* the same for OS X (I guess macOS now) reporting back devices - which human interface device is reported first seems to be random in my testing when I had both a virtual and physical joystick setup. Historically Winmm games would only take input from the first reported device - under Mac-Wine, I've noticed the games seem to be taking input from both my physical and virtual joysticks (sometimes regardless of what the game was saying it was doing!). This has both good and bad potential and is not necessarily behavior we should spend effort trying to get rid of. Not sure how the Linux version behaves in this situation in terms of joystick order and input from multiple sources.
It was taking input from both joysticks in the same run? At the same time? If so, can you figure out how that's happening? It really shouldn't, as near as I can see.
Or was it just arbitrarily picking which was first and therefore active for any given run? If this, then it's < https://bugs.winehq.org/show_bug.cgi?id=38997>, more or less.
As far as I can tell, both. It both arbitrarily picks which is first for any given run (so yes I can definitely confirm that bug report's description) and the game seems to read input from both inputs regardless of which is first - although which is first does still affect the game. I created virtual joystick in Controllermate which I mapped my physical joystick to but mapping X to Y and Y to X, so that when I pulled back on the yoke it would give both an X reading and a Y reading at the same time if it were reading input from both the virtual and physical joystick. In game, that's what happened, even when the trace logs said it was only recording information from one joystick (and in one case, Red Baron, it was explicitly reading from both in the trace log). Which joystick was found first would affect behavior somewhat (hard to describe, basically how out of whack the motions became!), but regardless I could get it sometimes explicitly, sometimes implicitly to read multiple inputs. Maybe this is an anomaly with virtual joysticks. Not sure, shouldn't be.
Yeah, it might be an issue with the virtual joystick. Does Apple's HID Calibrator sample code show any similar symptoms?
Apple's HID Calibrator Tool simply returns a collection of windows for each connected HID. The Calibrator doesn't tell you the order of the devices as far as I can tell (and the virtual joystick does not look any different from a normal joystick). That said, looking at the HID Calibrator code, they do sort the device list by USB location (kIOHIDLocationIDKey), so we could order them by that (see below).
Alternatively, is there any chance that the game was using both winmm and dinput, and the two had enumerated the devices in a different order?
Actually I think this may have been a result of poor testing methodology on my part. I'll keep testing but more recent testing is showing the games are only paying attention to one joystick. After the Winmm joystick driver enumerates all the possible joysticks connected to the system, X-wing Alliance chooses the first and only reports that from then on. Interestingly Red Baron 3D allows up two joysticks to continue to be reported by the trace logs. However, it still seems to only pay attention to the first*. I'll keep checking just in case, but I think the previous results that the games were listening to two simultaneous inputs was operator error - I had an axis controlling two axes in the virtual joystick.
*I think it was meant to allow for separate Rudder pedals. According to the manual, the game should allow for separate pedal input, but looking online I don't think they implemented it correctly as people in Windows couldn't get them to work without remapping them into a single device with the stick using controller software. At least I don't think it's a Wine issue.
Another side note: X-wing Alliance is at least partially setup to listen to Dinput (even asks you to install DirectX if you want to calibrate your joystick), but it ends up only listening to Winmm for joysticks in the game as far as I can tell (at least through Wine).
Apologies, last e-mail on the subject of testing. :) Red Baron 3D does use button mapping over the two controllers that it listens too (seems to mess it up a bit) even though it ignores axes information from the "second" joystick. But again, I'm pretty sure that this not a Wine issue. As before X-wing Alliance only pays attention to whichever joystick is "first", include for buttons. So the two input issue I think was something on my end and in RB3D, not Wine. However, the random device order is indeed a real issue with the aforementioned potential solution. Cheers, David
We could try to fix these bugs by sorting devices by cookie value in both dlls.
Yeah I think the random order bug can be fixed by sorting by kIOHIDLocationIDKey. Actually looking at the dinput code Andrew Eikum used kIOHIDLocationIDKey in his force feedback patch, though I'm not entirely sure to what end. But it seems like it is what we would want to use to sort devices:
http://lists.apple.com/archives/usb/2005/Nov/msg00085.html
I've attached the Apple version of sorting devices by location for reference. (part of the sample code) The array of devices in HID_Utilities.c are sorted in the function HIDRebuildDevices using the function CFDeviceArrayComparatorFunction, which calls the function IOHIDDevice_GetLocationID in IOHIDDevice_.c. Seems fairly straightforward ... what do you think?
-Ken
participants (2)
-
DavidL -
Ken Thomases