Linux/Hyprland: Space is lost after automatic correction and must be pressed three times

[Vadyanik]

PolterType version

0.36.3

OS and desktop environment

NixOS 26.11, Hyprland 0.55.3, Wayland, Linux 6.18.35

How did you install it?

AppImage (Linux)

Keyboard layouts involved

en-US + uk-UA + ru-RU (the issue was observed while correcting between en-US and ru-RU)

Anything unusual in your input stack?

input-remapper 2.2.0 is running. Its active keyboard preset only remaps evdev code 96 (KP_Enter) and does not remap the physical Space key (evdev code 57).

What happened, and what did you expect?

After an automatic wrong-layout correction, Space can enter a state where it must be pressed three times before a visible separator appears.

Reproduction with a physical keyboard:

1. Enable automatic conversion.
2. Set [engine].replay_speed = "normal".
3. Type a word in the wrong layout.
4. Press Space once.
5. PolterType switches the layout and rewrites the word, but no trailing space appears.
6. Press Space a second time. Nothing visible happens.
7. Press Space a third time. The space finally appears and the next word can be typed normally.

Expected: the first Space press should both trigger the correction and leave exactly one space after the corrected word.

The problem was also observed while typing continuously: two adjacent corrected words could be joined, for example the separator and sometimes the first letter of the following word were lost.

Things already checked:

• Changing from instant to the documented safe normal speed did not fix it.
• fast changes the latency but is not a reliable fix.
• In a controlled synthetic-input check, setting POLTERTYPE_HOLD_KEYS=0 did not prevent the words from joining. This synthetic check uses another virtual input device, so the physical-keyboard reproduction above is the authoritative one.
• The normal Linux key gate is available and reports holds_keys=true.
• The issue occurs in ordinary text fields. Ghostty is separately excluded and is not the source of this report.

The Wayland uinput emitter already sends release → press → release around the final boundary key, with last_hold = 20 ms and boundary_guard = 12 ms. As an experiment I built a local 0.36.3 binary with both values increased to 30 ms. That experiment is not yet evidence of a universal fix, but the three-press symptom looks consistent with the physical boundary key still being considered logically down when the synthetic boundary press is replayed.

Log excerpt

DEBUG applying correction from=en-US to=ru-RU original=<6 chars> corrected=<7 chars>
DEBUG key gate: holding devices=2
DEBUG uinput backspaces starting count=7
DEBUG uinput replay starting count=7
DEBUG uinput key scancode=57 shift=false
DEBUG typing out keystrokes the gate held back count=2
DEBUG typing out keystrokes the gate held back count=1
DEBUG typing out keystrokes the gate held back count=1
DEBUG typing out keystrokes the gate held back count=1
DEBUG key gate: released
DEBUG typing out the last held keystrokes count=1
DEBUG uinput key scancode=57 shift=false
DEBUG correction timing gear="normal" switch_ms=Some(0) absorb_ms=Some(60) verify_ms=Some(0) emit_ms=Some(556) total_ms=616
DEBUG applying correction from=ru-RU to=en-US original=<5 chars> corrected=<6 chars>
DEBUG key gate: holding devices=2
DEBUG uinput backspaces starting count=6
DEBUG uinput replay starting count=6
DEBUG uinput key scancode=57 shift=false
DEBUG key gate: released
DEBUG correction timing gear="normal" switch_ms=Some(1) absorb_ms=Some(60) verify_ms=Some(0) emit_ms=Some(262) total_ms=324

Relevant config.toml excerpt

[general]
paused = false

[engine]
hold_keys = false
replay_speed = "normal"

[exceptions]
disabled_apps = [".ghostty-wrapped"]

hold_keys = false is present in the config, but on Linux 0.36.3 the gate still starts by default; the startup log confirms holds_keys=true.