Some special characters not writing properly

[pinarruiz]

Hi!
Some of the characters are not written properly on the "View/Type individual entry".

For example a password that is like:

u46jxA#

Will be written like:

u46jxA·

It also happens with @ being written like Q i guess this is an issue with my setup, but cannot point exactly where.

Keepmenu version: 1.4.0
Rofi version: 1.7.5
Command used: keepmenu -d ~/locvault.kbdx

Let me know if i need to attach any more info.
Thanks

[firecat53]

I suspect either a locale issue or an issue with the type_library you are using. I'd suggest using xdotool if you're not already (assuming X and not Wayland). Check the docs for more information.

[pinarruiz]

I am already using xdotool, version 3.20160805.1

Edit: Just updated to 3.20211022.1 built from source, still does not work properly

[firecat53]

Did you to set your keyboard map locale someplace as per the docs (configure.md)? What window manager are you using?

Try using xdotool and Rofi (separately) from the command line and see they type the correct characters. Keepmenu doesn't really do anything with the text other than pass it to the type_library program that's configured.

[pinarruiz]

Did you to set your keyboard map locale someplace as per the docs (configure.md)?

$ setxkbmap -query
rules:      evdev
model:      pc105
layout:     es

What window manager are you using?

I am using qtile version 0.23.0

Try using xdotool and Rofi (separately) from the command line and see they type the correct characters. Keepmenu doesn't really do anything with the text other than pass it to the type_library program that's configured.

$ xdotool type [email protected]
[email protected]

$ xdotool type 1234@#
1234@#

[firecat53]

How are you launching keepmenu?

Is it perhaps being started before the keyboard gets set during window manager startup?

If you run keepmenu from the command line does it work properly?

[pinarruiz]

How are you launching keepmenu?

Keepmenu is launched by qtile on a keypress:

Key([mod, "shift"], "k", lazy.spawn("keepmenu -d ~/locvault.kbdx"), desc="KeepMenu")

If you run keepmenu from the command line does it work properly?

Launching it from the command line has the same effect.

[tbscode]

Experiencing a similar issue, when using keepmenu either from command-line or directly launched from terminal.

For me it converts | to >.

But when I do xdotool type "|>" I correctly get |>.
This is my ~/.config/keepmenu/config.ini:

[dmenu]
dmenu_command = rofi -show drun -dpi 1

[dmenu_passphrase]
nf = #222222
nb = #222222
rofi_obscure = True

[database]
database_1 = XXXXXXXXXXXX
keyfile_1 = 
pw_cache_period_min = 360
autotype_default = {USERNAME}{TAB}{PASSWORD}{ENTER}
type_library = xdotool

I'm launching keep menu by setting up a gnome keyboard shortcut to start /home/$USER/.keepmenu/venv/bin/keepmenu ( but as said I see the same issue running keepmenu directly ).

setxkbmap -query gives me:

rules:      evdev
model:      pc105
layout:     us,us
variant:    ,

I'm using Ubuntu 23.10 with regolith desktop ( i3wm + Sway ).

The same setup but using direct python install rather than virtual environment was working completely fine in my old setup under Ubuntu 22.10 also with regolith dektop.

[vaygr]

Apparently this is a duplicate of #140.

Recently dotool support was added -- I tested it and it worked as expected. But with pynput I get 1-to-1 conversion of | to >. Seems others get the same behavior with xdotool. But when using them outside of keepmenu, this doesn't happen.

[tbscode]

@vaygr thanks for commenting this.
I've tested again and It seems like I screwed up reloading my session / correctly switching to xdotool, after system restart ( or whatever ), It now seems to be correctly working.

So therefore I assume that I was also experiencing the issue pyinput.
Now with xdotool correctly activated the string ||||???>>><<<#%!@*!&@(!&9732!!! is correctly typed out!

So from my side this is resolved :D

[pinarruiz]

Hey @tbscode,
I just tried xdotool, and still no luck, what version are you using?

[tbscode]

$ xdotool --version
xdotool version 3.20160805.1

[firecat53]

But with pynput I get 1-to-1 conversion of | to >

I can replicate this and I believe it's a bug in pynput.

I have tried many combinations of xdotool, ydotool, dotool, and wtype and I cannot replicate any of the incorrect character outputs. I'm sorry people, but unless someone can troubleshoot on a non-US keyboard and provide some kind of obvious cause and patch I'm not sure I'm going to be able to fix this.

I'd suggest trying the other 'typing' tools (ydotook, dotool, etc) and see if one works for you. Unfortunately, each one has issues that you might either have to live with or work around.

• Wtype - misses some characters, not developed or updated for a couple of years, does type unicode fairly well.
• Ydotool - this one has worked best for me. Works in X and Wayland. Doesn't do much unicode. Requires daemon and a udev rule added.
• Xdotool - only X11. Types unicode
• Dotool - haven't used this one.

[vaygr]

@firecat53 I'm confused by the non-US keyboard statement in your comments. I have a US keyboard and using pynput get unexpected behavior. So I'm not sure if non-US keyboards have something to do with the problem.

So far we have only the original reporter that can reproduce the issue with xdotool. For the rest, as was supported in #140, it's considered to be a pynput bug.

As I'm very interested in leaving pynput support in keepmenu, I'll probably find some time in the coming weeks to debug this or prove the theory wrong.

It appears @pinarruiz could be having a separate problem, as switching to xdotool doesn't fix it.

[vaygr]

OK, I opened moses-palmer/pynput#593 with upstream and tracked it down to the code in xorg.py#L297

It's interesting, but with the same version of pynput I couldn't reproduce it on my older laptop with the same keyboard setup, however with the entire X stack from a few years ago. My thinking is that keysym normalization code in pynput could be responsible for this, as it worked fine with old keymap files provided by Xorg.

I also found a few ancient issues in pynput about unexpected character typing behavior, all unfortunately stalled. So I don't have hopes it'll get addressed anytime soon.

As far as alternatives go, there's https://github.com/gemdude46/autotype that even supports Unicode, but unfortunately doesn't support all functional keys to be considered a good replacement for pynput.

@pinarruiz I recommend trying out dotool and see if it solves the problem, but it would be interesting to know why xdotool doesn't.

[firecat53]

Thanks for submitting that bug and doing the in-depth troubleshooting! It's really frustrating not having a solid tool that works across X11/Wayland and all keyboard layouts/unicode characters.

Because of these issues, I'm considering adding a note to the README for people to use the password_chars and password_char_presets config settings to set the special characters that actually work on their system.

I'm not convinced that keepmenu (or bitwarden-menu) are responsible for any of these issues, but I'm open to being wrong!

[pinarruiz]

I was switching to hyprland from Qtile (X11) and was looking for an alternative, based on the following I am going to asssume my previous configuration was wrong.

I am now using ydotool, and from their README.md#hyprland noticed i needed some special configuration for setting the tools layout.

So as i had no special configuration for the tool i was using with Qtile, cannot remember which sorry, I am going to assume it was something like this?

I remember configuring Qtile with Spanish layout on mind, as I am doing with Hyprland, but noticed the same error, and this time there was a hyprland example so that caught my attention.

I don't know if this issue should be closed or not as i see some people with some issues, but I'll let @firecat53 decide, for me the issue is solved.

I also don't know if this is what happend on Qtile, but so far I am going to assume it is, unless someone changes my mind.

Thanks for all the help and feedback.