If figured out a solution to this problem, patch attached.
When a ‘SYN_DROPPED’ event is detected, each of the active axis for the
joystick are polled and the result returned to the application. This
counteracts the stuck axis and my driving game now works as expected.
I also included a ‘fresh’ flag so a newly opened joystick is polled for
values, which would normally only be sent when moved. This helps get
controls in a ‘normal’ position at start of game (rather than being stuck
at 1/2 value).
The ‘SYN_DROPPED’ situation can be forced by '^Z’ing the testjoystick
application and moving the joystick so the buffer overflows. ‘fg’ will
restart the application and the axis will ‘magically’ return to the
2). I am seeing some events being missed, this is (most noticably)
manifesting as the brake being slight ‘stuck on’. This can be clear by
pressing the pedal again, but is very frustrating to have your car
suddenly slow down with the brakes dragging. Anyone else experiencing
A bit of a thread bump and update on this, although I don’t yet have a
solution. I used the ‘testjoystick’ from yesterday’s SDL2 snapshot and
confirmed the problem still exists.
I would have to state that at present these behaviour makes SDL2
unsuitable for a driving simulator. This also occurs with SDL1 if you use
event based joysticks (rather than the default /dev/js0).
It seems that my wheel is sending events too quickly, or rather the system
is not consuming them fast enough and there is a buffer overflowing in the
The kernel issues the ‘SYN_DROPPED’ signal when this happens.
There is also a mention of the ‘EVIOCGABS()’ call which should (not tested
it) cause the wheel to return the current value for the axis.
To my mind this would be extremely useful, both when starting up the new
connection with an event based joystick to get first value correct and in
situations where the buffers overflow - allowing a re-sync to happen
-------------- next part --------------
A non-text attachment was scrubbed…
Size: 2608 bytes
Desc: not available