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

[DavidL]

On Wed, Jun 15, 2016 at 2:45 AM, DavidL <david.dljunk at gmail.com> wrote:

>
>
> On Wed, Jun 15, 2016 at 2:10 AM, DavidL <david.dljunk at gmail.com> wrote:
>
>>
>>
>> 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.
>>
>
> 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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160615/e42e1a0c/attachment-0001.html>