keyszer
keyszer copied to clipboard
joshgoebel
Remaps may require some delay per distro/DE
Describe the bug or unexpected behavior While inspecting issue #95 where I thought the problem was specific to how something was being held or bound via bind on specific shortcuts we have discovered that it is instead an issue that exists outside of keyszer, python or its libraries. By using evtest we have confirmed that the expected key inputs are being written and transformed just not seen by the OS itself.
Adding a delay like I have in this PR #96 solves the issue but we need to better implement the solution or even discover a way to resolve the issue and figure out how wide spread the problem actually is..
More information will follow, but this is all I will post on it for now. If @RedBearAK would like to test Ctrl-Shift-Up/Down, or any other user, on any distros or DE's the assistance would be appreciated. I have only tested this on Ubuntu Budgie 22.04 at this time.
@rbreaves
So these shortcuts are supposed to grab multiple lines and move them up and down, like a single cursor would move a single line up and down with Alt+arrow in VSCodes? There's no "bind" in my config yet, but I don't seem to be having any issue rapidly moving lines up and down with multiple cursors.
Not sure what kind of ill effect I should be watching for, or why "bind" would be necessary.
Ubuntu 22.04 with Sublime Text installed as a Flatpak.
By using evtest we have confirmed that the expected key inputs are being written and transformed just not seen by the OS itself.
This seems like it could be related to the issues I've always had with text macros dropping characters, especially on this system.
Perhaps related, someone needing to insert a 0.01 delay to get events to register:
- https://stackoverflow.com/questions/63561381/is-there-a-limit-to-how-rapidly-python-evdev-can-write-inject-to-an-input-device
This seems like it could be related to the issues I've always had with text macros dropping characters
It did remind me of that... but in this case we can trigger the [shift lines] combo 6 times (3 up, 3 down)... and it seems ALL the output is entirely ignored by the OS... despite the input/output in the log looking perfect - and despite evtest watching the output registering all the events... they seem to be getting lost FURTHER downstream...
Yet on my machine (Arch)... I can't reproduce the problem at all...
It did remind me of that... but in this case we can trigger the [shift lines] combo 6 times (3 up, 3 down)... and it seems ALL the output is entirely ignored by the OS... despite the input/output in the log looking perfect - and despite evtest watching the output registering all the events... they are getting lost FURTHER downstream...
Weird.
In that case it seems I can't replicate it either. Unless it actually requires "bind" to be involved before the problem will appear.
My fix for the macros remains adding this strangely effective (fixed about 99% of the time with just 1ms delay) sleep line to output.py;
def __send_sync(self):
_uinput.syn()
sleep(1/1000)
Ah that's right... @rbreaves You should try replacing your 0.12 fix with the fix immediately above (right after syn) and see if that helps... the placement might be what's important.
@RedBearAK What bugs me in this case though is that the "fix" (lowering the timeouts) sends the same AMOUNT of data to output, just different data - and then the problem seems to entirely disappear... as if somehow perhaps it's not just timing for something about the content of the output as well...
Doesn't work: (perfect combo, thanks to suspended output)
(OO) press LEFT_ALT
(OO) press LEFT_SHIFT
(OO) press UP
(OO) release UP
(OO) release LEFT_SHIFT
(OO) release LEFT_ALT
Works:
Shift has been held earlier and is being exerted constantly - since it isn't suspended.
(OO) release LEFT_META
(OO) press LEFT_ALT
(OO) press UP
(OO) release UP
(OO) release LEFT_ALT
(OO) press LEFT_META
So 6 events, all fired rapidly... one works great, the other doesn't register at all...
I'd start worrying about ordering except it shouldn't matter and Alt+Shift+Up works find on my computer...
So these shortcuts are supposed to grab multiple lines and move them up and down, like a single cursor would move a single line up and down with Alt+arrow in VSCodes? There's no "bind" in my config yet, but I don't seem to be having any issue rapidly moving lines up and down with multiple cursors.
Sorry no, the remapping is not happening correctly if "Ctrl-Shift-Up/Down" is moving your line up and down, that hotkey does exist too but is different. This combo is to create a multi-line cursor expansion in either the up or down direction.
Easiest to do the experimentation in Sublime Text 3/4 - it can work with VSCode too - but you then have to install a sublime text remap extension and maybe do some additional remapping to keymap as well to have full parity with sublime text. Either way though don't test w/ vscode lol.
I will try the fix you mentioned above @RedBearAK - but I do also want to mention that I did actually test this multi-line cursor expansion in both vscode and sublime text and it failed in both. Like Josh mentioned though we did confirm that this data is being written into the uinput device.. so yea it is getting lost btwn their and the OS.
Also I tried the combo both with bind and without. @RedBearAK Had no impact.
@rbreaves
Oh, sorry, I was using the wrong keys. So it's like Alt+Shift+up/down (logical), Super+Shift+up/down (physical) in VSCodes, to expand the multi-cursor. I've been using that a lot lately in VSCodes with no issue. (But not with the ST3 style shortcuts.)
Starting in the middle of a block of text in ST3 I'm not having any issue alternating up/down to expand the multi-cursor. I assume that the symptom would be that it wouldn't expand at all, or would respond intermittently? I'm not seeing that.
I assume that the symptom would be that it wouldn't expand at all, or would respond intermittently? I'm not seeing that.
Interesting, Josh had difficulty reproducing it as well. What OS are you trying this on? I am wondering if this is Budgie specific. Also it just typically doesn't do anything at all if I am pressing Ctrl-Shift and then Up/Down in fast succession. It does in fact work if done slowly, like a 1-2 second delay btwn Ctrl-Shift and Up/Down. But yes, Ctrl, also known as Super in this case.
@rbreaves
Ubuntu 22.04, GNOME 42.2
I was definitely doing it faster than a 1-sec delay between up/down.
Well colored me confused then.. I just tried adding your 1/1000th of a second delay and it does improve the situation for my bare metal surface pro 6 laptop with ubuntu budgie 22.04 on it..
I also applied it to my VM and it completely resolved it there.. so then I decided to go back to the main branch and make sure that it is still broken there.. and lo and behold my VM of Ubuntu Budgie no longer needs any fixes at all. So I have no idea what is going on now clearly. It was not intermittent for me at all eariler - it was broken in the exact same way on both earlier - but now only the bare metal one appears to have the issue -.-.
I mean all the logging indicates that neither should have the issue, but I don't know now and while that 1/1000th of a delay helps, it doesn't solve it entirely. I will increase it and see how it goes.
Yea I dunno I increased it to 2/1000 but seems about the same, it is more effective in that location than where I had the patch though.. the keys just get through intermittently. And again no idea why it now works on my VM and now I can't break it on my VM any more -.-.
On my laptop where I've always had the problem with macros there are times when it seems to work perfectly, even without the delay. Other times a macro falls flat on its face after just a few characters. These seem to correspond with times when my touchpad is very smooth and accurately tracks my finger, and other times acts like a drunk person handcuffed to a cop. Like there's just something in general going wrong with "input".
It is a very frustrating problem due to this intermittency.
My testing inserting print commands everywhere also seemed to indicate that there was no actual issue with the key events that evdev was trying to send out. Just how they were being received.
I honestly don't know.. I'd have not thought that I'd get such a weird problem duplicated exactly the same in 2 different places like this and then have difficulty reproducing it in the VM later on. Guessing we may need to hold off on switching Kinto over for at least 2-3 weeks though as I am sure we'll come across a resolution by then. Other than this issue though I do need to fix the permissions issue I am having with the setup and figure that out.
I think this issue will now be going on the back burner as I am not sure what else to do with it. So really given that this is the only issue I have ran into thus far, besides the permissions issue, which already existed with xkeysnail/kinto any ways... it really isn't all that bad considering.
Also I suspect keyszer will close a few open tickets, one being the lack of holding keys properly when some modifiers are released but shift remains and then doesn't continue to get passed through. @joshgoebel appears to have fixed that with his rewrite of that component.
Assuming I knock out the permission issues tomorrow I will try and get the changes together and get a new working branch with the installer working properly for keyszer tomorrow.
@rbreaves You might want to test #99 and see if it helps any. I try to strip out even more wasted traffic that we've always been pushing to output. I'm not sure if this matter though since xkeysnail 0.3 and 0.4 are VERY VERY bad in this regard... way worse offenders...
But it's just something else to try to change the "shape" of the output - and see if perhaps it makes a difference.
Will try that out and let you know how it goes - while always making sure I can revert back and that things still break lol - since my VM is now unreliable to test in since it works in every situation :/. Makes me think it is some sort of python caching issue if that is possible.. maybe I should reboot my VM.
maybe I should reboot my VM.
Can't hurt - unless it breaks it - which is another data point. :-)
@rbreaves
I still don't understand how this issue was even an issue (since I couldn't replicate it with or without bind involved), but now I'm wondering if my recently discovered fix for unreliable macros and Unicode sequences would also fix whatever was causing the problem here.
It's just a one-line change, removing the sync line in output.py, send_key_action. See PR #127.
I've been able to discard the weird 1ms sleep delay tweak, with even super-long macros being 99.9% reliable now, but faster, since there's no extra delay being inserted between keystrokes.
It also solved a weird issue with dialog windows not having keyboard focus when they appear.