(Wayland) Key repeat doesn't work when switching keys

[autolyticus]

Hi

I've looked at both #120 and #292 and the problem is similar but not quite like these ones.

This isn't specific to any particular key.

Let's say I press j (or any other key) for a while (say 3 seconds), the keys begin repeating

jjjjjjjjjjjj

Now when I switch to another key, say k

jjjjjjjjjjjjk

It stops at a single k however long I press the key.

If I run kitty with env WAYLAND_DISPLAY= kitty (under XWayland) then the problem disappears and I get

jjjjjjjjjjjjkkkkkkkkkkkk

as expected.

I'm using kitty under Wayland through glfw-wayland (SwayWM if that is relevant) Output of kitty --debug-config

kitty 0.15.0 created by Kovid Goyal
Linux archlinux 5.4.2-arch1-1 #1 SMP PREEMPT Thu, 05 Dec 2019 12:29:40 +0000 x86_64
Arch Linux \r (\l)
Loaded config files: /home/g/.config/kitty/kitty.conf
Running under: Wayland

Config options different from defaults:
background            Color(red=29, green=32, blue=33)
bell_on_tab           False
color0                Color(red=29, green=32, blue=33)
color1                Color(red=251, green=73, blue=52)
color10               Color(red=184, green=187, blue=38)
color11               Color(red=250, green=189, blue=47)
color12               Color(red=131, green=165, blue=152)
color13               Color(red=211, green=134, blue=155)
color14               Color(red=142, green=192, blue=124)
color15               Color(red=251, green=241, blue=199)
color16               Color(red=254, green=128, blue=25)
color17               Color(red=214, green=93, blue=14)
color18               Color(red=60, green=56, blue=54)
color19               Color(red=80, green=73, blue=69)
color2                Color(red=184, green=187, blue=38)
color20               Color(red=189, green=174, blue=147)
color21               Color(red=235, green=219, blue=178)
color3                Color(red=250, green=189, blue=47)
color4                Color(red=131, green=165, blue=152)
color5                Color(red=211, green=134, blue=155)
color6                Color(red=142, green=192, blue=124)
color7                Color(red=213, green=196, blue=161)
color8                Color(red=102, green=92, blue=84)
color9                Color(red=251, green=73, blue=52)
cursor                Color(red=235, green=219, blue=178)
cursor_blink_interval 0.5
enable_audio_bell     False
font_family           PragmataProMonoLiga-Regular
font_size             14.0
foreground            Color(red=213, green=196, blue=161)
macos_option_as_alt   3
scrollback_lines      10000
scrollback_pager      ['bat', '-p']
Changed shortcuts:
     shift+control+t KeyAction(func='new_os_window_with_cwd', args=())

[kovidgoyal]

I cannot reproduce running kitty master under sway-1.2-5 (arch). Steps I tried:

1) Press the a key, wait for it to start repeating 2) Release the a key 3) Press the b key and hold 4) b repeats

Or alternately, 1) Press the a key, wait for it to start repeating 2) Press the b key without releasing a key 3) b repeats

[autolyticus]

Could you give me some pointers on where the issue could be / how I could debug this issue on my own? It persists even on a default sway config and even on a different laptop and a brand new installation of arch

[kovidgoyal]

You can run kitty with --debug-keyboard and see what events are printed out. And then the code for handling key events under wayland is in wl_init.c and wl_window.c just search for key to find it.

Instructions for building kitty from source are here: https://sw.kovidgoyal.net/kitty/build.html

[cjtenny]

Hi, I've observed this issue in kitty 0.19.1 running swaywm as well. I've noticed that it seems to occur around delay in either handling or receiving the key release event from the pressed key. Every time it happens, with --debug-keyboard under Wayland or XWayland I see a press event for the repeat key, then repeat events, then a press for the second key followed by the release for the first repeating key - and the second key does not repeat. This can happen even when I've made sure I've definitely physically released the first key and given a delay before pressing the second key, though it is time sensitive - the delay certainly needs to be under a second, but not much under, which is still a very noticeable latency. Please let me know if you'd like more information or the output of kitty --debug-keyboard for this.

[kovidgoyal]

If you are getting an incorrect sequence of events, then the issue is in the compositor, kitty can only react to whatever events it receives. One could in theory hide this compositor bug in kitty, by not stopping repeats when the release event is for a different key than the repeats, this is what happens in the X11 backend, IIRC, but given that the bug is in the compositor, and this would just be a workaround, I am not particularly motivated to implement it. Patches are welcome.

[kovidgoyal]

I had a minute, so I implemented it.

[autolyticus]

Thanks! I really appreciate the effort and dedication you put into maintaining your projects. Both projects don't seem like they're trivial in any sense of the word and are beautifully architected monolithic code bases. It's something I aspire towards some day.

I really hoped to find one of your projects in https://aosabook.org/en/index.html so that I could learn more but was disappointed. Maybe you could think about writing a book (or a chapter for the above book) so that more people can learn your development philosophy?

Disclaimer: I have absolutely nothing to do with the creators of the book and am not marketing in any way. It just seemed a natural place for it to be

[kovidgoyal]

You are most welcome :) As for writing up my development philosophy for aosa, sure I can do that, if the publishers of the book are interested. It's been a while since I have written anything long form, might be fun. I think the last time was a chapter in a book on quantum computation.

[autolyticus]

Mind telling me a bit more about the book so I can give it a glance? I've always been interested in the topic. Couldn't quite get the activation energy (hehe) to actually sit down and understand the concepts. (I do understand that it is veering off topic and GitHub discussions are probably not the best place for this)

[kovidgoyal]

https://www.amazon.in/Quantum-Error-Correction-Daniel-Lidar/dp/0521897874

The book isnt really suitable as an introductory read. It's a fairly technical overview. I contributed the chapter on topological error correction, for a more detailed overview of which, you can see my thesis https://thesis.library.caltech.edu/2177/

[mariuszs]

This issue still appearers for me, for examle cursor right is not working sometimes. I'm not sure what is the reason. Fedora 36 with wayland, fish shell.

[page-down]

@mariuszs

You can try the nightly release.

https://github.com/kovidgoyal/kitty/issues/5188

[teto]

I had this behavior (could not repeat a key, keys being discarded...) among other things (couldn't copy/paste anymore) and thanks to this ticket and --debug-keyboard I could see that even when I was not touching the keyboard, I had infinite log of text-input: updating IME focus state. systemctl stop --user fcitx5-daemon fixed it. Now I am not sure if it's a bug in fcitx5 but its doesn't look suspicious.