Delay on all keys (key repeat reset) #1
Comments
|
@TingoL it doesn't happen for me, did you increase process priority like suggested? Also if you're using the older caps2esc based on xcape and xmodmap, it's best advised to reset such configurations. |
|
Yes, I've started it with nice -n 20. And I've cloned master today so it should be up to date. I'll try to investigate further... |
|
@TingoL Noooo! nice must be -20! |
|
You made it the lowest priority possible. |
|
Oh wow, you're right. But the issue still remains, even with -20, it seems it was unrelated to my problem... |
|
Did you make sure to quit an older instance before starting anew? Starting with older instance running may just end up finishing without notice. |
|
Yes, checked again with pgrep and htop, no process running after killing it. Started it again and same issue. |
|
I'm sorry but I'm just unable to reproduce this (by now I'm just so happy with it). Could you show it up so that I have an idea? Through a short video or possibly http://asciinema.org/. |
|
Not sure whether such recording could be made self-explanatory though. |
|
Well I tried to make it obvious in the recording. |
|
Thanks for the video. Well.... I've tried to do the same in my machine, both running and not running caps2esc and the effect in both situations was exactly the same. But also, I may not be understanding what exactly is happening for you, in which moment it's slow, etc. That's what I was afraid of. So, I think a good idea if possible would be to do the minimal test case video without caps2esc running and then, try to record a test case video typing exactly the same so that the difference is made explicit. You said it's also happening in the browser or any other place, so it should not be related with As I've just created this tool, I consider it useful to dig this so that I become aware of any compatibility issues. So thanks for the report effort. |
|
No problem and thanks for the quick response. Your tool will be very useful to me in the future so I'm glad to be of help. Here's a with/without video to clear things up. https://asciinema.org/a/bieidcvlvsn8d6e18f4hh9od9 echo $KEYTIMEOUT says 1. |
|
Are you on Archlinux? You may now use the AUR package. It's interesting because it's easier to check the instances and devices being captured:
Here I was with just my macbook keyboard at first, and then attached a bunch others to the USB. I'm just curious whether there are excessive instances for you, though I think there isn't. Well, I repeated many times your test here in my machine and I think my behaviour, which has never been a problem for me, looks a bit more like when you activate caps2esc, regardless whether I'm using caps2esc or not. So your no-caps2esc sample seems a little bit faster than what my system does by default. So I thought whether you have ever tweaked key repeat settings in your system, got used to it and forgot about it? Anyway, I've then tweaked key repeat as I pleased using dconf:
Default is 500/30 for me. The thing is that I can put any value there. Here on my system, with and without caps2esc, it presents the same rate, whatever value I put there. This is how it's done on Gnome though. One hypothesis is whether your system has a higher key repeat (set by you or distro specific) and caps2esc usage ends up resetting it to some other value. |
|
You were right, I've set the rate to 250/50 and it gets reset when I run caps2esc. So I've just put my rate setting program to come after caps2esc during startup and now it's all good. :) |
|
\o/ glad it was at last figured out :-) |
If you press and hold any key on the keyboard, it will work once, then nothing will happen for a second, then it starts to work as intended. Which makes usage very hard and cumbersome.
The log and err don't show anything.
The text was updated successfully, but these errors were encountered: