Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bluetooth LE XINPUT compatible input device #489

Open
TahoeWebmaster opened this issue Apr 29, 2023 · 5 comments
Open

Bluetooth LE XINPUT compatible input device #489

TahoeWebmaster opened this issue Apr 29, 2023 · 5 comments

Comments

@TahoeWebmaster
Copy link

TahoeWebmaster commented Apr 29, 2023

I would like to reopen a long closed bug. I am trying to use vjoy/HidHide/Gremlin to create a multi mode, multi joy device interface for Star Citizen for the xbox controller. This seems to work fine for an ancient XBOX ONE controller, but when I updated to a new controller(seems bluetooth is the only interface available) I can only see vjoy outputs when the Gremlin interface is in focus.

So while I can hide the controller from SC, I also lose any and all vjoy I/O and cannot map the keybinds in SC.

Did you have any luck on figuring out what the problem is? This is on Win11.

Thanks
Joel

@TahoeWebmaster
Copy link
Author

I also have the same issue using a wired PowerA controller, so it would seem this is an issue with the newer controllers or win11.

@WhiteMagic
Copy link
Owner

Xbox controllers are XInput devices that provide a DirectInput compatibility layer which is what Gremlin uses as it only works with DirectInput devices. That compatibility layer, however, is behaving in a dumb way in that only the program that has focus is allowed to receive input events. This is valid behavior, though the XBox controller is the only one I've ever seen to do this.

The result of this is that until Gremlin gets support for reading XInput devices this is an unsolvable issue, see WhiteMagic/dill#1. Sometimes Windows installs a less "bad" driver for xbox controllers that doesn't behave this way and usually using a USB cable seems to also avoid the problem. Though I haven't played around with this in a while so things may have changed as well on that front.

@TahoeWebmaster
Copy link
Author

TahoeWebmaster commented Apr 29, 2023

OK, sorry to hear this. My testing to date indicates that using a USB cable on the more recent XBOX controllers does not solve the problem. You need to pull the batteries when using the cable(the c connector is basically a charging port). Also if the controller goes into sleep mode using bluetooth you have to restart everything.

Fortunately I have an ancient XBOX ONE controller that works if 1] deselect device XBOX controller in HidHide, 2] launch Gremlin 3] reselect device XBOX controller in HidHide.

If I don't deselect XBOX controller in HidHide Gremlin will not see the controller. And of course, I need to rehide the controller to get bindings to work in SC.

@TahoeWebmaster
Copy link
Author

Any plans to add XInput support? Can you document where in your code updates would be needed? We could do a repo on your code, add a few collaborators and see if we can get it done.

I think we could live with these limitations:

XInput ref

API for accessing 4 XInput compatible controllers (e.g. XBox 360 or XBox One controllers)
XInput controllers can be accessed in the background.

Limitations:
Max 4 controllers.
Only XInput capable devices.
Unable to activate the extra 2 rumble motors in XBox One controller triggers. (Use Windows.Gaming.Input to do that.)

@WhiteMagic
Copy link
Owner

WhiteMagic commented May 2, 2023

It's not on the list of next things I will look at, mainly because it's orthogonal to Gremlin at this stage and I already have too little time to make progress on the rewrite of Gremlin.

Support would have to be achieved by implementing logic in dill that

  • decides whether to use DirectInput or XInput to process a device
  • implements XInput data reading
  • uses existing data structures and callbacks to notify the executing code about new events

This is likely not that much work, but requires understanding the way dill operates and C/C++ to make the whole thing work correctly. Gremlin itself doesn't even know things like DirectInput or XInput exist, it simply receives event information from dill and handles those. Therefore, there is no input API specific code in Gremlin, and there never will be, as that would just create needless complications that should be handled by the input library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants