TPMouse VS ydotool

And for Windows, my https://github.com/esporttoys/TPMouse was inspired by warpd itself but focuses more on the intuitive usability of direct cursor control via inertia/momentum.

You may be interested in how I did my Windows script for adding three-finger drag[0].

Basically, it is an independent subscriber to RawInput messages that only keeps track of whether or not to send three-finger drag, and posts emulated mouse messages using SendInput. I have a few other scripts that each run as independent userland processes that only monitors their own trigger and nothing else.

Tangentially, not sure if this might serve for some inspiration, but my TPMouse[1] script implemented inertia in a framerate-independent way so that it uses very little resource while having perfect simulation stability.

A previous discussion where I explained the analytic derivation for this low-resource exact-solution damped inertia can be seen in [10]

[0] https://github.com/EsportToys/PrecisionThreeFingerDrag/blob/...

[1] https://github.com/EsportToys/TPMouse

[10] https://old.reddit.com/r/Trackballs/comments/ym9q2t/tpmouse_...

With the TPMouse script I implemented the activation shortcut as LShift+RShift+ which I felt had a nice balance between deliberateness and easy-to-reach (since you are using it with your hands on homerow).

Though because some keyboards have key rollover issues with using both Shifts, Capslock+ is also allowed as an alternative activation shortcut.

[0] https://github.com/EsportToys/TPMouse

I personally use AutoIt a ton as a super fast way to quickly prototype GUIs. It's basically a really simple entrypoint for WinAPI.

Shameless plug: my script for emulating a trackball with your keyboard [0], and my tray app for quickly tweaking your cursor speed (usually for when I'm drawing something)[1]

  [0] https://github.com/EsportToys/TPMouse

Wayland provides little by design, so this is quite typical. For example:

Screensharing is handled by pipewire [0], changing keyboard layouts aren't defined [1] by wayland, and generally anything Wayland devs think would 'corrupt' their protocol.

They leave most things to the compositor to implement, which leads to significant fragmentation as every compositor implements it differently.

Long gone are the days of xset and xdotool working across nearly every distro due to a common base, now the best you'll get is running a daemon as root to directly access `/dev/uinput` [2] or implementing each compositors accessibility settings (if they have them) as a workaround.

[0] https://superuser.com/questions/1221333/screensharing-under-...

[1] https://unix.stackexchange.com/questions/292868/how-to-custo...

[2] https://github.com/ReimuNotMoe/ydotool

I personally use libinput-gestures to call commands using touchpad gestures. You can also combine it with ydotool to bind macros and such to your gestures, e.g. 4 fingers swipe down closes the current window, 3 fingers swipe left or right changes workspace, etc

Have you tried using the systemd unit file supplied with ydotool? It's probably installed somewhere on your system. Else you can get it here and just change the install location of ydotoold.

For simulated keyboard there are tools such as dotool or ydotool and KeePass extensions such as KPUInput that work by giving the user access to /dev/uinput. That works, but it's a bit inelegant; I guess in the future a Wayland protocol for simulated keyboard input will emerge, like wlroots already has, also for virtual pointers.

ydotool is the generic equivalent. It works on both X11 and Wayland environments.

Autokey does not work yet, but there is Hawck and Espanso that you could play around with. And there is ydotool if all you need is simulating basic input (as in ydotool mousemove -x -10 -y -10, ydotool type 'Hello world!' and so on).

Does ydotool do what you need? I haven't even tried Wayland in years. I'm sure someday I'll find the need.