ydotool alternative

[nateskulic]

Hi!

Small suggestion to create a simple uinput virtual keyboard instead of depending on ydotool. See: https://www.kernel.org/doc/html/v4.12/input/uinput.html

ydotool is planning to add a new runtime and rewrite in 2024 ^1... Not so sure about it as a dependency.

I think speech is worth an entirely different "input device" 🙂

[mkiol]

Thanks for the suggestion. I didn't know about that. I must admit that at first glance it looks quite complicated.

Do you know if the program accessing the uinput API must be run with special privileges? This is the reason why ydotool is very convenient. The user runs ydotool with all elevated privileges, and the regular app (e.g. Flatpak app in the sandbox) can simply talk to ydo socket without having to give it additional privileges.

[nateskulic]

Thanks for the suggestion. I didn't know about that. I must admit that at first glance it looks quite complicated.

I haven't tried it yet. The hardest part seems to be devising a protocol/server/port for which to receive and process events. I presume Qt/D-Bus console application would be suitable.

Do you know if the program accessing the uinput API must be run with special privileges? This is the reason why ydotool is very convenient. The user runs ydotool with all elevated privileges, and the regular app (e.g. Flatpak app in the sandbox) can simply talk to ydo socket without having to give it additional privileges.

Typically, yes. /dev/uinput is owned/writable/readable by root only.

However, one may do so without special privileges. Something like this in a file in /etc/udev/rules.d/:

KERNEL=="uinput", MODE="0660", GROUP="users", OPTIONS+="static_node=uinput"

(Giving permissions to the group users to the uinput device)

[nateskulic]

Not sure how the latency is on D-Bus compared to a typical input device, but it may or may not be an issue... If it is, you may need a faster protocol (e.g. plain old HTTP, of which a simple local server would probably suffice for such an application).

While this may expand the scope of the dsnote a bit, I think tight integration with uinput may open a path for speech to text, and voice commands or a voice user interface... e.g. command palettes, templates/shortenings/expansions, etc. This may avoid any redundant application/models/data/devices providing such functions.

[kolya-ay]

Just for the reference. Here is another Go-based tool which talks directly to /dev/uinput

[lmtr0]

Mentioning #327 as it seems related to this.

I'm exploring the implementation of this.