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

Keyboard repeat rate / delay on wayland does not respect system settings #669

Closed
yiding opened this issue Apr 9, 2021 · 3 comments
Closed
Labels
bug Something isn't working Wayland

Comments

@yiding
Copy link

yiding commented Apr 9, 2021

Describe the bug

Keyboard repeat rate and delay does not respect what's configured in the desktop environment.

Environment (please complete the following information):

  • OS: Linux Wayland
  • Version: ezterm 20210405-110924-a5bb5be8

To Reproduce

Run wezterm on gnome wayland.
Play with different repeat rate/speeds in gnome settings > accessibility > repeat keys.

Expected behavior

Keyboard repeat in wezterm respect the settings / behave the same way as other apps.

@yiding yiding added the bug Something isn't working label Apr 9, 2021
@wez wez added the Wayland label Apr 9, 2021
@gwww
Copy link
Contributor

gwww commented Apr 12, 2021

I have something similar on MacOS, although I don't know if its wezterm being slow or keyboard repeat rate.

When in vim, on say iTerm2, and I hold down the j key then it moves through the file extremely quick (at what would appear to be my keyboard repeat rate). Same scenario in wezterm the movement is very slow, along with lines of a standard keyboard repeat rate.

I don't know how to isolate further. Is it repeat rate? Screen redraw? Something else?

@wez
Copy link
Owner

wez commented Apr 13, 2021

On Wayland wezterm is currently deliberately ignoring the system repeat rate because the client library that handles that goes into a busy loop.

On macOS wezterm generates key events at the same rate that macos delivers them to wezterm.

rbutoi pushed a commit to rbutoi/dotfiles that referenced this issue Jun 2, 2021
also tried wezterm, almost works except
wez/wezterm#669

alacritty is same as kitty in lack of mosh truecolor support

+github.com/sayanarijit/pomo
rbutoi pushed a commit to rbutoi/dotfiles that referenced this issue Jun 2, 2021
also tried wezterm, almost works except
wez/wezterm#669

alacritty is same as kitty in lack of mosh truecolor support

+github.com/sayanarijit/pomo
rbutoi pushed a commit to rbutoi/dotfiles that referenced this issue Jun 2, 2021
also tried wezterm, almost works except
wez/wezterm#669

alacritty is same as kitty in lack of mosh truecolor support

+github.com/sayanarijit/pomo
rbutoi pushed a commit to rbutoi/dotfiles that referenced this issue Jun 9, 2021
also tried wezterm, almost works except
wez/wezterm#669

alacritty is same as kitty in lack of mosh truecolor support

+github.com/sayanarijit/pomo
rbutoi pushed a commit to rbutoi/dotfiles that referenced this issue Jun 11, 2021
also tried wezterm, almost works except
wez/wezterm#669

alacritty is same as kitty in lack of mosh truecolor support

+github.com/sayanarijit/pomo
@wez wez closed this as completed in 0a00ffe Jun 27, 2021
@github-actions
Copy link
Contributor

github-actions bot commented Feb 4, 2023

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working Wayland
Projects
None yet
Development

No branches or pull requests

3 participants