Xtr126 / XtMapper

Keyboard and mouse input mapper
https://xtr126.github.io/XtMapper-docs
GNU General Public License v3.0
201 stars 22 forks source link

[Issue] Waydroid input handling and more #56

Closed ilhan-athn7 closed 6 months ago

ilhan-athn7 commented 11 months ago

Overally, the app and everything is perfectly wroking but some issues are exist;

  1. Can't use "~" key. (Fixed by dad33d1)
  2. "Mouse aim" shortcut works only if i hold the key neither if it is in "toogle" mode or "hold" mode. Regarding these, i can only use right click to switch aim mode.
  3. Can't perform two finger gesture on waydroid. (Fixed by 70d036d)

Additionally moving the cursor to screen edges or corner triggers host system actions while xtmapper is running. (Xtmapper wayland window should lock pointer and let us claim the pointer back if possible, otherwise users are responsible for disabling screen edge actions.)

Xtr126 commented 11 months ago
  1. It works on my system, what keycodes do you see when executing the client alone and pressing "~" key? keycode should contain "grave"

    Additionally moving the cursor to screen edges or corner triggers host system actions while xtmapper is running. (Xtmapper wayland window should lock pointer and let us claim the pointer back if possible, otherwise users are responsible for disabling screen edge actions.)

I already used the pointer constraints api to "constraint" the pointer to the region of the wayland window, maybe it's not enough and we will have to "lock" the pointer.

The percentage of waydroid users for XtMapper are negligible (<1% probably) so I can't spend too much time on issues related to it currently, but thanks for filing the issue I will see later.

ilhan-athn7 commented 11 months ago

The "~" key is recognized as "KEY_QUOTEDBL"

Xtr126 commented 11 months ago

Fine then I'll add another case for that keycode. Not sure about any possible side-effects though.

Xtr126 commented 11 months ago

Closing as the critical issues reported were fixed. I myself don’t use waydroid so it’s hard. Development will be focused on support for Bliss OS and other projects. Waydroid support will be in “maintenance mode” (if there are breaking changes it will be solved when possible), If someone is willing to contribute improvements for waydroid support they can fork and make a pull request.

afzl-wtu commented 9 months ago

The percentage of waydroid users for XtMapper are negligible (<1% probably) so I can't spend too much time on issues related to it currently, but thanks for filing the issue I will see later.

Waydroid Seriously lacks a keymapper. So first of all waydroid users do not know if there is keymapper that works on waydroid. I was going to build one from scratch but after surfing a lot on internet i Found this repo today. But it does not work totally on waydroid First of all it create another extra cursor in waydroid window. And alo it crashes:

# sh /sdcard/Android/data/xtr.keymapper/files/xtMapper.sh                                                                                                      
Waiting for overlay...
opening device: No such file or directory

So obviously there will never be a waydroid population here. Waydroid provide both linux and android in one place so it is far superior than bliss os or any other Android x86 desktop.

afzl-wtu commented 9 months ago

I am a Flutter developer not a Java or Kotlin developer. It is really hard for me to to fork this and make changings but I am ready to contribute and testing this project for waydroid. I learnt Linux Input subsystem yesterday. So what I understand about this project is it runs its Server through adb shell to get access to /dev/input devices in waydroid case these are :

# ls /dev/input
wl_keyboard_events  wl_pointer_events  wl_tablet_events  wl_touch_events

(When I click on "Touch to launch editor" in notification section it overlays the current app with its keybindings but then my laptop keyboard can no longer even change default Key X on Key Bubble. )

Carrying on, it start reading from /dev/input devices and manipulate them according to keymap and then send it to a single uinput device in /sys/devices/virtual/input/. Am I right? But I have one question how it translate a irregualr swip gesture. Because a human swipe is not android straight swipe it is a series of xy commands how to overcome latency?

Xtr126 commented 8 months ago

I am a Flutter developer not a Java or Kotlin developer. It is really hard for me to to fork this and make changings but I am ready to contribute and testing this project for waydroid. I learnt Linux Input subsystem yesterday. So what I understand about this project is it runs its Server through adb shell to get access to /dev/input devices in waydroid case these are :

# ls /dev/input
wl_keyboard_events  wl_pointer_events  wl_tablet_events  wl_touch_events

(When I click on "Touch to launch editor" in notification section it overlays the current app with its keybindings but then my laptop keyboard can no longer even change default Key X on Key Bubble. )

Carrying on, it start reading from /dev/input devices and manipulate them according to keymap and then send it to a single uinput device in /sys/devices/virtual/input/. Am I right?

Sorry for the late reply, I didn't see your comment as you posted it in a closed issue. Reading from /dev/input inside a waydroid container was tried but not feasible as it's not possible to constraint the pointer that way. Currently it reads input in the same way a usual wayland application on Linux would do. Now the wayland client runs in the host Linux system, not inside Android.

First of all it create another extra cursor in waydroid window.

It has been fixed in the dev branch of XtMapper (user app) but not in the latest release. I haven't found a way to hide Waydroid's own cursor yet, but it can be moved to a corner by the user.

But I have one question how it translate a irregualr swip gesture. Because a human swipe is not android straight swipe it is a series of xy commands how to overcome latency?

There is an option in XtMapper settings to adjust swipe delay to make it either more human-like or fast.