Android: Touchscreen controlling doesn't work at some devices when using SDL_GetTouchFinger() calling by touch IDs #5322
Comments
|
strange, and what are the name of the touch devices ? |
|
Okay, I see: |
|
I expected the touch device will return most of the touchscreen, but looks like it adds even more things, including S-Pen as independent touch device |
|
At the Java side I have the next code that adds touch devices: but looks like it adds all of them than filter touchscreen only.... |
|
I remember I saw previously errors with this code. See: #2718
It seemed to me there was errors in using SOURCE_* vs SOURCE_CLASS_* types.
|
Can you add some trace in the java file, so that: |
|
Okay so, a first 5 devices it adds on launch from the Java side, and then, on every touch event, it adds one another device from C side: |
|
btw, When I replace condition: device.getSources() & InputDevice.SOURCE_TOUCHSCREEN) != 0with device.getSources() & InputDevice.SOURCE_TOUCHSCREEN) == InputDevice.SOURCE_TOUCHSCREENNow it adds three devices only at Java side: |
|
Can you add the "name" for the java trace. |
For C code it just adds constant empty line |
|
|
ok, some more check:
|
|
Done:
|
|
And the device 6 is actual touchscreen that is used at me |
|
(so, C-side had simply request the existing touch device) |
|
Ok Great ! the java code that does it is: if (device != null && (device.getSources() & InputDevice.SOURCE_TOUCHSCREEN) != 0) {
nativeAddTouch(device.getId(), device.getName());
}The layout of the 'sources' is InputDevice.SOURCE_TOUCHSCREEN is defined as So the id[5] isn't selected because it's a "TOUCHSCREEN" but because it is a MOUSE, and the MOUSE is a CLASS_POINTER, like the TOUCHSCREEN is a CLASS_POINTER. @Wohlstand can you explain how it breaks you app ? @slouken ? device.getSources() & InputDevice.SOURCE_TOUCHSCREEN) == InputDevice.SOURCE_TOUCHSCREENSo we select devices who have at least a SOURCE_TOUCHSCREEN inside ? Also some are "stylus" should they be SDL_TOUCH_DEVICE_INDIRECT_ABSOLUTE/RELATIVE ? (they are currently all SDL_TOUCH_DEVICE_DIRECT) ? |
|
The stylus is a direct input device, and it works over the main device. (in my case it's an S-Pen stylus) I guess, everything that doesn't contain a "touchscreen" shouldn't be added here. Anyway, SDL2 seems to need an extra description of touch device types to tell, what is it: touchscreen, or the side-plugged touchpad thing. |
Right now yes, as the touchscreen is used mainly on Android devices (but possibly, some special embedded devices would have the non-screen touchpad or something also that would be cool to utilize). |
|
I think this is a typo. because the first shot was to filter with SOURCE_TOUCHSCREEN
|
1bsyl
added a commit
that referenced
this issue
Feb 7, 2022
Wohlstand
added a commit
to Wohlstand/TheXTech
that referenced
this issue
Feb 7, 2022
|
I'll send a test build to my buddy (who has troubles with a touchscreen controller: it just doesn't work at all at his end), and will say, had they solved the problem or not... |
|
@1bsyl, just now I found another case, I finally sent a debug build to my buddy, and what his device reported: Devices got been added to the list of touch devices: The device with id=2 got been added to the list Devices got been retrieved using SDL API: And.... So, because of this weird case, buddy has touchscreen controller don't work at all |
|
P.S. Forgot to tell you that I updated my SDL2 up to 2.0.20 |
|
ok ... in SDLActivity.java, we do: 1939 /*
1940 * Prevent id to be -1, since it's used in SDL internal for synthetic events
1941 * Appears when using Android emulator, eg:
1942 * adb shell input mouse tap 100 100
1943 * adb shell input touchscreen tap 100 100
1944 */
1945 if (touchDevId < 0) {
1946 touchDevId -= 1;
1947 }So you should also do that in initTouch(): diff --git a/android-project/app/src/main/java/org/libsdl/app/SDLActivity.java b/android-project/app/src/main/java/org/libsdl/app/SDLActivity.java
index 812163ca3..173fcb061 100644
--- a/android-project/app/src/main/java/org/libsdl/app/SDLActivity.java
+++ b/android-project/app/src/main/java/org/libsdl/app/SDLActivity.java
@@ -1205,7 +1205,17 @@ public class SDLActivity extends Activity implements View.OnSystemUiVisibilityCh
for (int id : ids) {
InputDevice device = InputDevice.getDevice(id);
if (device != null && (device.getSources() & InputDevice.SOURCE_TOUCHSCREEN) == InputDevice.SOURCE_TOUCHSCREEN) {
- nativeAddTouch(device.getId(), device.getName());
+ int touchDevId = device.getId();
+ /*
+ * Prevent id to be -1, since it's used in SDL internal for synthetic events
+ * Appears when using Android emulator, eg:
+ * adb shell input mouse tap 100 100
+ * adb shell input touchscreen tap 100 100
+ */
+ if (touchDevId < 0) {
+ touchDevId -= 1;
+ }
+ nativeAddTouch(touchDevId, device.getName());
}
}
} |
|
But the -1 is |
|
Can you log again in SDLActivity.java At the beginning of the function
|
However, finger events from SDL_PollEvents came from -2 touch device, but actual touch device is 2 |
|
@Wohlstand: |
|
Thanks, I got the "epos". had to use my translator .. At first, I though that was a hw device :) |
|
I will try to make some tweaks after I'll complete my today's main job and will send another debug build to my buddy (there is some waiting that will be needed as he lives with 7 hours later than me (my time zone is UTC+3), and he is asleep now) |
|
thanks ! |
|
for the record: |
Wohlstand
added a commit
to Wohlstand/TheXTech
that referenced
this issue
Feb 8, 2022
- every onTouch() event happening - Set SDL hints to disable mouse<->touch event mapping libsdl-org/SDL#5322
|
Okay, I did some tweaks at my side and made another debug build for my buddy, will wait tomorrow once he wakes up and gives us another log file with the result |
|
Okay, my buddy finally tested my debug build with onTouch() trace and both mouse-touch mapper hints disabled, so, result is next: Load trace: SDL API touch devices: Touch poll events mixed with Java side trace: Little note: " = Finger press..." events are traces of fingers, and ID of each finger is, I'd clean up this log, but it's pain to do by phone, I'm not at home right now |
1bsyl
added a commit
that referenced
this issue
Feb 9, 2022
…because they can send SOURCE_TOUCHSCREEN events even if getSources() doesn't declare them.
|
@Wohlstand btw, notice the previous SDLControllerManager.java changes is different than yours) |
|
eventually to get more information, you could also log in onTouch to see the "sources" of the inputdevice of the event. {
InputDevice device = InputDevice.getDevice(event.getDeviceId());
int sources = device.getSources();
//log what "sources" look like
} |
Don't worry, I'll put the change manually |
|
(mainly, mine is different because I had to inject lots of logging) |
Wohlstand
added a commit
to Wohlstand/TheXTech
that referenced
this issue
Feb 9, 2022
- Using "isVirtual" instead of -1 - More debug logging against the touch device input libsdl-org/SDL#5322
|
Made, so, gonna send the debug build to my buddy again |
|
Aaaaand, another updated log: Load: SDL API load: Touch events: |
|
ok. So the InputDevice is still reported as a "DPAD KEYBOARD", even if it sends TOUCHSCREEN sourced events.
If you're ok, let's close the issue. we've added the check with isVirtual() to add the inputDevice so you can detect it as potential SDL_Touch. And it doesn't hurt even other part of the code |
|
Yea, because the main problem - a touchscreen didn't worked at my buddy - has been solved, and possibly, solved at many other people who also reported me the "touch controls don't react" mystery. And, because we all cleaned all unonowledge against this whole thing, etc. That was a nice cooperation, thank you very much :) |
Wohlstand
changed the title
giannoug
pushed a commit
to giannoug/SDL
that referenced
this issue
Nov 13, 2022
giannoug
pushed a commit
to giannoug/SDL
that referenced
this issue
Nov 13, 2022
giannoug
pushed a commit
to giannoug/SDL
that referenced
this issue
Nov 13, 2022
… since there are several bits (see libsdl-org#5322, libsdl-org#2718)
giannoug
pushed a commit
to giannoug/SDL
that referenced
this issue
Nov 13, 2022
…t handle DPAD GAMEPAD (see libsdl-org#5322, libsdl-org#2718)
giannoug
pushed a commit
to giannoug/SDL
that referenced
this issue
Nov 13, 2022
…ch device because they can send SOURCE_TOUCHSCREEN events even if getSources() doesn't declare them.
giannoug
pushed a commit
to giannoug/SDL
that referenced
this issue
Nov 13, 2022
…ch device, fix compilation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello!
Recently I found that some users has problem that touchscreen doesn't work for them.😱
Later, by my log file, I found that SDL_GetNumTouchDevices() got returned two touch screen devices, and seems, one of them is a ghost tha steals control and makes no way to use the real one. At my phone the touch control works fine, however, I suddely found it returns !!!6!!! touch devices
(Note, to choose the device to work, I do scan all devices to find any that has fingers placed)
Was this bug been fixed at 2.0.20? Why these mystery touch devices got appear here?
The text was updated successfully, but these errors were encountered: