Weird behavior when Ctrl appear in Alt mapping

[vhbui02]

Hi, I'm currently mapping my Alt + IJKL to up, left, down, right. Today when I decide to add another mapping: Ctrl + J = Ctrl + Left, Ctrl + L = Ctrl + Right. Soon, I notice a strange behavior.

When switching from Alt + J to L very quickly (J up and L down, Alt still hold), my cursor suddenly traverse to the end of the word/line. It's like my new mapping has been fired. My assumption was right, turns out this is what happened bts:

Why is there a leftcontrol down and a leftcontrol up? Is this keyd normal behavior?

[nsbgn]

What is your exact config?

In general, the insertion of an extra key is to deal with applications that react to bare modifier taps, and it can be disabled with disable_modifier_guard:

https://github.com/rvaiya/keyd/blob/dcbb68b12f71245121035b730b50872802a259b4/docs/keyd.scdoc#L572

... but it sounds like there is more at play here.

[vhbui02]

What is your exact config?

@nsbgn Here is my /etc/keyd/default.conf:

[ids]

*

[main]

# Default
# Maps capslock to escape when pressed and control when held.
# capslock = overload(control, esc)

rightalt = capslock
capslock = layer(capslock)
leftalt = layer(nav)

[nav:A]
i = up
j = left
k = down
l = right
u = home
o = end

[capslock:C]
j = C-left
l = C-right

# Tapping both shift keys will activate Print
[shift]
leftshift = print
rightshift = print

[nsbgn]

If I understand the log correctly, the sequence <leftalt down> <j down> <l down> ... results in <leftalt down> <leftcontrol down> <leftalt up> <leftcontrol up> <left down> <left up> ... <right down> <right up>? If so, that would be expected behaviour: the <leftalt down> ... <leftalt up> is because the alt modifier gets activated as soon as you enter the layer (and deactivated before emitting a bound key in the layer), and the interleaved <leftcontrol down> ... <leftcontrol up> is the aforementioned modifier guard.

However, you also mentioned that it looks like something is inserted that causes your cursor to go to the end of a word, as if C-right is emitted. That would be unexpected, but I don't see that happening in the log you posted. Is this really the full sequence that leads to the word-skipping behaviour? If so, what application does it happen in?

[vhbui02]

@nsbgn I'm sorry for lack of information, it was 2am and I'm too sleepy to make a good issue report. Let me summary my situation:

My system info:

• OS + ver: Ubuntu 22.04 LTS, Gnome 42.9, Wayland
• keyd ver: v2.4.3 (5e4ef41)

Answer your question:

However, you also mentioned that it looks like something is inserted that causes your cursor to go to the end of a word, as if C-right is emitted.

I'm sorry for my premature assumption. The behavior occurs in my Fish terminal and the cursor traverse to the end of word. According to Fish shell docs about bindings, It's actually Alt + Right, or A-right is emitted. I've tested in Firefox and reconfirmed this.

That would be unexpected, but I don't see that happening in the log you posted. Is this really the full sequence that leads to the word-skipping behaviour?

Again i'm sorry, It was not the full sequence, it's the first part of it. I've managed to recreate it and capture its log below. NOTE: There are 2 things: Input method "vn", or Vietnamese must be on, set up via ibus-bamboo. It won't happen in built-in English method in Ubuntu.

# These are redundant
##################################################
keyd virtual keyboard	0fac:0ade	leftalt down
keyd virtual keyboard	0fac:0ade	leftalt up
keyd virtual keyboard	0fac:0ade	left down
keyd virtual keyboard	0fac:0ade	left up

keyd virtual keyboard	0fac:0ade	leftalt down
keyd virtual keyboard	0fac:0ade	leftalt up
keyd virtual keyboard	0fac:0ade	left down
keyd virtual keyboard	0fac:0ade	left up

keyd virtual keyboard	0fac:0ade	leftalt down
keyd virtual keyboard	0fac:0ade	leftalt up
keyd virtual keyboard	0fac:0ade	right down
keyd virtual keyboard	0fac:0ade	right up

keyd virtual keyboard	0fac:0ade	leftalt down
keyd virtual keyboard	0fac:0ade	leftalt up
keyd virtual keyboard	0fac:0ade	left down
keyd virtual keyboard	0fac:0ade	left up

keyd virtual keyboard	0fac:0ade	leftalt down
keyd virtual keyboard	0fac:0ade	leftalt up
keyd virtual keyboard	0fac:0ade	right down
keyd virtual keyboard	0fac:0ade	right up

keyd virtual keyboard	0fac:0ade	leftalt down
keyd virtual keyboard	0fac:0ade	leftalt up
keyd virtual keyboard	0fac:0ade	right down
keyd virtual keyboard	0fac:0ade	right up

keyd virtual keyboard	0fac:0ade	leftalt down
keyd virtual keyboard	0fac:0ade	leftalt up
keyd virtual keyboard	0fac:0ade	left down
keyd virtual keyboard	0fac:0ade	left up

