Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Key won't release #59

Closed
sezanzeb opened this issue Mar 15, 2021 · 9 comments
Closed

Key won't release #59

sezanzeb opened this issue Mar 15, 2021 · 9 comments

Comments

@sezanzeb
Copy link
Owner

sezanzeb commented Mar 15, 2021

openrazer/openrazer#1039 (comment)

@Amdarin I'm moving that discussion to this place

I was trying much more and I know what was happening. For ejemple the device have by default a pre-assigned keys, i just give you an example. 1 Key and 2 key have "1" and "2" preassigned so if you assign the same key by error or the first time you use the software and you don't know that it could happend then if you pressing the key 1 or 2 you will get a "1" or "2" repeting without stop. "1111111111111111111".... It's not an exactly a error but perhaps could show any message warning at the same moment of the setting up the keyboard. I was testing it with World of Warcraft and I can tell you the feeling and respond of the keyboard was pretty good. Also it could be good if we have profiles but I think it could be far of the focus project. I would like comment too that I have a razer basilisk V2 and one key of it is not reconize but I going to post it on the web project. Thank you for you support and effort..

@sezanzeb
Copy link
Owner Author

sezanzeb commented Mar 15, 2021

I don't get what you think the problem is. But a key not releasing is certainly a bug.

Please run:

sudo systemctl stop key-mapper
sudo key-mapper-gtk -d

and then reproduce your problem (such that it writes 1111... again). Afterwards share the output in the console as an answer here.


1 Key and 2 key have "1" and "2" preassigned

That is expected. If it wouldn't do that key-mapper wouldn't work at all, because devices that don't have keys assigned to their buttons won't report events over usb. My razer naga trinity also does that and it works perfectly fine.

@Amdarin
Copy link

Amdarin commented Mar 15, 2021

As you can see I have assigned the Key_1, then I save the profile and apply it. I typed key 1 and I get the result as you can see in the screenshot at right. I have to make a ctrl+c to break the repeating.

Captura de pantalla de 2021-03-15 14-08-57

@sezanzeb
Copy link
Owner Author

Thanks! I'll look into it soon

@JonasLoos
Copy link

JonasLoos commented Mar 16, 2021

I seem to have the same problem. When pressing RIGHTALT+LEFTBRACE [ gets spammed until another input key (e.g. space) is pressed. This only happens the first time, afterwards the combination is disabled and nothing happens when pressing it. Pressing ctrl during the spamming of [ causes it to hold until I release ctrl. Similarly, pressing shift during the spamming switches the spammed character to { until I release shift.

Log: https://gist.github.com/JonasLoos/6722b39fd9e8f8d58cf886f965b91033

image

Edit: Note that this is 0.7 instead of the latest commit in main.

sezanzeb pushed a commit that referenced this issue Mar 16, 2021
@sezanzeb
Copy link
Owner Author

thanks for your help. Pushed a fix to main

reopen if it still doesn't work

@JonasLoos
Copy link

This seems to be only partly fixed. Nothing is spammed anymore, but another bug, which might have caused this, is still there. It causes wrong keys to be triggered in special cases.

What I did to trigger it:

Add two input sources in gnome-control-center (en and ger). Add a mapping in key-mapper for e.g. 1-> udiaeresis (=ü). Having the German layout selected it works fine, but using the English layout [ is triggered. It doesn't seem to matter which input source is active during setup of the mapping.

My uninformed guess:

Key-mapper reads the available mappings from all input sources and then maps the selected mapping to the corresponding key-code. If now another input source is active, the keycode doesn't correspond to the mapped meaning anymore.


Log: https://gist.github.com/JonasLoos/0bb78d0c4331b90f127201e3409ade06

@sezanzeb
Copy link
Owner Author

sezanzeb commented Mar 18, 2021

The keyboard layout is display server related, but key-mapper doesn't interact with it, it just maps keycodes. Hence it works for both x and wayland or any future display server. It doesn't know which characters will be written into the desktop environment, besides what xmodmap -pke prints. Which works if people only need keys from their default system keyboard layout.

xmodmap -pke doesn't take a device or layout argument unfortunately, so I can't figure out the correct keycode in that case. That command is what populates the dropdown list.

I could use setxkbmap to change the layout of the mapped device, but I still need the correct keycode during the mapping which doesn't seem to be possible.

@sezanzeb
Copy link
Owner Author

sezanzeb commented Mar 18, 2021

An alternative is work in progress: https://github.com/sezanzeb/key-mapper/tree/xkb

it optionally writes custom xkb configs for the injected device, so it can write any arbitrary character. But it's not finished yet and buggy, and there are no unit tests yet. I'm a bit busy with other features, but I guess I'll be able to continue working on that branch soon.

@JonasLoos
Copy link

This alternative seems like the way to go.

Switching the layout on the fly with setxkbmap sounds quite slow. But the correct keycode and layout could maybe be extracted from xmodmap -pke. The keycode should be the one at the beginning of the line and the layout should be determinable by the position of the symbol.

Example output for xmodmap -pke | grep "keycode 34":

# only en layout
keycode  34 = bracketleft braceleft bracketleft braceleft
# en + ger layouts
keycode  34 = bracketleft braceleft udiaeresis Udiaeresis dead_diaeresis dead_abovering bracketleft braceleft
# ger + en layouts (layout order switched)
keycode  34 = udiaeresis Udiaeresis bracketleft braceleft dead_diaeresis dead_abovering bracketleft braceleft
# en + ger + fr layouts
keycode  34 = bracketleft braceleft udiaeresis Udiaeresis dead_diaeresis dead_abovering dead_circumflex dead_diaeresis dead_tilde dead_abovering bracketleft braceleft

There seem to be 4 entries per layout, but the ordering is a bit mixed up.

sezanzeb pushed a commit that referenced this issue Oct 2, 2021
sezanzeb pushed a commit that referenced this issue Oct 2, 2021
sezanzeb pushed a commit that referenced this issue Oct 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants