Why is pynput typing incorrect output, but only on Linux? (lemmy.world)

submitted 1 week ago* (last edited 1 week ago) by zkfcfbzr@lemmy.world to c/python@programming.dev

14 comments fedilink hide all child comments

I have a rather large Python script that I use as basically a replacement for autohotkey. It uses pynput for keyboard and mouse control - and at least on Windows, it works exactly how I expect.

I recently started dual-booting with Linux and have been trying to get the script to work here as well. It does work but with mixed results - in particular, I found that pynput has bizarrely wrong output for special characters, in a way that's both consistent and inconsistent.

The simplest possible case I found that reproduces the error is this script:

import time
from pynput import keyboard

# Sleep statement is just to give time to move the mouse cursor to a text input field
time.sleep(2)

my_kb = keyboard.Controller()

text = '🍆' # Eggplant emoji
my_kb.type(text)

time.sleep(1)

text = '𝕥𝕖𝕤𝕥' # blackboard bold test
my_kb.type(text)

time.sleep(1)

text = '𝐭𝐞𝐬𝐭' # bold test
my_kb.type(text)

When I run that script right now, it produces the output "🍆𝕥𝕥𝕤𝕥𝐭𝐭𝐬𝐭". And if I run it again, it'll produce the same output. And if I change the eggplant emoji to something else, like the regular character 'A', it will still produce the same output (specifically "A𝕥𝕥𝕤𝕥𝐭𝐭𝐬𝐭"). But... If I log out and log back in, then the output changes to something else that's still wrong, but differently. For example, when I changed the eggplant to a regular 'A', then relogged, the output became "A𝕥𝕖𝕖𝕥𝐭𝐞𝐞𝐭". And then that wrong output will keep being the same wrong output until I log out and back in again. If the test strings don't change, then the incorrect outputs don't change on relog - but if they do, then they do.

In the larger script, errors seemed to chain together somehow - like if I produced an eggplant emoji, then tried to write blackboard bold test, I would get "🍆𝕖𝕤🍆". This is despite verifying just before running the pynput.keyboard.Controller.type function that what it was about to type was correct. The issue also happens if I type it character-by-character with press and release functions.

I am very new to Linux. I'm on Linux Mint. I'm running this in a python3 venv that just has pynput and two other external libraries installed. ChatGPT thinks the issue might be related to X11. The issue does not occur at all on Windows, using the exact same code. On Linux there seems to be no issues with typing regular text, just special characters.

you are viewing a single comment's thread
view the rest of the comments

[-] zkfcfbzr@lemmy.world 1 points 1 day ago* (last edited 1 day ago)

Do you follow the reasoning for why they set it up this way? The comments in this function from _xorg in keyboard make it seem like it expects K1 K2 K3 K4.

#: Finds a keycode and index by looking at already used keycodes
        def reuse():
            for _, (keycode, _, _) in self._borrows.items():
                keycodes = mapping[kc2i(keycode)]

                # Only the first four items are addressable by X
                for index in range(4):
                    if not keycodes[index]:
                        return keycode, index

I assume that second comment is the reason the person who wrote your function likes the number 4.

Which way is right/wrong here? It would seem at least part of the issue to me is that they don't make the list be K1 K2 K1 K2 as they say, since the function I quoted above often receives a list formatted like K1 K2 K1 NoSymbol.

Also, if I modify the function you quoted from to remove the duplications, I'm still finding that the first element is always duplicated to the third element anyways - it must be happening elsewhere as well. Actually, even if I modify the entire function to just be something nonsensical and predictable like this:

def keysym_normalize(keysym):
    # Remove trailing NoSymbol
    stripped = list(reversed(list(
        itertools.dropwhile(
            lambda n: n == Xlib.XK.NoSymbol,
            reversed(keysym)))))
    if not stripped:
        return
    else:
        return (keysym_group(stripped[0], stripped[0]), keysym_group(stripped[0], stripped[0]))

then the behavior of the output doesn't change at all from how it behaves when this function is how it normally is... It still messes up every third special character, duplicating the previously encountered special character

Later edit: After further investigation, the duplication of the first entry to the third entry seems to happen in the Xlib library, installed with pynput, in the display.py file, in the change_keyboard_mapping function, which only has a single line. Inspecting the output of the get_keyboard_mapping() function both before and after the change_keyboard_mapping function does its thing shows that it jumps right from [0, 0, 0, 0, 0, 0, 0, 0, 0, 0] to [keysym, 0, keysym, 0, 0, 0, 0, 0, 0, 0]. It's still unclear to me if this is truly intended or a bug.

[-] logging_strict@programming.dev 2 points 1 day ago

The way forward is to make a unittest module (unfortunately author not using pytest). With characters that are taken as an example from each of the four forms.

THEN go to town testing each of the low level functions.

Suspect the test coverage is awful. mypy and flake8 also awful.

[-] logging_strict@programming.dev 1 points 1 day ago

There are several forms

K1 NoSymbol K2 NoSymbol characters with lower/upper case forms

K1 K2 K1 K2 unicode <= 256 with no lower/upper case forms. Like | or + symbol

K1 K2 K3 NoSymbol 2 bytes latin extended character set

K1 K2 K3 K4 3 bytes like nuke radiation emoji

Non-authoritative guess. Having played around with xev together with onboard virtual keyboard with my symbols layout.

[-] logging_strict@programming.dev 1 points 1 day ago

keysym 0 and 2 are for lower and upper case. If the character has an upper and lower case equivalents.

This is documented in keysym_group when it should be documented in keysym_normalize

In that case, the group should be treated as if the first element were
the lowercase form of ``K`` and the second element were the uppercase
form of ``K``.