XInput (?) devices don't produce reliable input

[WhiteMagic]

A xbox one controller connected via bluetooth appears to not generate any inputs that dill can see via the test application. In Gremlin there is input generated, however, only when the window has focus.

This might be due to the way access to devices is requested, i.e. non-exclusive or some other weirdness in DirectInput for XInput devices.

[GameOverture]

This SO thread identifies the problem with how XINPUT devices, when being emulated to use DirectInput are unable to read input when their window isn't focused:

https://stackoverflow.com/questions/48748313/using-directinput-with-xbox-one-controller-and-window-focus-on-windows-10

Using XINPUT and DirectInput side-by-side is an option but with the limitation to 4 XINPUT devices total.

I'm currently having trouble attaching a debugger to JoystickGremlin.exe to test a modified version of dill.dll (using VS2017). I'm not too familiar with how Python interops with C++ yet.

[WhiteMagic]

I wouldn't try to connect a debugger to Gremlin, I have no idea what that will do really as it's an effectively Python running in a bundled interpreter. You should be able to use the example test programs of dill to test things which would make attaching a debugger much easier.

As for the interaction between Python and C++, I don't interface with C++ code at all because that would cause all sorts of grief and would require proper binding creation which I don't want to deal with if I can help it. What Gremlin interfaces with are a handful of C functions that are exposed by dill. Accessing C functions is quite easy from within Python using the ctypes package.

Based on that thread the only realistic option would be xinput, as the whole UWP thing makes it dead in the water, as it would not work with the majority of games people actually use Gremlin for.

[WhiteMagic]

• https://docs.microsoft.com/en-us/windows/win32/xinput/getting-started-with-xinput
• https://stackoverflow.com/questions/48748313/using-directinput-with-xbox-one-controller-and-window-focus-on-windows-10

[neilser]

I'm returning to trying to get JG + VJoy doing what I want in terms of remapping, after about a year of it being on the back burner.

My controller is an Xbox wireless controller (full title of what I bought on Amazon is "Xbox Wireless Controller + Wireless Adapter for Windows (Xbox Series X/)") and it's not connecting via Bluetooth per se but instead the little wireless dongle thingy.

If there is anything that I can do to help with debugging and curing this problem I'd be keen to have a go...

For info, in case someone knows of a better way to cure my problem :) the root issue I'm trying to cure is basically that when a thumbstick on my Xbox controller is hard over on both X and Y axes at the same time (so it's at say 45 degrees) it doesn't send +-1 for each axis, but more like 0.7 or 0.8. I can see why they might have thought this was OK but it really isn't from my point of view. Evading interdictions is much easier when you have the full roll and pitch at the same time! (And to rub salt in the wound: my £5 cheap and nasty wired controller DOES generate +-1 for each axis at the 45 degree positions. If it didn't have other issues and horrific dead zones, I'd go back to using it.)

[WhiteMagic]

There really isn't anything to debug but to add XInput support into dill.

[neilser]

Well I'm happy to chip in with that, if it's realistically achievable and there's any kind of interest in making it happen (and of course some guidance from experts like yourself).
I'd be climbing a rather large learning curve, but if there's really no other way to do what I want (i.e. getting 100% from both axes of my thumbsticks at the same time) then I'll have a reason to get it working...

[WhiteMagic]

If you're not comfortable grabbing the code for dill and compiling it using MSVC and the stuff on the Microsoft page about XInput looks like gibberish to you then I would not think that this is realistic. While all in all, I suspect that it's not a whole lot of work to get this working that's only the case if you're familiar with C++ and can deal with and read old C-style interfaces.

[neilser]

OK after a few squints at the relevant bits of code, it looks doable - will see how it goes...

[snow4us]

Did y'all ever figure out a way to get this working? I'm trying to setup a TurtleBeach velocity one and I can't get it to register in the input viewer. I have whitelisted the WindowsApp that is used to update the yoke.

[WhiteMagic]

Assuming it is the same issue, i.e. abnormal implementation of DirectInput compatibility for a defacto XInput device, then there is no workaround. This will not work until XInput handling is implemented into dlil.

[snow4us]

Thanks for the reply. I somehow got everything to work and register w/ JG. I turned off my anti-malware and reinstalled hidhide, re-whitelisted all programs and double checked that the VelocityOne MFD was set to PC mode instead of Xbox. Can’t wait to learn more about JG to enhance my sim setup. Thanks for everything!

[TahoeWebmaster]

I'm returning to trying to get JG + VJoy doing what I want in terms of remapping, after about a year of it being on the back burner.

My controller is an Xbox wireless controller (full title of what I bought on Amazon is "Xbox Wireless Controller + Wireless Adapter for Windows (Xbox Series X/)") and it's not connecting via Bluetooth per se but instead the little wireless dongle thingy.

If there is anything that I can do to help with debugging and curing this problem I'd be keen to have a go...

For info, in case someone knows of a better way to cure my problem :) the root issue I'm trying to cure is basically that when a thumbstick on my Xbox controller is hard over on both X and Y axes at the same time (so it's at say 45 degrees) it doesn't send +-1 for each axis, but more like 0.7 or 0.8. I can see why they might have thought this was OK but it really isn't from my point of view. Evading interdictions is much easier when you have the full roll and pitch at the same time! (And to rub salt in the wound: my £5 cheap and nasty wired controller DOES generate +-1 for each axis at the 45 degree positions. If it didn't have other issues and horrific dead zones, I'd go back to using it.)

Hi, I think if you adjust the saturation by adjusting the outer deadzones you can fix this issue. I had to set mine at about .75.

[neilser]

Hi, I think if you adjust the saturation by adjusting the outer deadzones you can fix this issue. I had to set mine at about .75.

Adjust the deadzones, how? (I mean, with what app?)

[TahoeWebmaster]

You can adjust the deadzone(outer) in Gremlin by adding a response curve to a remap, otherwise you will need to adjust the deadzone in your game. For example Star Citizen has a Saturation setting controls->joystick sensitivity curves.

For an XInput gamepad your only possible option is to adjust the sensitivity curves to prevent it from reaching 100%, a tedious procedure at best. This is why I am lobbying for XInput support in Gremlin. It looks like I may need to generate an Issue Council report in SC to get them to add a Saturation setting for the gamepad.

SC is already contemplating removing tri-cord support in the FM due to this issue with XInput gamepads which have rounded corners in the outer deflection curves which is why you never see full input at 45 degrees. If they do that it will piss a lot of folks off who depend on tri-cording.

You might look for a pre-XInput gamepad, I happen to have an older XBOX ONE that appears to predate the current XInput usage in the current gamepads. It works OK with Gremlin if I tweak HidHide to not hide the XBOX controller before I start Gremlin, afterward I re-enable hiding so that SC doesn't see it.

Normally I wouldn't recommend a gamepad in SC, I am only using one for my alt account which I run on a second pc side by side my main account on my main pc using HOTAS/HOSAS. The gamepad should be ok for ships that don't engage in PVP.