We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2214

Summary: Suggestions for fixes for keycode_to_SDL
Product: SDL Reporter: ny00
Component: joystickAssignee: Gabriel Jacobo <gabomdq>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: philipp.wiesemann
Version: HG 2.1   
Hardware: All   
OS: Android (All)   

Description ny00 2013-11-06 16:31:44 UTC 
With the recent inclusion of joystick support for Android (for actual controllers, not an accelerometer), the function keycode_to_SDL found in android/SDL_sysjoystick.c and called from SDLActivity.java is responsible for converting an Android KeyCode to an SDL joystick button number.

I. One minor bug I see in it is the unused variable "final".

II. A more major problem is the fact that an unrecognized KeyCode may arrive. There are two possible solutions for that:

1. Check in SDLActivity.java that keycode_to_SDL returns a nonnegative number before calling SDL_PrivateJoystickButton (for a button press, as well as release), and let keycode_to_SDL return some negative number if it gets an unrecognized KeyCode as the input.
2. Alternatively, modify keycode_to_SDL such that any KeyCode can be mapped to a (nonnegative) gamepad button number in a 1-1 fashion. In such a case, it is probably good to warn the user of SDL that no bound may be assumed, not even the value returned by SDL_JoystickNumButtons. (See Bug 2213 for some details about this function on Android.)
Comment 1 Philipp Wiesemann 2013-11-10 14:18:55 UTC 
(In reply to ny00 from comment #0)
> I. One minor bug I see in it is the unused variable "final".

This was fixed now:
http://hg.libsdl.org/SDL/rev/8d4d3fdca1aa

It was originally reported in bug 1700 and was like a regression. :)
Comment 2 Gabriel Jacobo 2013-11-10 23:14:36 UTC 
This takes care of II : http://hg.libsdl.org/SDL/rev/f19c0aca56aa
Comment 3 ny00 2013-11-11 09:02:50 UTC 
Thanks for the bug fixes (and same in regards to other related bug reports)!

Yeah, I've realized that limiting ourselves to 36 buttons is probably the simpler approach. If all possible Android keycodes are handled, the reported number of supported buttons should be pretty large (basically getMaxKeyCode() plus 1, just to be on the safe side).