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 2284

Summary: [Android] More suggestions for handling joystick input
Product: SDL Reporter: ny00
Component: joystickAssignee: Sam Lantinga <slouken>
Status: RESOLVED WONTFIX QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: gabomdq
Version: HG 2.0   
Hardware: All   
OS: Android (All)   

Description ny00 2013-12-03 16:43:21 UTC 
A couple of suggestions, looking at SDLActivity.java in its current state:

- In the constructor of SDLJoystickHandler_API12, InputDevice.SOURCE_CLASS_JOYSTICK is used as a filter for picking the input devices which should be classified as SDL joysticks. But, I have this feeling that there may be some input device with gamepad buttons and no analog axes, reporting just InputDevice.SOURCE_GAMEPAD and not InputDevice.SOURCE_CLASS_JOYSTICK. So it's probably better to check for InputDevice.SOURCE_GAMEPAD as well. Of course this is not relevant to the motion ranges, at least the way I understand it.
I'm not entirely sure it's good to do the same with InputDevice.SOURCE_DPAD, though, due to some unusual cases as described here: http://www.android-hilfe.de/3316725-post10.html

- In SDLJoystickHandler_API12.handleMotionEvent, InputDevice.SOURCE_JOYSTICK is used. While it appears to be the only source that belongs to the source class of InputDevice.SOURCE_CLASS_JOYSTICK at the moment, it may be better to use InputDevice.SOURCE_CLASS_JOYSTICK instead, for the sake of consistency, as well as covering devices with joystick-like sources in the future (if a new joystick-class source is added).
Comment 1 ny00 2013-12-03 17:01:23 UTC 
On a side-note, just for the sake of documentation (if not already stated elsewhere):

As discussed beforehand, one difficulty of the porting process is that keyboard and gamepad buttons aren't that different on Android, API-wise. This can lead to a complication in the following scenario.

Suppose that for some gamepad, it is reported that it has the sources SOURCE_KEYBOARD and SOURCE_GAMEPAD. In addition to buttons with familiar gamepad keycodes, it has a button with keycode KEYCODE_BACK. A KeyEvent with this keycode can then be translated:
- To an SDL keyboard event (which seems to be the current behavior).
- To an SDL joystick event.

On the one hand, with the second approach it should be possible to tell from which controller does the button press/release come.
But, on the other hand, this can lead to a level of inconsistency. SDL may report a back button press/release as a keyboard event (probably the case with most Android-powered devices), while it may also be reported as a joystick event (with controllers). This can be a clear issue when the controller is a part of the device itself (e.g., the Nvidia Shield).

I guess this shows that major changes to the SDL API are a must for full-featured handling of input devices on the Android platform, and it's clear they may not arrive before SDL 2.1/2.2 (or even 3.0).
Comment 2 Gabriel Jacobo 2013-12-04 12:58:54 UTC 
Thanks for the suggestions. Unless we can get our hands on one of this "corner case" devices to test changes, I don't think we should be proactive in this case :)