Next Generation Emulation banner

1 - 5 of 5 Posts

·
Registered
Joined
·
2 Posts
Discussion Starter · #1 · (Edited)
Hi. I have the above mentioned gamepad, a Speedlink XEOX Pro Analog SL-6556-BK. It's a nice pad with precise sticks and a switch for DirectInput mode where it supports force feedback effects on old games, which the original Microsoft pad is incapable of.

Vibration effects in XInput mode however are kinda broken. Noticeable in some games, for example GTA IV and Driver San Francisco, where it happens every other time that either effects aren't triggered or the motors keep vibrating way longer than they should and only stop when the next effect is triggered. It also works fine in some other games, so I got curious and experimented a bit to reproduce the problem:

It seems that xinput api calls to set the motor speeds sometimes get ignored, which explains why effects don't trigger. But those values seem to get buffered/remembered because subsequent calls with the same values are completely ignored as well. This has very undesirable consquences:
- if the application relies on sending data only once, it can happen that the event is ignored
- even if the application sends data constantly (for example each simulation tick), but uses the same value for a state, for example zero to turn off the motors completely, it can happen that this stream is completely ignored as well until the value is changed

I've tested this with 2 original Microsoft pads (wireless and wired) and 2 brandnew xeox pads (assuming that the first might have been broken I went back to the store and got a replacement), on Windows 7 and Windows 8. The problem only shows on the xeox pads, and on both of them. Now as far as I can tell they don't come with own drivers for the XInput stuff and are recognized as regular 360 pads, so I'm guessing that it's a firmware bug. Or maybe Windows somehow detects that the pads are not genuine after all and messes with the signals, which honestly wouldn't suprise me.

Now I'm wondering if it's possible to use x360ce to "fix" this issue: It would be necessary to intercept motor state related XInput calls from the application and send some additional and/or fake calls to the device to work around that bugged buffering (which I assume is done by the driver to reduce data sent per usb?) and make sure that the motors trigger by sending a stream of values in the range the application wants to trigger.

I'm aware that this needs some additional coding, if it's possible at all. So before I dive into trying to build x360ce only to realize that the hooking mechanism doesn't work that way (i.e. catching calls from the application) I was hoping that somebody who is more familiar with the internals could give his opinion on this topic, any input is appreciated.
 

·
Registered
Joined
·
2 Posts
Discussion Starter · #3 ·
Thanks for your reply, I'll keep that in mind for the future. In the meantime I had contacted the Speedlink support, and a few days ago they replied and claimed that it's the first time somebody reports this particular problem so it's most probably "just" a hardware defect and I should get a replacement. But my vendor didn't have another pad of the same model in stock, so for the time being I was unable to pursue this topic any further. Maybe it really was just bad luck to get two broken pads in a row, shrug. If not, this thread might be helpful someday for other customers running into the same problem.
 

·
Registered
Joined
·
2 Posts
OMG, I have the same problem with SpeedLink XEOX! And at least last year I think to cut out the rumble because this bug is real annoying!
And of course I will never buy more products of this shitty brand "SpeedLink". Never ever again.
Inside there is a lot of dirt (factory dirt because of soldering) - the quality of the production of this gamepad is worst than noname China products.
 
1 - 5 of 5 Posts
Top