[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: Enabling/Disabling Joysticks from registry for the Mac
From:       Ken Thomases <ken () codeweavers ! com>
Date:       2016-07-30 8:40:28
Message-ID: 509C93C6-F656-4503-9F35-054858B64E7B () codeweavers ! com
[Download RAW message or body]

Hi,

On Jul 30, 2016, at 2:15 AM, DavidL <david.dljunk@gmail.com> wrote:
> 
> I was looking into how the Linux-dinput code and joy.cpl work and comparing that to \
> the macOS-dinput code. I have some questions about how best to proceed: 
> joy.cpl uses joy->instance.tszInstanceName to name the joysticks in the control \
> panel. In Linux-dinput code, they pass the joystick_devices[id].name to both \
> tszInstanceName and tszProductName  In the macOS-dinput code, they pass the name \
> "Joystick #" where # is the index in the joystick array to the instance name and \
> the joystick's actual name to the product name. When looking at the Microsoft \
> guidelines for dinput, it does indeed say that the instance name *can* be joystick \
> + position in the array, but doesn't specify that it *has* to be \
> (https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.reference.dideviceinstance(v=vs.85).aspx). \
> Also, I've confirmed that in the Windows 10 joystick control panel the joysticks \
> are listed by their name, not by joystick number (and in my memory of earlier \
> Windows OSes it's the same).  
> So, should I change the macOS-dinput code to set both tszInstanceName and \
> tszProductName to the product name (as in Linux) or should I change joy.cpl to use \
> tszProductName instead of tszInstanceName? This will also make it easier in the \
> registry to know which joystick is being enabled/disabled. 

We need to distinguish between an object's internal identifier and what's displayed \
in UI.

It seems to me that joy.cpl and dinput ought to use the guidInstance field to \
determine which devices are enabled or disabled.  That would require that the \
backends actually provide a guidInstance that's unique among devices but stable \
across runs and attachment/detachment of devices.  Unfortunately, I'm not sure how \
practical that is.  Some devices seem to provide kIOHIDSerialNumberKey, but not all \
do.  kIOHIDLocationIDKey is stable so long as the USB topology doesn't change, but it \
can change, of course.  An experiment shows that the location ID changes if you just \
plug the device into a different point in the topology (a USB port on the computer \
vs. one on the keyboard, which is a hub).

Also, if you change how this works, everybody's existing registry settings will \
break.

So, perhaps a decent compromise would be for joy.cpl to display both the instance and \
the product name (e.g. "Joystick 1 - Logitech Extreme 3D Pro") but record the \
instance name in the registry.  On Linux, I guess that may make the name looked \
doubled, if the instance and product names are the same.

On the Mac, we should probably change the instance name to something that's really \
associated with the device.  The index in the device array is not stable.  If you \
disconnect the first joystick, all other joysticks will get renumbered in that \
scheme.  Probably, the location ID is the closest we have to a stable ID (which is \
why you've used it for sorting).  It's just too bad that it's an ugly number, whether \
formatted decimal or hexadecimal.

Another approach would be for the Mac code to basically build a dynamic database of \
every game controller it ever encounters, storing all of the available stable \
identifying information about each, and assigning a permanent identifier.  So, \
location ID would not be used because it's not truly stable, but vendor ID, product \
ID, manufacturer, product name, serial number, version number, usage pairs, and maybe \
even the report descriptor could be.  As it enumerates devices, it would look through \
the database to find one that matches all of the these available pieces of metadata.  \
If it does, it will reuse the previously-generated identifier.  Otherwise, it will \
generate a new identifier and add the device to the database.  There would have to be \
a check, in case there are two exactly identical devices attached, to not use the \
same identifier for both.  In practice, the database should never grow very large \
since one system should never have very many devices connected to it over its \
history.


> Further, while joy.cpl correctly is a dinput control panel, enabling/disabling \
> joystick should be for both dinput and winmm games - e.g. X-wing vs Tie Fighter \
> even has the joystick control panel in the game's loader window*, but, once in the \
> game, joystick control is handled by winmm. I believe the joystick registry entry \
> is under dinput, but the winmm wine joystick driver should read that as well.  
> Is it acceptable for wine joystick driver to read the dinput registry? Or should \
> two registry entries be created? or should a single general joystick registry entry \
> not under dinput or winmm control both?

Well, the registry key is actually Wine-specific.  It's got "DirectInput" in the \
path, but we can play a little fast and lose with it.  No Windows app is sensitive to \
what's under that key, for example.  I see no problem with having winmm check it.

There's work underway to implement proper HID support and then reimplement lots of \
different APIs (dinput, winmm joystick, xinput, raw input) on top of that.  When that \
happens, a lot of this will probably have to change and redundancy will hopefully be \
eliminated.  (If it's going to break people's settings, it may be a good time to \
switch to using guidInstance or the equivalent, too.)

-Ken


[prev in list] [next in list] [prev in thread] [next in thread]