enigo-rs
Reason about `Wayland` integration
- what do i need from Wayland side
- is this even possible with the Wayland security measures?
Of course it's possible, you'd need a protocol that allows access to global input. But no compositor authors ever decided to implement that.
You can do things on evdev level like I did: https://github.com/myfreeweb/evscript — and it'll work in both X and Wayland.
@myfreeweb isn't evdev for reading events - creating events requires uinput? I saw that you added uinput into your evdev repo https://github.com/myfreeweb/evdev/blob/uinput/examples/uinput.rs .
@myfreeweb thanks for the suggestion, i was thinking about that but i havn't digged into evdev + uinput yet. The problem i currently see with uinput is that we don't know which keyboard layout the user currently has and even if we do know we have to handle every special layout in code ... am i on the right track here? The current implementation can input various characters like "äöü ❤️🍉" even if there is no corresponding button on the current keyboard.
Yeah, this is raw keycodes, absolutely terrible for entering text. My use case was all about modifier keys and special characters :) but if you want to enter text, there's no good way to do it with uinput.
I actually wrote a draft of a protocol for global input access. Sway developers didn't like it. I would imagine GNOME and KDE developers also might not like it :D Or maybe they do understand that people need UI automation?…
I've done a little bit of playing around with evdev-rs and can definitely get simple input working under Wayland. @myfreeweb is definitely right that entering text with this would be nasty, but it would work. I could put together the world's grossest library to translate strings to keycodes, but handling Unicode won't be easy. It can certainly be done with some keyboard shortcuts, but that appears to be dependent on the desktop environment. I'd imagine we could hack that together with some explicit environment checks, but that's less than elegant.
Anyhow, I'd love to help out here. It looks like all of the X dependent stuff can be replaced with evdev. I'm just not sure if messy support is better than no support for Wayland? Let me know if you are interested in doing some more on this front.
@TheLostLambda I am very interested in this – even outside the scope of this project anyway. I havn't really found time to invest in this subject yet. Is there any code snipped of the things you tried yet? I have almost no clue about evdev anymore after my first experiments couple years ago. Under X you could make some weird hacks i don't know if one can make something similar with evdev
Haha, the little thing I was playing with this morning is crazy simple and really messy (I haven't taken away any of the boilerplate yet) but here it is. Since I'm in Gnome, I have it set up to run the keyboard shortcut to switch down a workspace and then open a calculator (turns out there is a dedicated key for that).
You need to run the code as root and give it a path to your current keyboard. It should be /dev/input/eventX where is X is some number. I used sudo evemu-record to find which device my keyboard was. You can also make a device from scratch instead of duplicating one, so the final version wouldn't need any path like this.
Use this https://github.com/grelltrier/zwp-virtual-keyboard or https://github.com/grelltrier/input_method_service
I've been playing around with zwp-virtual-keyboard and it should work well for the compositors that support it.
Here's another example that uses the zwp-virtual-keyboard to get UTF-8 symbols (it's a constrained use-case but seems to work better than X11) https://github.com/hid-io/hid-io-core/commit/f897ff2a8484a358308fcdc83f6585642e633b67