Wrong Keyboard Input on Assignment (Wayland)

Figuera commented 2 years ago

Is there an existing issue for this?

[X] 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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@mrhappy200
Could you show screenshot from key checker?

mrhappy200 commented 2 years ago

Here it is EDIT: I am pressing Q

This is me pressing 1

pktiuk commented 2 years ago

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

mrhappy200 commented 2 years ago

@pktiuk Anything I could do to help?

pktiuk commented 2 years ago

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 commented 2 years ago

@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 commented 1 year ago

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 commented 1 year ago

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

tutacat commented 1 year ago

Correct input (key 1 = "1") antimicrox_xcb_key_1 Erroneous input (key 1 = "9") antimicrox_wayland_key_1

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

pktiuk commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 :)

AntiMicroX / antimicrox