[BUG] Ctrl shortcuts broke system-wide until relogin

[hopsayer]

Summary

Once, on 0.15.0 (AppImage) / GNOME Wayland, Ctrl-based keyboard shortcuts
stopped working system-wide (not just in vocalinux's target apps) until I
logged out and back in. Hard to reproduce on demand, so filing this
separately from #657 as a lower-confidence report with a
possible mechanism, not a repeatable bug.

What happened

• Ctrl+A (select all) and Ctrl+V (paste) stopped registering — affected Telegram (Qt), Obsidian (Electron), Nautilus (GTK4).
• Mouse-based equivalents (drag-select, right-click paste) worked fine.
• Plain text typing was unaffected — characters weren't dropped, altered, or
  misinterpreted as shortcuts.
• Quitting/disabling vocalinux did not fix it — only logout/login did.
• After relogin, keyboard layout also seemed to stop influencing injected
  text at all (possibly related, possibly a side effect of the relogin
  resetting something else — unclear).

I don't have a reliable reproduction path for this one.

Possible mechanism (unconfirmed, from reading the code)

I first suspected vocalinux itself was holding an exclusive grab on an input
device, but that doesn't check out: neither evdev_backend.py nor
pynput_backend.py calls .grab()/EVIOCGRAB or pynput's suppress=True —
they only listen, they don't intercept.

A more concrete candidate is _inject_via_clipboard_paste() in
text_injector.py, which simulates Ctrl+V as a single ydotool key call
with a 3-second timeout:

_YDOTOOL_V1_CTRL_V = ["ydotool", "key", "29:1", "47:1", "47:0", "29:0"]
# 29 = LEFTCTRL, 47 = V — press Ctrl, press V, release V, release Ctrl
...
subprocess.run(cmd, check=True, stderr=subprocess.PIPE, text=True, timeout=3)
except (subprocess.CalledProcessError, subprocess.TimeoutExpired) as e:
    logger.warning(f"Paste simulation failed: {e}")

If ydotoold stalls and this hits the 3s timeout, the client process gets
killed mid-sequence. If the daemon had already applied 29:1 (Ctrl-down) to
its virtual uinput device before the client was killed, but never received
29:0 (Ctrl-up), the virtual Ctrl key could stay logically "held" on that
device — separate from the real keyboard. That would explain: real typing
unaffected (different device), mouse actions unaffected (not
modifier-dependent), Ctrl shortcuts broken system-wide (Mutter aggregates
modifier state across all input devices for global shortcuts), and only
logout fixing it (restarts the session's input stack, presumably including
ydotoold's uinput device — quitting vocalinux alone doesn't touch the
separate ydotoold process).

Not confirmed, just flagging a specific, checkable spot rather than "Mutter
broke." If it holds up, an explicit safety-net release (e.g. always send a
bare ydotool key 29:0 after a TimeoutExpired/CalledProcessError here)
would be a cheap mitigation regardless of the exact trigger.

If it happens again, I'll try to look into logs of Voca and gnome-shell.

Environment

• vocalinux 0.15.0, AppImage
• GNOME on Wayland
• Arch latest packages

[jatinkrmalik]

Thanks for writing this up. The timeout-kills-client theory is right.

I tried this against the 0.15.0 AppImage. _inject_via_clipboard_paste runs ydotool key 29:1 47:1 47:0 29:0 with timeout=3. If that hangs, Python SIGKILLs the ydotool client. The except block logs Paste simulation failed and returns False. Nothing sends 29:0.

ydotool 1.x (Arch extra is usually 1.0.4) writes those four events one at a time, 12ms apart, over a SOCK_DGRAM socket with no ACK. ydotoold just recv()s and writes to uinput. It does not track pressed keys and does not release anything when the client dies. Same class of bug as ydotool#170.

If the daemon has already applied 29:1 (Left Ctrl down) and then stalls before 29:0, virtual Ctrl stays held on that uinput device for the rest of the session. That matches what you saw:

• Ctrl+A / Ctrl+V dead in Telegram, Obsidian, and Nautilus, because Mutter ORs modifiers across every device on the seat
• ordinary typing still works, because the physical keyboard has its own per-device XKB state
• mouse select / right-click paste still work
• quitting Vocalinux does nothing (ydotoold is a separate process)
• logout (or killing ydotoold) is what actually clears it

The 3s timeout almost never fires on the happy path (~50ms). You need ydotoold to stop reading after Ctrl-down, which is why this happened once and you could not reproduce it on demand.

One caveat: the #657 logs from the same machine show the xdotool fallback (Checking for better Wayland text injection tools... then Text injected using xdotool). I cannot prove this specific incident went through ydotool. XTEST usually would not break native GTK4 Nautilus, so a stuck uinput Ctrl is still the better fit if Nautilus really lost Ctrl+A. The AppImage does not bundle ydotool; it uses whatever is on the host.

Draft PR with the 29:0 safety net you suggested: #675

[hopsayer]

Yes, I've just checked my pacman log and ydootool was installed just today when I used the install.sh from latest main. But still I'm not sure text insertion is working stably on my system. In that day I just didn't guess ydotool is actually important all the same, even though the app itself in logs says it relies on IBus.

Right while I was testing that build according to your tips, I've catched broken ctrl+C/V/A and alt+shift/win+space in certain apps again. But ydotool is already on my system after install.sh. And I don't understand the exact moment and reason enrirely again. I even suspected usermod -aG input $USER happening during installation. Also I assumed xwayland/qt/qt platform variables (I have QT_QPA_PLATFORM=xcb in /etc/environment).

Anyway, maybe these most recent logs will help to trace this out or narrow it down:

• Full Install Log: https://gist.github.com/hopsayer/b1b3c12edf038734b97fba4bf43370a5
• Full Runtime Log: https://gist.github.com/hopsayer/1772efe8f631e72951564449f1d70634

And interestingly, this is somehow connected to multiple text non-insertion. Both time when this problem reproduced, it happened exactly after continious text insertion failing. First 5-10 insertions failed, though they appeared in logs, being successfully transcribed by the engine. But on ~11 time, the insertion succeeded for some reason. But if it succeeds after a series of fails, it breaks the hot keys. This is the pattern I've observed twice.

Not sure, whether this contains something you don't already know.

As for ydootool issue you mentioned, it's surprising to me that it was created in 2022 and is still open. But your thought is clear: that garbling is a ydotool specific problem, not exactly voca's.