Wrong Keyboard Input on Assignment (Wayland)

[Figuera]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

On pressing a keyboard key to assign a mapping using the Advance Option the wrong key is assigned.

When creating a mapping I press "A" and "(" is assigned.

Expected Behavior

I press "A" and "A" is assigned.

Steps To Reproduce

1 - Click on a Random Gamepad key
2 - Select a key to assign
3 - Click on Advanced Button
4 - Click on Extra Assignment
5 - Press Keyboard Key

Environment

- OS: ArchLinux
- Display: Wayland
- Environment: Sway
- AntiMicroX version: 3.2 (AUR antimicrox-git version, also tested on AUR antimicrox)

Anything else?

I... am confused about this one. It is not something that would go by unnoticed so it have to be something particular to my machine. At first I thought it was my keyboard layout which is non-standard, so I changed it to the US layout but problem persisted. I try installing a different version of AntiMicroX but it didn't help.

So maybe it is something particular to Sway/Wayland.

I did searched for a similar issue but couldn't find, if there is please merge us and ignore me.

---

Upvote & Fund

• If you find this issue important, mark it with 👍. It lets us see which fixes and features are demanded by the most users.
• We're using Polar.sh so you can upvote and help fund this issue. It may incentivize some developers to contribute to this project and fix some bugs.
• Funded developer receives the funding once the issue is completed & confirmed by you.
• Thank you in advance for helping prioritize & fund our backlog.

[pktiuk]

Could you upload your .amgp profile file containing this assignment?
This is a very strange bug and this is probably somehow linked with your config.

[Figuera]

I haven't done much yet but here is my config:

https://pastebin.com/raw/3vGdCcz0

and one of the control mappings:

https://pastebin.com/raw/fPY8v12B

[mrhappy200]

I have the same problem, with me it always seems to register 8 values further, so if I press 1 it registers 9 and if I press Q it registers O. in the key checker the qt value is correct but the antimicroX value is 8 further.
EDIT: I am running manjaro sway

[pktiuk]

@mrhappy200
Could you show screenshot from key checker?

[mrhappy200]

Here it is
EDIT: I am pressing Q

This is me pressing 1

[pktiuk]

This seems to be sway-only issue.
Tested with ubuntu X11+uinput and ubuntu wayland +uinput and it worked properly.

[mrhappy200]

@pktiuk Anything I could do to help?

[pktiuk]

I don't think so (unless you are C++ developer).
Due to lack of time and comparably low number of affected users, this issue will have to wait until I will finish ironing out other problems with Windows build

[mrhappy200]

@pktiuk I might have an idea, what if you just put the gui key picker into the advanced settings. This would solve most problems and I would imagine (I wouldn't know not a c++ dev) that is is mostly just copy paste.

[tutacat]

This behaviour appears when running on Wayland, because it has different key codes to X11.

It is also an issue on GNOME.

@pktiuk This should not be labeled low-priority now, because wayland backend is enabled by default, but AntiMicroX doesn't properly support wayland.

uinput lib only handles event generating. Capturing the keypress is handled by the QT backend.

[tutacat]

A temporary workaround is to set QT_QPA_PLATFORM=xcb environment variable, to use QT xcb platform.

[tutacat]

Correct input (key 1 = "1")

Erroneous input (key 1 = "9")

This is because antimicroX is reading the X11 key code, instead of the Qt one

[pktiuk]

You are right, this issue occurs on all of the wayland compositors.

Unluckily I have no idea, what is going on in the part of the code dedicated to these key codes. TBH I don't know why do we have these three types of key values (lack of code docs does not help), so fixing this issue may be problematic for me :/

[rporter220]

I am also seeing this in Wayland when trying to assign the numpad keys. Instead of the Numpad keys being assigned it seems I'm getting F keys (Numpad 1 = F11) or functions (insert/delete/etc) but not the non-numlocked variety, but the 6 dedicated keys.

This seems to be my last hurdle with trying to use Wayland over X11.

[tutacat]

You are right, this issue occurs on all of the wayland compositors.

Unluckily I have no idea, what is going on in the part of the code dedicated to these key codes. TBH I don't know why do we have these three types of key values (lack of code docs does not help), so fixing this issue may be problematic for me :/

The AntiMicroX code is probably for cross-platform functionality, so each key has a common code. But the code is converting from the native keycode instead of the abstracted Qt keycode.

[pktiuk]

You are right, this issue occurs on all of the wayland compositors.
Unluckily I have no idea, what is going on in the part of the code dedicated to these key codes. TBH I don't know why do we have these three types of key values (lack of code docs does not help), so fixing this issue may be problematic for me :/

The AntiMicroX code is probably for cross-platform functionality, so each key has a common code. But the code is converting from the native keycode instead of the abstracted Qt keycode.

Feel free to investigate the code and fix this issue. PR-s are welcome :)

[pktiuk]

Hello guys,

I had some time to look t this problem once again, and I think I found a fix

@Figuera @mrhappy200 @rporter220 @tutacat

Test build is available here: https://github.com/pktiuk/antimicrox/releases/tag/fix_wayland_keyboard_assignment

Could you test is and tell me whether it fixes this issue (without creating any new bugs)?

[gllt]

So far the appimage works great for me. I've only tested it for about 30 minutes, using an xinput gamepad to press CTRL+Z for undo in Krita, but it's working. I was using the current antimicrox build found in the arch linux repo and running it on plasma + wayland when I ran into the issue described above. I'll test this build some more tonight and if anything comes up I'll let you know. Thank you for the test build!

[oe4dns]

I have just build version 3.5.0. on a Raspberry Pi 4 (Raspberry Pi OS "bookworm") and also have experienced this issue. When registering keypresses, the codes are shifted by a value of 9.

Picking the correct values from the virtual keyboard leads to a working configuration though. This means I cannot press the wanted buttons to select a value but have to choose them visually. So maybe this is half solved?

[pktiuk]

@oe4dns
Could you write your instruction for reproduction in steps?

Does it also happen in x86 environments?

[oe4dns]

Steps for Reproduction:

• Compile, install and run antimicrox (in my case on Raspberry Pi OS Debian "bookworm")
• push a button on the gamepad to see which one registers in the antimicrox window.
• click on the button*s representation in antimicrox window to connect it to a keystroke
• Window with on-screen keyboard is now visible. While cklicking on a button of the on-screen keyboard assigns the correct value, pushing the button on the device's real hardware keyboard has the aforementioned offset of 9.

I have tested this on a x86 system and everything works as expected, no issues. BUT I do not yet run Wayland on any of my x86 boxes, everything ist still X11. So this is more likely a Wayland issue and not connected to the hardware architecture.