Apologies if I’m starting to sound like a broken record, but I got no
commentary on the patch offered below.
In my system SDL2 is dropping a chunk of joystick events, which result in
a ‘stuck brake/accelerator’ whilst playing a racing simulator. This
basically means SDL2 is unsuitable for use at this point…
The patch below detects this situation and forces a re-read of all
attached joystick axis - thus resync to the correct/current pedal
positions.
Please apply… pretty please
Simon.> ----- Original Message -----
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
correct position.
Cheers,
Simon.
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
this?
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
kernel.
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
automatically.
FYI, bugzilla.libsdl.org is a better place to make sure patches don’t get
lost.
Cheers!On Tue, Feb 5, 2013 at 4:10 PM, wrote:
Apologies if I’m starting to sound like a broken record, but I got no
commentary on the patch offered below.
In my system SDL2 is dropping a chunk of joystick events, which result in
a ‘stuck brake/accelerator’ whilst playing a racing simulator. This
basically means SDL2 is unsuitable for use at this point…
The patch below detects this situation and forces a re-read of all
attached joystick axis - thus resync to the correct/current pedal
positions.
Please apply… pretty please
Simon.
---------------------------- Original Message ----------------------------
Subject: Re: Evdev based joystick - issues
From: simon at mungewell.org
Date: Thu, January 17, 2013 11:10 pm
To: simon at mungewell.org
Cc: sdl at lists.libsdl.org
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
correct position.
Cheers,
Simon.
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
this?
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
kernel.
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
automatically.
–
Regards,
Mark de Wever
-------------- next part --------------
changeset: 6892:bd8bd90a8516
tag: tip
user: Mark de Wever <@Mark_de_Wever>
date: Sun Feb 17 14:10:30 2013 +0100
files: src/joystick/linux/SDL_sysjoystick.c
description:
Fix compilation if SYN_DROPPED is not defined.
Changeset 6844 introduced the SYN_DROPPED which is not available on some
systems (Debian Squeeze for example). This patch backs out the entire
switch case introduced SYN_DROPPED in that changeset.
diff -r 177f29ae5279 -r bd8bd90a8516 src/joystick/linux/SDL_sysjoystick.c
— a/src/joystick/linux/SDL_sysjoystick.c Sat Feb 16 23:09:10 2013 -0800
+++ b/src/joystick/linux/SDL_sysjoystick.c Sun Feb 17 14:10:30 2013 +0100
@@ -941,6 +941,7 @@
break;
}
break;
+#ifdef SYN_DROPPED
case EV_SYN:
switch (code) {
case SYN_DROPPED :
@@ -952,6 +953,7 @@
default:
break;
}
+#endif
default:
break;
}
This block at the top didn’t take care of it for you?
/* This isn’t defined in older Linux kernel headers */ #ifndef SYN_DROPPED #define SYN_DROPPED 3 #endifOn Sun, Feb 17, 2013 at 5:27 AM, Mark de Wever wrote:
On Mon, Feb 11, 2013 at 04:47:01PM -0800, Sam Lantinga wrote:
Thanks for this patch! It really helped me with some issues I was having with gamepads in XBMC.
I did have to make a couple tweaks, though:
I placed the PollAllValues for a “fresh” device inside the read loop. This was because it would fire an axis value of zero for any gamepad which was disconnected. This would not be a problem but for the fact that zero is not the resting point for some axes, therefore disconnected controllers constantly appear to be in a modified state. This way, fresh devices will be polled once they have sent the first real event.
Added button states to PollAllValues. This fixes an issue in XBMC where dropped button up events cause the button to “stick”. A key_map value 0 can only mean “unmapped” in this patch, as opposed to both “unmapped” and “key 0”.
