Re: XInput [1/4]: Implement XInputGetState
Am 09.07.2009 um 02:58 schrieb Michael Gruber:
This patch series implements parts of the XInput library. You can use this to play games that support Xbox 360 Controllers. To be able to use this you will need to have your Controller working on Linux via the xpad kernel driver and the event interface. It will not work on any OS other than Linux. It supports gamepads, should work with guitars and wheels, but will not work with dance-mats. <1-XInputGetState.patch> 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. Does DInput have enough capabilities to access all the Xbox controller's features? My gut says no, otherwise MS wouldn't have created a new lib. I guess its worth checking though.
On Thu, Jul 9, 2009 at 09:50, Stefan Dösinger<stefandoesinger(a)gmx.at> wrote:
Am 09.07.2009 um 02:58 schrieb Michael Gruber:
This patch series implements parts of the XInput library. You can use this to play games that support Xbox 360 Controllers. To be able to use this you will need to have your Controller working on Linux via the xpad kernel driver and the event interface. It will not work on any OS other than Linux. It supports gamepads, should work with guitars and wheels, but will not work with dance-mats. <1-XInputGetState.patch>
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. Does DInput have enough capabilities to access all the Xbox controller's features? My gut says no, otherwise MS wouldn't have created a new lib. I guess its worth checking though.
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. For example DirectInput does not support FF_RUMBLE, only FF_PERIODIC can be used. This means that the two vibration motors cannot be adjusted independently. Also, with DirectInput I was unable to re-connect the controller while an application was using it.
On Do, 2009-07-09 at 12:50 +0200, Michael Gruber wrote:
On Thu, Jul 9, 2009 at 09:50, Stefan Dösinger<stefandoesinger(a)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
Am Wednesday 15 July 2009 17:37:12 schrieb Detlef Riekenberg:
On Do, 2009-07-09 at 12:50 +0200, Michael Gruber wrote:
On Thu, Jul 9, 2009 at 09:50, Stefan Dösinger<stefandoesinger(a)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)? I doubt that. XInput is special to Xbox 360 controllers, DInput also handles other joysticks, mouse, keyboard
On Wed, Jul 15, 2009 at 17:37, Detlef Riekenberg<wine.dev(a)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(a)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.
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
Am 04.07.2015 um 20:02 schrieb Nathan Schulte <nmschulte(a)gmail.com>:
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). Aric is working on hid.dll and and hidclass.sys. I think the idea is to build xinput.dll on top of this, together with the enumeration functionalities in other DLLs. Later on dinput can be rewritten to work on top of hid.dll and friends. He sent plenty of Emails and patches for review to wine-devel and wine-patches in the past few weeks.
participants (5)
-
Detlef Riekenberg -
Michael Gruber -
Nathan Schulte -
Stefan Dösinger -
Stefan Dösinger