[v4 2/4] winejoystick.drv/joystick_osx.c: fixes Slider mapping

[DavidL]

On Tue, Jun 14, 2016 at 1:02 AM, Ken Thomases <ken at codeweavers.com> wrote:

>
> On Jun 14, 2016, at 2:06 AM, DavidL <david.dljunk at gmail.com> wrote:
>
> On Mon, Jun 13, 2016 at 11:41 PM, Ken Thomases <ken at codeweavers.com>
> wrote:
>
>> On Jun 14, 2016, at 1:23 AM, DavidL <david.dljunk at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160615/ba61b394/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HID_Utilities.c
Type: text/x-csrc
Size: 34763 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160615/ba61b394/attachment-0002.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IOHIDDevice_.c
Type: text/x-csrc
Size: 19233 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160615/ba61b394/attachment-0003.c>