Evdev based joystick - issues

I’m porting code over to SDL1.3/2.0 and am seeing a couple (more) issues
with a joystick accessed via SDL with events. Application is a car racing
simulator.

1). The reported (polled) value is 0 when game is started, ie. before any
events are registered, this is not good as it put accelerator at ‘half
pressed’. Anyone have suggestions how to work around this…? Once pedal
is pressed everything is good.

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?

Thanks,
Simon.

I’m porting code over to SDL1.3/2.0 and am seeing a couple (more) issues
with a joystick accessed via SDL with events. Application is a car racing
simulator.

1). The reported (polled) value is 0 when game is started, ie. before any
events are registered, this is not good as it put accelerator at ‘half
pressed’. Anyone have suggestions how to work around this…? Once pedal
is pressed everything is good.

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?

Thanks,
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?

I’m also seeing this with SDL1.2.

I dug a little deeper, attached is a log taken simultaneously with evtest
and reporting what SDL events send. It ‘triggered’ with the brake being
stuck on with a value of 21282, where as evtest shows that the kernel has
reported the correct value of 255.

Also worth noting is that after the ‘stuck’ I kicked the pedal to free it
up. SDL report 8 events but the kernel sent a lot more… does SDL limit
the rate of which events are passed on (ie only 0.1s)?

Simon.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: sdl_event_missed.txt
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20121005/1a4f9f97/attachment.txt

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?

I’m also seeing this with SDL1.2.

I dug a little deeper, attached is a log taken simultaneously with evtest
and reporting what SDL events send. It ‘triggered’ with the brake being
stuck on with a value of 21282, where as evtest shows that the kernel has
reported the correct value of 255.

Also worth noting is that after the ‘stuck’ I kicked the pedal to free it
up. SDL report 8 events but the kernel sent a lot more… does SDL limit
the rate of which events are passed on (ie only 0.1s)?

In ‘SDL_PrivateJoystickAxis()’ we have the code–
if ((SDL_EventOK == NULL)
|| (*SDL_EventOK) (SDL_EventOKParam, &event)) { <— what
does this mean?
posted = 1;
SDL_PushEvent(&event);
}

I don’t understand the ‘if’ condition, but when it fails this means that
the event is NOT pushed into the SDL event queue, and the Linux code
calling this function does nothing with the return value.

Simon

SDL_EventOK is a function pointer. That ‘if’ statement is calling the
function. Specifically, SDL_EventOK is an SDL_EventFilter. This
documentation may not be for the version you’re using, but most of the info
is the same:
http://sdl.beuc.net/sdl.wiki/SDL_SetEventFilter

Jonny DOn Fri, Oct 5, 2012 at 1:05 AM, wrote:

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?

I’m also seeing this with SDL1.2.

I dug a little deeper, attached is a log taken simultaneously with evtest
and reporting what SDL events send. It ‘triggered’ with the brake being
stuck on with a value of 21282, where as evtest shows that the kernel has
reported the correct value of 255.

Also worth noting is that after the ‘stuck’ I kicked the pedal to free it
up. SDL report 8 events but the kernel sent a lot more… does SDL limit
the rate of which events are passed on (ie only 0.1s)?

In ‘SDL_PrivateJoystickAxis()’ we have the code

    if ((SDL_EventOK == NULL)
        || (*SDL_EventOK) (SDL_EventOKParam, &event)) {   <--- what

does this mean?
posted = 1;
SDL_PushEvent(&event);
}

I don’t understand the ‘if’ condition, but when it fails this means that
the event is NOT pushed into the SDL event queue, and the Linux code
calling this function does nothing with the return value.

Simon


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

To be more clear, I would expect SDL_EventOK to always be NULL unless you
called SDL_SetEventFilter(). I don’t think this code is related to the
problem you’re experiencing.

Jonny D

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?

Dug a little deep on this. It appears that I’ve only seen this with the
G27 wheel and it seems to be triggered with fast transitions between brake
and accelerator - problem can show on either axis (2 or 3 in attached
log).

This problem show with ‘testjoystick’ so I know that it is the underlying
SDL code, and not my code :wink:

Basic issue is that the last reported value for an axis is not 'released’
leaving the brake (or accelerator) ‘dragging’–
Joystick 0 axis 2 value: 11147 (tick 15358)
Joystick 0 axis 2 value: 9458 (tick 15360)
Joystick 0 axis 2 value: 8783 (tick 15361)
Joystick 0 axis 2 value: 8445 (tick 15363)
Joystick 0 axis 2 value: 7769 (tick 15365)
Joystick 0 axis 2 value: 8445 (tick 15369)
Joystick 0 axis 2 value: 8783 (tick 15373) <— axis 2 stuck
although pedal is released.
Joystick 0 axis 3 value: 0 (tick 15439)
Joystick 0 axis 3 value: 0 (tick 15440)
Joystick 0 axis 3 value: 0 (tick 15442)
Joystick 0 axis 3 value: -338 (tick 15444)

Joystick 0 axis 3 value: 32767 (tick 15528)
Joystick 0 axis 3 value: 32767 (tick 15592)
Joystick 0 axis 3 value: 32767 (tick 15592)

[ waited a long time taking screenshot ]

Joystick 0 axis 2 value: 32767 (tick 87946) <- pedal pressed
very gently, oh look it was fully released
Joystick 0 axis 2 value: 32767 (tick 87950)
Joystick 0 axis 2 value: 32767 (tick 87952)
Joystick 0 axis 2 value: 32767 (tick 87956)
Joystick 0 axis 2 value: 32767 (tick 87958)
Joystick 0 axis 2 value: 32767 (tick 87962)
Joystick 0 axis 2 value: 32767 (tick 87964)

Monitoring with ‘evtest’ simultaneously shows that both the axis return to
the ‘255’ (released) value.

Any suggestion on where to look?
Simon
-------------- next part --------------
A non-text attachment was scrubbed…
Name: SDL_joystick_stuck.txt.gz
Type: application/gzip
Size: 4469 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20121018/85593d5f/attachment.bin

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’s some more commentary here:
http://www.mail-archive.com/linux-input at vger.kernel.org/msg01920.html

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.

Any comments/thoughts?
Simon

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’s some more commentary here:
http://www.mail-archive.com/linux-input at vger.kernel.org/msg01920.html

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.

Any comments/thoughts?
Simon

-------------- next part --------------
A non-text attachment was scrubbed…
Name: missing_events.patch
Type: text/x-patch
Size: 2608 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130117/a3b1e68f/attachment.bin

1 Like