keyd virtual keyboard	0fac:0ade	leftalt down
keyd virtual keyboard	0fac:0ade	leftalt up
keyd virtual keyboard	0fac:0ade	left down
keyd virtual keyboard	0fac:0ade	left up

keyd virtual keyboard	0fac:0ade	leftalt down
keyd virtual keyboard	0fac:0ade	leftalt up
keyd virtual keyboard	0fac:0ade	right down
keyd virtual keyboard	0fac:0ade	right up

###############################################

# It's pretty messes up here: here are what I've done: I pressed `J` then released and suddenly pressed `L` then released and suddenly pressed `J`, the third `J` jumped the cursor.
# Last `L` is redundant
keyd virtual keyboard	0fac:0ade	leftalt down
keyd virtual keyboard	0fac:0ade	leftalt up
keyd virtual keyboard	0fac:0ade	left down
keyd virtual keyboard	0fac:0ade	right down
keyd virtual keyboard	0fac:0ade	left up
keyd virtual keyboard	0fac:0ade	leftalt down
keyd virtual keyboard	0fac:0ade	leftalt up
keyd virtual keyboard	0fac:0ade	left down
keyd virtual keyboard	0fac:0ade	right up
keyd virtual keyboard	0fac:0ade	leftalt down
keyd virtual keyboard	0fac:0ade	leftalt up
keyd virtual keyboard	0fac:0ade	right down
keyd virtual keyboard	0fac:0ade	left up
keyd virtual keyboard	0fac:0ade	leftalt down
keyd virtual keyboard	0fac:0ade	right up
keyd virtual keyboard	0fac:0ade	leftalt up

If so, what application does it happen in?

This behavior only occurs when the input method is Vietnamese by ibus-bamboo. it can happen to anything that can input text (e.g. Terminal, Google Docs on Firefox, ...)

Built-in English input method doesn't have this issue.

Conclusion: Now I think the cause of problem is from ibus-bamboo, not keyd anymore :(

[nsbgn]

Thanks for the detailed description!

Conclusion: Now I think the cause of problem is from ibus-bamboo, not keyd anymore :(

But it does happen in conjunction with keyd, right? That is, if you were to simulate those keypresses without keyd running, it doesn't have the same effect?

If I am interpreting your logs correctly, this is the offending sequence:

keyd virtual keyboard	0fac:0ade	leftalt down
keyd virtual keyboard	0fac:0ade	leftalt up
keyd virtual keyboard	0fac:0ade	right down
keyd virtual keyboard	0fac:0ade	left up
keyd virtual keyboard	0fac:0ade	leftalt down
keyd virtual keyboard	0fac:0ade	right up
keyd virtual keyboard	0fac:0ade	leftalt up

... and it is generated by <leftalt down> <j down> <j up> <l down> <l up> <j down> ..., is that correct?

[vhbui02]

That is, if you were to simulate those keypresses without keyd running, it doesn't have the same effect?

If I'm not using keyd how can I simulate those keypresses? You mean by other key mapper like kmonad?

... and it is generated by <leftalt down> <j down> <j up> <l down> <l up> <j down> ..., is that correct?

Yes, that is correct.

[nsbgn]

If I'm not using keyd how can I simulate those keypresses? You mean by other key mapper like kmonad?

Yeah, or manually --- I was mostly trying to figure out if that bare tap of leftalt/leftalt+leftcontrol makes ibus-bamboo respond in some way. But if keyd really inserts a <alt down><j down><j up><alt up> in some weird interplay with ibus-bamboo, I fear we'll have to dig a little deeper. Especially if it only happens after adding that [capslock:C] layer (which I do doubt)...

[vhbui02]

@nsbgn Actually, there is another unwanted behavior associating when keyd integrate with ibus-bamboo, which I've mentioned in ibus-bamboo's GitHub issues: It seems nobody bothers to read it, makes me so sad :( Issue458 I've posted in ibus-bamboo's instead of keyd's since I though ibus-bamboo is the one to take responsible (like I said, when switching to "en", both this issue mentioned behavior and this other behavior which I mentioned in ibus-bamboo issue don't even exist).

I've checked the log, J, K, I, L are indeed down, yet the cursor only moved 1 character then stop. In this issue, it seems like ibus-bamboo has blocked the remaining signal.

Both this issue and that other issue shows that ibus-bamboo tinkers the system deeper than I thought. It might not be you guys's fault.

[nsbgn]

It seems nobody bothers to read it, makes me so sad :(

Don't let it get to you --- it's all volunteer stuff, and there's a lot of issues to deal with ;)

Maybe it's something to do with timing, which you may be able to work around by using something like macro2(100, 100, left) (with an appropriate timeout) instead of plain left, but that's a complete shot in the dark. Otherwise, someone who knows more will have to step in. Good luck!