[rcore_android] Restore face-button input on Android gamepads#5824
Open
Tubbles wants to merge 1 commit intoraysan5:masterfrom
Open
[rcore_android] Restore face-button input on Android gamepads#5824Tubbles wants to merge 1 commit intoraysan5:masterfrom
Tubbles wants to merge 1 commit intoraysan5:masterfrom
Conversation
Tubbles
changed the title
Tubbles
force-pushed
the
fix-android-gamepad-keyboard-source-regression
branch
from
ae73a6f to
6b79e2a
Compare
Tubbles
changed the title
Tubbles
force-pushed
the
fix-android-gamepad-keyboard-source-regression
branch
4 times, most recently
from
b42abcf to
313375c
Compare
The KEYBOARD-source veto added in raysan5#5439 drops face-button key events that arrive with both AINPUT_SOURCE_KEYBOARD and AINPUT_SOURCE_GAMEPAD set on the source bitmask. Confirmed reproducible on GameSir X2 Type-C and 8BitDo Ultimate Bluetooth, both reporting source 0x501 on every face-button key event. This source-bit pattern is general AOSP behaviour since Android 3.2 (commit 6f2fba4 in frameworks/base, Feb 2011): EventHub adds InputDeviceClass::KEYBOARD to any device whose evdev keyBitmask claims gamepad buttons (BTN_JOYSTICK..BTN_DIGI), and KeyboardInputMapper::getEventSource stamps the resulting KEYBOARD|GAMEPAD source on every outgoing key event. Use AndroidTranslateGamepadButton(keycode) as the discriminator instead. Recognised gamepad keycodes route to the gamepad path; unknown keycodes fall through to the keyboard handler. Assisted-by: Claude:claude-opus-4-7
Tubbles
force-pushed
the
fix-android-gamepad-keyboard-source-regression
branch
from
313375c to
4185094
Compare
Tubbles
changed the title
Author
|
It seems like this is also how SDL and Allegro 5 have solved this quirk |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
raylib 6.0's
rcore_android.c:1279guard!FLAG_IS_SET(source, AINPUT_SOURCE_KEYBOARD)drops face-button key events that arrive with bothAINPUT_SOURCE_KEYBOARDandAINPUT_SOURCE_GAMEPADset on the source bitmask. The keyboard fallback then seesmapKeycode[AKEYCODE_BUTTON_*] == 0and the press is dropped. The GameSir X2 Type-C exhibits this regression: every face-button key event arrives with source0x501(KEYBOARD | GAMEPAD | CLASS_BUTTON). Reproducible on an 8BitDo Ultimate Bluetooth as well.The combined source-bit pattern is general AOSP behaviour, not a controller quirk, and has shipped in every Android release since 3.2 (Feb 2011). Commit
6f2fba4extendedEventHub::openDeviceLockedto addInputDeviceClass::KEYBOARDto any input device whose evdevkeyBitmaskclaims gamepad buttons (BTN_JOYSTICK..BTN_DIGI), in addition toInputDeviceClass::GAMEPAD.InputDevice::createMappersthen ORs both classes into thekeyboardSourceand installs aKeyboardInputMapper, whosegetEventSource()returnsdeviceSources & (AINPUT_SOURCE_KEYBOARD | AINPUT_SOURCE_DPAD | AINPUT_SOURCE_GAMEPAD)and stamps that on every outgoing key event. For the X2 (deviceSources = 0x01000511) the mask yields0x501.The fix uses the keycode as the discriminator.
AndroidTranslateGamepadButton(keycode)already enumerates exactly the keycodes raylib routes as gamepad buttons: a recognised keycode goes to the gamepad path, an unrecognised keycode falls through to the keyboard handler instead of being dropped. This mirrorsKeyEvent.isGamepadButton(int), a pure keycode-range test that ignores the source. Side effect:CORE.Input.Gamepad.ready[0]now flips to true only when a recognised gamepad keycode arrives.Assisted-by: Claude:claude-opus-4-7