Paste to active window support

Since version v0.20.3, vicinae supports universal "paste to active window" by relying on the uinput linux kernel module. This is how the well known ydotool utility works. On some systems, this works out of the box. On others, it requires a few tweaks. This page explains everything about it.

Setup

udev setup

From the root of the vicinae repository, copy the udev rules to the appropriate system location:

cp extra/udev/rules.d/* /usr/lib/udev/rules.d/

You may also want to copy the files inside modules-load.d to make sure the uinput kernel module is getting automatically loaded on boot:

cp extra/modules-load.d/* /usr/lib/modules-load.d/

Reload udev rules

If you installed the udev rules manually or just got done installing vicinae, you will most likely need to reload the udev rules:

sudo udevadm control --reload-rules
sudo udevadm trigger

# optional: load `uinput` module manually. Might be required if you just got done installing
sudo modprobe uinput

Add your user to the input group

The installed udev rule states that access to uinput is restricted to members of the input group.

This is a standard group name on most linux distributions, but you may not be part of it. Check with the groups commands. If you are not in this group already, run:

sudo usermod -aG input $(whoami)

# start a new shell with new group, or restart your user session (logout/login again)
newgrp input

Known caveats

Environments without full window management support (KDE Plasma or Gnome without the extension) will not be able to know whether the active window is a terminal emulator window or not, and as such vicinae will not be able to dispatch the correct paste sequence (ctrl+shift+v) to them. Paste will work in every application accepting ctrl+v though.

Why is pasted content copied in my clipboard?

vicinae uses the clipboard as a data transfer mechanism to paste the content, because "typing" the content is very quirky and limited to ASCII text. It also avoids confusing the target app with raw input sequences that it may not expect.

Why not use wtype?

wtype uses the virtual keyboard wayland protocol which presents some caveats:

  • wayland only, X11 support requires special handling
  • may work slightly differently from a compositor to another
  • not implemented by many compositors and big desktop environments such as KDE Plasma and Gnome

On the other hand, the uinput virtual keyboard method works everywhere in a predictable way.

Was this page helpful?