SDL support

[alexytomi]

A clone of PojavLauncherTeam#6462, but Amethyst

Not so much anymore

This PR basically takes only the minimum out of what's needed to get controller pass-through working properly, anything else wasn't given thought.

Thanks isXander for most of the reference material used for this PR

[alexytomi]

This compiled locally wtf

[alexytomi]

Changes

• "Enable SDL controller backend"

  • Enables SDL
  • Input passthrough to our keys input forwarder is blocked when SDL is active as it causes issues with duplicate inputs.
  • GLFW will still be present be cause there is no way to remove or disable it, if we do so forcefully, even more buggier behavior appears. To minimize the effect of this buggy behavior, I have disabled input passthrough to GLFW when the SDL subsystems are active.
    • Test: If disabled, we should have identical behavior as to before this PR with all inputs, controller or not.

• "Forcibly start SDL controller handling"

  • Starts the SDL subsystems for gamepad, joystick, and events inMainActivity.onCreate().

• Legacy4J old version detection

  • Detects whether or not Legacy4J properly loaded our SDL or used GLFW
    • If GLFW was used
      • Start the SDL subsystems for gamepad, joystick, and events.
      • Show a warning to enable the SDL backend for best experience
  • Technically this is bugged in versions 1.7.4 and below as it never removes the log listener, in that case but I am not supporting that. Update already or deal with the immense overhead of essentially having the log output open at all times (ooo scary, not really tbh).
    • We should use regex to filter out 1.7.5 and above but I don't think anyone is gonna be using those ancient versions of Legacy4J any time soon so am not gonna

• Controllable native loading mitigation

  • If controllable is found, we try to delete the natives it extracts asap, before it can dlopen them and crash because it's dlopening a glibc lib in android
    • This is a horrible race condition, a bug report should be filed with controllable to fix this.
    • This happens because controllable sets the setExtractionPath() which only falls back if the path isn't valid, else it crashes trying to dlopen the linux glibc native

[ThatStella7922]

Testing https://github.com/AngelAuraMC/Amethyst-Android/actions/runs/17873979455

Minecraft 1.21.8 fabric loader 0.17.2

Vanilla game:

Works fine, glfw controller setup wizard appeared and glfw controller support works

Controllify 2.4.1:

Worked fine too, glfw controller support disabled itself and it was purely SDL. No more pojav cursor

I think it's good ngl, this gets the Mommy Stella Seal of Approval™️

[alexytomi]

Worked fine too, glfw controller support disabled itself and it was purely SDL. No more pojav cursor
GLFW wasn't actually turned off, Controlify turns off their GLFW backend when SDL is found.

It can still be selected in Legacy4J but the inputs won't work because of me adding an if statement to not forward inputs into GLFW when SDL joystick subsystem is running.

[alexytomi]

Bugfixes

• The SDL callback did not run only once as intended
• Accidentally blocked all non-controller inputs when SDL enabled

[alexytomi]

Also just for documentation purposes, the Gamepad remapping system wasn't used because I don't wanna do the job that SDL already does, that is filter all that stuff through to an actual input again.

eventKeycode >= KeyEvent.KEYCODE_BUTTON_A && eventKeycode <= KeyEvent.KEYCODE_BUTTON_MODE ensures no weird shit controllers will crash SDL, like an oculus one

If someone somehow has a weirdshit controller they wanna use that isn't registering because of this, they can feel free to make a bug report and I'll try to fix it.

[alexytomi]

Bugfixes

• Android's garbage keyevents was leaking through to processKeyEvent again due to fixing up the keyboard input blocking
• Controllable was at the mercy of whether inotify would want to work, now we just poll it..a lot, say hi to fried CPU