-
-
Notifications
You must be signed in to change notification settings - Fork 376
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rightclick emulation on touchscreen does not work as intended in Linux #8051
Comments
According to the description, I would say that on Linux (at least on that particular Linux) finger ids are messed up. Apparently on step 3 "finger up" event comes with wrong finger id - it comes with finger id of the second finger, and not the first finger (as it should actually be). The logic of the operation is based on the fact that the correct finger ids come from SDL (or from the touchscreen driver). If this is not the case, then, alas, of course, it will not work. Need to fix the driver (or the corresponding SDL build). |
Unfortunately, it's not possible for regular user like me, so I would appreciate if you could find some workaround. |
You can start with a simple one - which SDL version is installed on that device? Have you tried to install the latest one (2.28.5) and build fheroes2 using the latest version? |
Please tell me how to check it? And what exactly SDL is? Package "sdl2" in my system has version 2.28.5-1, so looks like it's correct version? Manjaro is actually a rolling distribution, so all software has versions close to latest. |
Looks like it is. Well, then the things may be worse than I thought.
There is no customization in fheroes2 that can deal with wrong finger ids in touchscreen events. |
So maybe I could collect some traces to check contents of actual events? |
Well, even if you add some debugging output in printf("%u %ld\n", event.type, event.fingerId); at the beginning of that function (after opening curly brace at line 899 in |
Here are results of tapping with ONE finger at a time in main game menu. Each block between minuses is a result of ONE tap on some of main menu items - load game, cancel load dialogue, etc.
What seems interesting:
Next two blocks are results of following gestures sequence:
And it looks like events are really messed up: here I changed numbers with words for better undestanding, and we see, that there is event in the middle of the sequence where second finger is released and placed again (but, of course, it's not true):
And here I tried to hold ONE finger for several seconds, so looks like 1794 is actually a "hold" event:
And finally, it's how actual movement looks like. Here I placed ONE finger on the screen, moved it several inches and released:
So seems like 1794 indicates that the finger is on the screen and is being sent more frequently when coordinates change. |
Yes, 1792 is "finger down" event, 1793 is "finger up" and 1794 is "finger motion" events.
There is nothing wrong with this as long as different fingers touching the touchscreen at the same time have unique IDs.
That was in fact the only explanation - something (SDL or, more likely, touchscreen driver) reports that the wrong finger was removed from the screen. This should not happen, this behavior is wrong. |
By the way, are these events always stored in correct order? Couldn't there be several instances of events listener running in parralel or concurrently? |
In fheroes2 there is single event loop, which asks SDL for the next event and processes it, that's all. External events of all types are processed via this single event loop, so no events can be reordered in our code. In any case, reporting of an incorrect finger ID would be difficult to attribute to some reordering. |
Preliminary checks
Platform
Linux
Describe the bug
on touch screens double finger tap does not work as intended.
Expected actions to emulate right mouse click:
Actual actions needed to emulate right click:
Here is video reproducing the issue:
rightclick_emulation_issue.mp4
Save file
Additional info
No response
The text was updated successfully, but these errors were encountered: