[tijszwinkels]

Addresses #71 for literal-only invocations.

wtype assigns each distinct character the next sequential keycode, starting at evdev 1 / XKB 9. This can put printable characters on physical control-key positions. Chromium can then interpret a character as an editing command despite its assigned keysym.

This PR was created with help from the Pi coding agent and the Astra model. I have reviewed the changes and tested them extensively.

Problem

For example, on Arch with Hyprland 0.56.2, wtype 0.4-2 and Chromium 153.0.8010.36 on Wayland:

wtype -d 1 -- "let's just keep it open."
# Before: let's just keep it ope
# After:  let's just keep it open.

The period is the 14th distinct character, so stock wtype assigns it evdev 14 / XKB 22: physical Backspace. Chromium reports key=".", code="Backspace", keyCode=8, followed by deleteContentBackward.

Solution

This patch assigns literal text only to the 48 physical keycodes in the printable section of a PC keyboard, avoiding Escape, Backspace, Tab, Enter and modifier positions. The character assignments remain generated from the input, so text is not restricted to a particular keyboard layout.

For inputs with more than 48 distinct characters, the patch divides the character list into groups and uploads the required group's keymap before typing. The same physical codes are reused for each group. Switching happens only between complete press/release pairs, and returning to an earlier group reloads its map. Characters within the active group require no switch.

Limitations

• Any invocation containing -k, -P, -p, -M or -m retains the original upstream path, preserving explicit key and modifier behavior. This also means literal text mixed with those options remains unfixed. Literal argv and stdin input, delays and sleeps remain supported.

• Frequently alternating between groups adds keymap-upload overhead.

• The separately observed Chromium corruption of non-BMP characters such as emoji remains unfixed.

[alexcampbelling]

Heya @tijszwinkels,

I just found this PR as it fixes my current, and same, issue. However this project looks to be unmaintained.

I have shifted my scripts from wtype to ydotool.

Having also using the same display server protocol and OS, I recommend it highly :)

[fedesapuppo]

Another case this fixes: a single space typed into the Chromium omnibox.

Flux (bjarneo/flux) types phone keyboard input with one wtype - per keystroke, so every character is the first in its keymap and lands on evdev 1 (Escape). The omnibox drops a space on that code. Letters survive.

Repro on Hyprland, wtype 0.4-2, Chrome stable, clean profile, omnibox focused:

for c in h o l a ' ' c o m o; do printf '%s' "$c" | wtype -; done
# omnibox shows: holacomo

A text field in a web page receives key=" " code="Escape" and keeps the space. Only the omnibox drops it.

With this PR built (99e8e15), the same loop types hola como in the omnibox.

[sawy3r]

Confirming the same bug on COSMIC: Pop!_OS 24.04, cosmic-comp 0.1~1791227611, wtype 0.4-3, Google Chrome 154.0.8037.92 (Flatpak).

Dictated text piped through wtype - lost every full stop along with the letter before it ("It mostly looks right." came out as "It mostly looks righ"). In that transcript the period is the 14th distinct character, so it landed on evdev 14 (Backspace), matching the analysis here. It happened in Chrome text fields and in a terminal as well, so it is not limited to Chromium and Electron.

We fixed it in our own tool by taking the same approach as this PR: literal characters only go on the printable key positions, space, Return and Tab go on their real keys, and the keymap switches once there are more than 48 distinct characters. +1 for getting this merged.

[tijszwinkels]

@atx By now, quite a few people have looked at this and are waiting for this. I understand this is not your focus, but could you merge?

[atx]

Right, LGTM! My worry here was that it used to be that some clients really hated the keymap getting switched from under them repeatedly. But doing some casual testing this is probably no longer the case as of 2026

[sawy3r]

Thanks @atx for merging, and @tijszwinkels for the fix!

[tijszwinkels]

Super @atx ! Thanks for merging this!