<div dir="ltr"><div><div>I'll CC Aric to this thread.<br><br></div>Cheers,<br></div>Aaryaman<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 14, 2016 at 6:52 PM, Juan Jose Gonzalez <span dir="ltr"><<a href="mailto:juanj.gh@gmail.com" target="_blank">juanj.gh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I just published a patch with my xinput core implementation. If anyone<br>
is interested in an evdev (linux) backend I could publish that too, but<br>
I guess it won't make it into wine due to the tendency towards the HID<br>
architecture.<br>
<br>
A rough overview on how it's supposed to be used can be read in the<br>
README file from the second patch. Let me know what you think.<br>
<br>
The next step would be to implement a backend that uses hid.dll. Using<br>
HID devices should be fairly straightforward. There are, however, two<br>
parts that I haven't figured out yet:<br>
<br>
 - How can we find new devices? The current work for the HID<br>
architecture seems to have tackled the hotplugging problem. Can the<br>
XInput HID backend get notified when a new controller gets plugged in?<br>
Should it just poll for new devices using SetupDi functions or something<br>
similar?<br>
<br>
 - How do we map a controller's buttons and axes to the corresponding<br>
XInput ones? This has to be done per controller model. My evdev backend<br>
has a lookup list that matches controllers to a certain mapping using<br>
some selection criteria (Name, Vendor ID, etc.). My idea was to load the<br>
mappings from the registry, but for this to be usable by regular users,<br>
a GUI would have to be implemented to create those registry entries.<br>
<br>
Any ideas are welcome.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Juan<br>
<br>
<br>
</font></span></blockquote></div><br></div>