XInput and HID - architecture

[Juan Jose Gonzalez]

Hi,

I got a bit stuck and would like to hear your opinion on the XInput HID
backend, specifically on the mappings, i.e. the code that "accepts" a
certain device based on its properties and then maps its buttons and
axes to XInput buttons and axes.

As long as the mappings are fixed, i.e. are not supposed to be extended
or edited by the user, everything can be compiled into xinput1_3.dll.
However, I would like to provide a "xinput.cpl" control panel node for
xinput similar to "joy.cpl", where the user can not only test the XInput
gamepads, but also manage the XInput-HID backend mappings. The first
part can be accomplished by using xinput1_3.dll. However, in order to
load and persist different mappings, the second part requires access to
the functions that serialize and deserialize the mappings. It also needs
some way of getting raw capabilities and changes in HID devices in order
to be able to create new mappings.

Here are some possible ways of solving it:

  * Extend xinput1_3.dll with the required management functions and add
    a "wine/xinput_hid_mgmt.h" or similar header that declares those
    methods. xinput.cpl could then simply use xinput1_3.dll to perform
    all management functions. I'm not sure if this would break anything
    due to the additional exports in the dll.
  * Extract the mapping load and store logic into a separate
    "xinputhid.dll" or similar. I this case both xinput1_3.dll and
    xinput.cpl would access this library to load and store mappings.
  * Move the xinput core and backends into a driver and let
    xinput1_3.dll access it via IOCTLs. I believe this is the way it
    works on windows, although there doesn't seem to be any freely
    available documentation regarding the internal architecture. The
    XInput-HID backend could then create its own kernel object as a
    management interface, which could be accessed by xinput.cpl. This
    would have the added effect of having a single instance managing the
    xinput devices if several programs are running at the same time,
    which mimics the behavior of windows.

What do you think would be the best option? Is there another way I
haven't mentioned?

- Juan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160303/e14b1e7b/attachment.html>