Fix GameActivity touch inputs in the presence of a stylus #185
Conversation
This makes parsing logging a bit nicer for debugging stuff Changelog-Changed: Change threaded_app logs to android_activity Signed-off-by: William Casarin <jb55@jb55.com>
I noticed touch inputs weren't working on my Galaxy S9 tab device which
includes a stylus. The value was 0xD002 for source, which seems to be:
SOURCE_CLASS_POINTER 0b0000 0000 0000 0010
SOURCE_STYLUS 0b0100 0000 0000 0000
SOURCE_BLUETOOTH_STYLUS 0b1000 0000 0000 0000
SOURCE_TOUCHSCREEN 0b0001 0000 0000 0000
----------------------------------------------
0xD002 = 0b1101 0000 0000 0010
Let's modify default_motion_filter to use bitwise AND (&) instead of
equality (==) when checking SOURCE_TOUCHSCREEN. This ensures stylus
inputs (which combine touchscreen and stylus flags) are not discarded,
while still filtering non-touch events.
Changelog-Fixed: Fix touch inputs on tablets with a stylus
Signed-off-by: William Casarin <jb55@jb55.com>
46c2393 to
3de4f3a
Compare
|
could we perhaps just take a more recent source of the upstream GameSDK, which fixed this a long time ago here? |
|
@rib would know best how to continue migrating and updating this crate, I only use (and feel comfortable reviewing/approving) native-activity parts. |
Oh i had no idea this was sourced elsewhere |
|
Could this be why i’m seeing buggy stuff here as well? Not sure where to go from here, but if its a matter of updating something from upstream at least i could try that |
|
We've had quite a few reports that the vendored I'm still using |
From what i was told, NativeActivity is deprecated and it was difficult to get the keyboard to work. I am able to show the keyboard and process text events with GameActivity through winit to egui. If i can resolve these remaining issues i might be able to actually launch our egui app on android, and hopefully open up egui dev on mobile a bit. |
|
My plan is to create patches of everything since the last clean re-import (c471fdf) and re-apply them on top of the latest. I will see how far I get with this |
fwiw, I intentionally didn't reply to that comment while it came across as kinda rude / accusatory. I have opened various upstream issues with GameActivity in the past.
The comment about using Currently if you're using the GameActivity backend you should ideally use version 2.0.2 (ref: #88). If you use another, newer, version it's possible it might work but that would depend on whether they have changed the internal ABI between their native code and JNI which isn't something they would be required to maintain. |
Nice; yeah it could be good to do another update if there have been some upstream fixes for |
hmm, definitely getting dejavu feelings here but can't really recall anything specific right now - feels like something that's come up before. |
|
Looks like latest alpha version is 4.2.0? not sure what I should target. latest and greatest? formatting commits: ugh this should be fun |
maybe I'm thinking of this: #79 |
I guess we should target the latest stable release available on Jetpack: https://developer.android.com/jetpack/androidx/releases/games (i.e. 4.0.0) |
I'm sorry, I thought the same and initially wanted to say something about it but that never materialized. Said something now, hope you didn't feel too alone/bothered when getting complaints for all your hard work.
I don't think this can truly be deprecated because it's part of the core Android framework and always supposed to be there and "just work". Yes, because it's hardlocked into the Android system it becomes impossible to forward-port bugfixes and new features, which is possible with So far everyone (at least we) seem to be moving into the direction of making custom subclasses of Unfortunately a common system for building and distributing that has not yet materialized, I'm working on some ideas (also being the main maintainer for |
are there any examples of this approach? or is this still just an idea |
yeah in an ideal world I still tend to think the best solution would be for us to create a Although it addresses a number of issues in
|
It's just a pipe dream still that we've discussed a bunch of times over the years |
|
In practice it wouldn't necessarily be a huge undertaking to bootstrap an experimental One of the awkward things to address would be the need to host corresponding Java/Kotlin packages, probably on Maven Central. |
|
had Claude do an analysis of how much work this would be. I just code2prompt'd the game-text-input codebase. Just leaving this here for my future self and others who are crazy enough to do this (but honestly doesn't seem like a bad idea) https://claude.ai/share/5eb35755-917d-466c-a2ce-d8d9d06bdef0 |
|
My inner correctness exploded when reading how awfully wrong that AI output is. I need to recover from reading this. |
Btw, in the case of the game-text-input library specifically, that's probably one case where we wouldn't really want to just port the existing native side to Rust and we should instead aim for a different Java/Kotlin implementation too that lets us support an IME interface that's more expressive. One of the pain points with enabling IME in Winit on Android has specifically been with the limitations of the game-text-input IME interface. the tedious part before that is just porting the C/C++ integration code to Rust but since I already did that for NativeActivity we could either use that as a starting point or at least a point of reference for a similar port for GameActivity. |
|
Should we target the Preedit/Commit stuff like in the winit IME apis? I haven't thought too much about that but I did find it weird that things did not map well over there. |
exactly - the game-text-input api is a bit too simplistic, which makes it awkward to implement IME APIs on top of it in toolkits / Winit. |
(though maybe the latest version is better - I haven't really checked recently) |
Unfortunately an implementation of this is in a private repository. Not that it matters too much, I was put on a separate project right as someone else started implementing it in our codebase and despite my efforts to describe the ideal outcome that would be friendly to the entire Android community/crates/tooling we're building here at It's not very complicated though. All I'll add is some very basic tooling in Secondly, that For end-users of This still needs a way to then subclass our Finally, this all neatly integrates with the new classes and Java/JNI interop that I'm adding to the But yeah, as @rib already mentioned, we'd first have to bootstrap this whole activity before someone might want to start taking a stab at adding IME APIs to it (not me).
@rib how "direct" was this C++-to-Rust port of |
|
rust-mobile/ndk#498 @jb55 this is your team (or someone working on the same project at least), right? 😂 |
Lol yeah he's our pm he's a character |
|
Closing this in favor of: |
I noticed touch inputs weren't working on my Galaxy S9 tab device which
includes a stylus. The value was 0xD002 for source, which seems to be:
Let's modify default_motion_filter to use bitwise AND (&) instead of
equality (==) when checking SOURCE_TOUCHSCREEN. This ensures stylus
inputs (which combine touchscreen and stylus flags) are not discarded,
while still filtering non-touch events.