XInput and HID - architecture
Juan Jose Gonzalez
juanj.gh at gmail.com
Thu Mar 3 02:39:46 CST 2016
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>
More information about the wine-devel
mailing list