Open orbea opened 1 year ago
This should not be a driver bug because the driver initializes with force feedback support enabled, the device should only become available after the rumble notification, and then the feedback driver will already be there. Could you try with module parameter ff_connect_notify=0
please?
I unloaded hid_xpadneo
with rmmod
and then reloaded it with modprobe hid_xpadneo ff_connect_notify=0
.
Then I repeated both scenarios.
1.
$ ./sdl2hp
Joystick Connected: Xbox 360 Controller
Instance ID: 0, Player: 0
Force Feedback Enable Failed: Haptic: Invalid haptic device identifier
Ports: 1 0 0 0
2.
$ ./sdl2hp
Joystick Connected: Xbox 360 Controller
Instance ID: 0, Player: 0
Force Feedback Enabled
Ports: 1 0 0 0
Instance ID: 0
Joystick 0 Disconnected
Ports: 0 0 0 0
Joystick Connected: Xbox 360 Controller
Instance ID: 1, Player: 0
Force Feedback Enabled
Ports: 1 0 0 0
This now matches the behavior with the sony dualshock3 controller where the error message is the same and the second scenario works correctly.
Potentially there are two different bugs in both xpadneo and SDL2? Or perhaps the test program is doing something wrong? I will make an SDL2 issue soon.
I made a SDL2 issue here. https://github.com/libsdl-org/SDL/issues/6250
Well, just because without the rumble notification the force feedback device becomes available sooner, doesn't mean there isn't a race condition in SDL: It should wait until the driver initialization settled. So, yes, xpadneo should probably not delay the initialization as long but SDL should be unaffected by whether it takes 9ms, 90ms, or 900ms: The appearance of such additional features is not atomic in Linux.
Without that rumble notification delay, we are actually doing it exactly the same way as hid-microsoft.
But this delay is a longstanding issue I'd like to avoid anyways. There's a plan on my agenda to fix it when introducing haptic feedback for mouse mode (and normal gamepad usage if someone wants to enable that instead of rumble).
That said, I think it's a racing bug in SDL although xpadneo could and should act faster here.
OTOH, the test program may need to consider looking for the haptic property again later - and thus SDL behavior may be totally valid. What happens if you delay checking SDL_JoystickIsHaptic(...)
by 1000ms?
Yes, with this diff for the behavior for the test program now matches the sony dualshock3 controller.
--- a/sdl2hp.c
+++ b/sdl2hp.c
@@ -62,6 +62,8 @@ int main(int argc, char *argv[]) {
SDL_JoystickGetPlayerIndex(joystick[port])
);
+ SDL_Delay(1000);
+
if (SDL_JoystickIsHaptic(joystick[port])) {
haptic[port] =
SDL_HapticOpenFromJoystick(joystick[port]);
So as you said xpadneo could improve this delay and SDL could fix this race condition. I will make a second related SDL issue soon.
I made a second SDL issue. https://github.com/libsdl-org/SDL/issues/6253
Version of xpadneo
https://github.com/atar-axis/xpadneo/commit/48f4b119fdef9479d5e45056dc7a234e8959af0d
Controller Model
Connection mode
Installed Software
N/A
Protocol Information
evtest
is showing issues (describe the issues below)BTN_NORTH
andBTN_WEST
are intentionally swappedjstest
is showing issues (describe the issues below)gamepad-tool
is showing issues (post console output below)Please describe how it is failing below in the next sections.
Severity / Impact
Describe the Bug
With SDL2 programs and maybe other programs the rumble does not work with some hotplugging under certain circumstances.
For example with the following test program created by the jgrf developer.
sdl2hp.c.txt
Build it:
./sd2hp
And the second scenario.
./sd2hp
Instance ID: 0 Joystick 0 Disconnected Ports: 0 0 0 0
Joystick Connected: Xbox 360 Controller Instance ID: 1, Player: 0 Device is not haptic Ports: 1 0 0 0
Controller and Bluetooth Information
xpadneo-btmon.txt xpadneo-dmesg.txt xpadneo-lsusb.txt
Additional Context
There is a SDL2 hotplugging example repo here.
https://github.com/carmiker/sdl2-hotplug-example