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

[DavidL]

Sorry, keep hitting reply instead of reply-all to make sure the list-serve
has a copy.

---------- Forwarded message ----------
From: DavidL <david.dljunk at 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 at 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 at codeweavers.com> wrote:

> On Jun 14, 2016, at 1:23 AM, DavidL <david.dljunk at gmail.com> wrote:
>
>
> On Mon, Jun 13, 2016 at 2:46 PM, Ken Thomases <ken at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160614/a3fbf7fe/attachment-0001.html>