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.

Sign up for GitHub

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

Jump to bottom

update sway 1.6 seems have some compatible with fcitx5 and alacritty #6193

Open
chenjie199234 opened this issue Apr 17, 2021 · 5 comments
Open

update sway 1.6 seems have some compatible with fcitx5 and alacritty #6193

chenjie199234 opened this issue Apr 17, 2021 · 5 comments
Labels
bug Not working as intended

Comments

@chenjie199234
Copy link

OS: archlinux
Sway Version: 1.6
Fcitx5 Version: 5.0.7
Alacritty Version: 0.7.2

Follow the below steps to reproduce the problem
1.open the sway
2.open a alacritty window
3.run fcitx5 in the alacritty window
4.switch to another workspace
5.open a alacritty window
6.make sure there is only one window in the current workspace which is the one you opened in step 5
7.input exit and enter to quit the alacritty window
8.switch to the first workspace which has the fcitx5 running on it

now the enter key input will be automaticly trigered.
@chenjie199234 chenjie199234 added the bug Not working as intended label Apr 17, 2021
@wuliaotc
Copy link

You can try disabling the wayland front-end in fcitx5-configure. The reason may be that text intput protocol is not perfect.

@fosskers
Copy link

See also https://bugs.archlinux.org/task/70485?project=5&opened=33998

@s-mcf
Copy link

s-mcf commented Apr 18, 2021

#6095 tracks a very similar issue. NB some of the people in that issue are not using fcitx. Personally, I see it if and only if fcitx5 is running.

yuja added a commit to yuja/fcitx5 that referenced this issue May 4, 2021
@yuja
Stop key repeat timer on wayland keyboard grab cleared
e45df7c 
This should fix one of the unexpected key inputs problem on sway:
swaywm/sway#6193

The problem occurs as follows:

 1. press Ctrl+d to exit from terminal emulator
 2. fcitx captures the key press event and enables repeat timer
 3. terminal emulator exits (while the key is still pressed)
 4. fcitx sends key repeat events indefinitely (since there's no release event)

It's unclear whether this is a bug of the compositor (i.e. sway) or not, but
I think it's better for fcitx to not carry the key-repeat state over to new
keyboard grab.
@yuja yuja mentioned this issue May 4, 2021
Merged
@yuja
Copy link

yuja commented May 4, 2021

Appears that key release event is lost at "7.input exit and enter to quit the alacritty window"
and fcitx sends key repeats because of that.

So I made a patch to make fcitx stop the key-repeat timer on deactivate. I'm not pretty sure if
this change is correct, but it seems that the problem goes away at my end.

fcitx/fcitx5#271

wengxt pushed a commit to fcitx/fcitx5 that referenced this issue May 4, 2021
@yuja
Stop key repeat timer on wayland keyboard grab cleared (#271)
f48fcd1 
This should fix one of the unexpected key inputs problem on sway:
swaywm/sway#6193

The problem occurs as follows:

 1. press Ctrl+d to exit from terminal emulator
 2. fcitx captures the key press event and enables repeat timer
 3. terminal emulator exits (while the key is still pressed)
 4. fcitx sends key repeat events indefinitely (since there's no release event)

It's unclear whether this is a bug of the compositor (i.e. sway) or not, but
I think it's better for fcitx to not carry the key-repeat state over to new
keyboard grab.
@yuja
Copy link

yuja commented May 5, 2021

Note that the fcitx patch should mitigate some of the key repeats problem seen in sway 1.6,
but apparently lack of the key release event causes other problems.

a. run fcitx5 in terminal -> ctrl+c to terminate -> "c" printed indefinitely
b. run fcitx5 in background -> run gvim (X11 app) -> run terminal -> ctrl+d to exit from terminal -> "d" inserted to gvim indefinitely

IIUC, key events are handled as follows:

  1. key event comes from physical keyboard
  2. grabs it to redirect to fcitx5 (or other input method)
  3. key event comes from virtual keyboard of the input method
  4. update_shortcut_state() for the virtual keyboard, and wlr_seat_keyboard_notify_key()

https://github.com/swaywm/sway/blob/1.6/sway/input/keyboard.c#L513

If the keyboard grab destroyed while a key pressed, future key release event from physical keyboard
wouldn't be redirected to the input method. The event wouldn't go through the step 4 either because
the corresponding press event came from the virtual keyboard, not from the physical keyboard.
So the key remains in pressed state.

yuja added a commit to yuja/wlroots that referenced this issue May 7, 2021
@yuja
virtual_keyboard: Emulate key release events on destroy
ad386c6 
According to libinput, release events are generated when device is unplugged,
and libinput copies this behavior for device removal. Let's do the same for
our virtual keyboard.

https://github.com/wayland-project/libinput/commit/8f846a41fa0566fbd72ece676656e20e56ce43e6

This is another attempt to fix swaywm#2034 and the following sway issue:

swaywm/sway#6254

Note that we have other key repeating issues in sway, which aren't addressed
by this patch. Since the virtual keyboard itself isn't destroyed when the
keyboard grab is destroyed, we'll probably need some trick to reset the state
of the corresponding virtual keyboard when the grab is released.

swaywm/sway#6095
swaywm/sway#6193
@yuja yuja mentioned this issue May 7, 2021
Merged
emersion pushed a commit to swaywm/wlroots that referenced this issue May 7, 2021
@yuja @emersion
virtual_keyboard: Emulate key release events on destroy
8008d21 
According to libinput, release events are generated when device is unplugged,
and libinput copies this behavior for device removal. Let's do the same for
our virtual keyboard.

https://github.com/wayland-project/libinput/commit/8f846a41fa0566fbd72ece676656e20e56ce43e6

This is another attempt to fix #2034 and the following sway issue:

swaywm/sway#6254

Note that we have other key repeating issues in sway, which aren't addressed
by this patch. Since the virtual keyboard itself isn't destroyed when the
keyboard grab is destroyed, we'll probably need some trick to reset the state
of the corresponding virtual keyboard when the grab is released.

swaywm/sway#6095
swaywm/sway#6193
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Not working as intended
Milestone
No milestone
Development

No branches or pull requests
5 participants
@yuja @fosskers @s-mcf @chenjie199234 @wuliaotc