Skip to content
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

touch support in wayland (gnome, phosh) #1536

Closed
2 tasks done
subjectdenied opened this issue Jun 22, 2020 · 8 comments
Closed
2 tasks done

touch support in wayland (gnome, phosh) #1536

subjectdenied opened this issue Jun 22, 2020 · 8 comments

Comments

@subjectdenied
Copy link

subjectdenied commented Jun 22, 2020

  • I have read the FAQ.
  • I have searched in existing issues.

Environment

  • OS: Mobian (Debian Linux for Pinephone)
  • scrcpy version: latest
  • installation method: apt
  • device model: -
  • Android version: -

Describe the bug
using phosh (phone sized wayland client) on my pinephone no touch events are registered in scrcpy, while it is working flawlessly with X11. i tested this also under gnome using wayland, and touch is also not recognized

@rom1v
Copy link
Collaborator

rom1v commented Jun 22, 2020

Oh, that's unfortunate. 😞

However, scrcpy uses SDL to receive input events (SDL_TouchFingerEvent), so the problem should be reported against libsdl.

@subjectdenied
Copy link
Author

subjectdenied commented Jun 22, 2020

i asked in #SDL on IRC and got a reply that touch might be only implemented for wayland when using QT

on further investigation i found that on wayland touch is actually working, however the surface that recognizes touch seems to be scaled down to a small area of the screen (i'd say a 1/8) compared to the real window-dimensions

@rom1v
Copy link
Collaborator

rom1v commented Jun 23, 2020

on further investigation i found that on wayland touch is actually working, however the surface that recognizes touch seems to be scaled down to a small area of the screen (i'd say a 1/8) compared to the real window-dimensions

Oh, interesting! And the mouse works as expected?

It might be #15, but specific to touch events.

Is it better with this change?

diff --git a/app/src/input_manager.c b/app/src/input_manager.c
index e8ba9f79..588432c6 100644
--- a/app/src/input_manager.c
+++ b/app/src/input_manager.c
@@ -467,7 +467,7 @@ convert_touch(const SDL_TouchFingerEvent *from, struct screen *screen,
 
     int ww;
     int wh;
-    SDL_GL_GetDrawableSize(screen->window, &ww, &wh);
+    SDL_GetWindowSize(screen->window, &ww, &wh);
 
     // SDL touch event coordinates are normalized in the range [0; 1]
     int32_t x = from->x * ww;

@rom1v rom1v added the bug label Jun 23, 2020
@subjectdenied
Copy link
Author

this actually fixed it, thanks for looking into it!

will test mouse later also

@rom1v
Copy link
Collaborator

rom1v commented Jun 24, 2020

OK, thank you, so I'll write a better fix. I'll ask you to test again when it's done :)

rom1v added a commit that referenced this issue Jun 25, 2020
Touch events were HiDPI-scaled twice:
 - once because the position (provided as floats between 0 and 1) were
   converted in pixels using the drawable size (not the window size)
 - once due to screen_convert_to_frame_coords()

One possible fix could be to compute the position in pixels from the
window size instead, but this would unnecessarily round the event
position to the nearest window coordinates (instead of drawable
coordinates).

Instead, expose two separate functions to convert to frame coordinates
from either window or drawable coordinates.

Fixes #1536 <#1536>
Refs #15 <#15>
Refs e40532a
@rom1v
Copy link
Collaborator

rom1v commented Jun 25, 2020

Here is a proper fix: fb5e619

Could you confirm that it works, please?

@subjectdenied
Copy link
Author

working perfect, thanks for looking into this!

@rom1v rom1v added the hidpi label Jun 26, 2020
rom1v added a commit that referenced this issue Jun 27, 2020
Touch events were HiDPI-scaled twice:
 - once because the position (provided as floats between 0 and 1) were
   converted in pixels using the drawable size (not the window size)
 - once due to screen_convert_to_frame_coords()

One possible fix could be to compute the position in pixels from the
window size instead, but this would unnecessarily round the event
position to the nearest window coordinates (instead of drawable
coordinates).

Instead, expose two separate functions to convert to frame coordinates
from either window or drawable coordinates.

Fixes #1536 <#1536>
Refs #15 <#15>
Refs e40532a
@rom1v
Copy link
Collaborator

rom1v commented Jun 27, 2020

Thank you for your report and feedback 👍

Merged into dev: e8a565f

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants