XInput [1/4]: Implement XInputGetState

Nathan Schulte nmschulte at gmail.com
Sat Jul 4 13:02:45 CDT 2015


On Wed Jul 15 11:38:49 CDT 2009 Michael Gruber wrote:
> On Wed, Jul 15, 2009 at 17:37, Detlef Riekenberg<wine.dev at web.de> wrote:
>> On Do, 2009-07-09 at 12:50 +0200, Michael Gruber wrote:
>>> On Thu, Jul 9, 2009 at 09:50, Stefan Dösinger<stefandoesinger at gmx.at> wrote:
>>> > Is it possible to implement XInput on top of DirectInput? DirectInput
>>> > already has some internal abstraction layers for differnet joystick APIs,
>>> > and has basic support for OSX joysticks.
>>>
>>> I actually wrote an implementation on top of DirectInput earlier, but
>>> I ditched it since I couldn't get the features to work that I wanted.
>>
>> Can it work the opposite way (DirectInput on top of XInput)?
>>
>> --
>>
>> By by ... Detlef
>
> No, not even the Joystick part of DirectInput could be implemented on
> top of XInput for various reasons: For example DirectInput supports
> lots of ForceFeedback options while XInput supports only rumble. Also,
> the number of XInput devices is limited to 4.

So, whatever happened to these patches?  Given my understanding and the 
discussion here, it seems like this is the way to go (drive XInput from 
e.g. evdev directly instead of layering it with DInput/WinMM).

I'm currently working to get gamepads/joysticks to work with a piece of 
software:

https://www.winehq.org/pipermail/wine-devel/2015-July/108254.html

I'm trying to determine if the software uses RawInput or XInput, which 
brought me to these patches.  The snoop interface (and the undocumented 
SnoopInclude/Exclude and SnoopFromInclude/Exclude configurations) 
doesn't seem to be helpful here, though I may be mis-using it. [1]

Anyway, I'm about to test these patches on master and wanted to see if 
it's possible to include them in Wine if that work goes well.

[1] Using Snoop

With native XInput DLLs, I've tried setting 
SnoopInclude/SnoopFromInclude (with no Snoop*Exclude set) to 
'xinput1_1;xinput1_2;xinput1_3;xinput1_4;xinput9_1_0' and 
'xinput1_1.*;xinput1_2.*;xinput1_3.*;xinput1_4.*;xinput9_1_0.*', but the 
results are the same: no 'CALL/RET' logged from Snoop. (snoop uses 
capital CALL and RET in its logging, and I get none of these in my logs: 
http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/relay.c#l1083)

I've even tried WINEDEBUG=...,+snoop=xinput1_3 which also doesn't seem 
to output any logging other than the SNOOP_SetupDLL traces.

I see lots of GetModuleHandleA and GetProcAddress calls (and a few: 
Call/Ret PE DLL traces, but I think these are just from the 
loader/thread attachments: 
http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/loader.c#l1071). 
  Does the use of GetProcAddress for these routines mean that Snoop 
won't be able to get in the middle?   I see there is a 
SNOOP_GetProcAddress routine (called from ntdll/loader.c) which appears 
like it's supposed to support this GetProcAddress-wrapping, so I'm a bit 
confused.

Thanks,

--
Nate



More information about the wine-devel mailing list