Mitigation for unreliable macros

[RedBearAK]

@rbreaves

After some lengthy discussion on an xkeysnail issues thread, it seems the problem I've run into on multiple machines and multiple Linux distros with multi-key macros behaving unreliably might actually stem from the Kinto patched version of xkeysnail. I can't replicate the problem with the unpatched xkeysnail branch, and I tried pretty hard.

Found a relatively innocuous mitigation measure, thanks to @joshgoebel. Insert a tiny delay into output.py.

Take this:

def send_sync():
    _uinput.syn()

Turn it into this:

import time

def send_sync():
    _uinput.syn()
    time.sleep(1/1000)

Yes, that is literally just 1ms of delay, the smallest possible with time.sleep(). Yet it takes my main Ryzen 3700u laptop with Ubuntu 22.04 from about 50% reliability with macros like the Firefox preferences shortcut to about 99% reliability with that and even longer macros. Without this I would often have to do Cmd+comma two or even three times before it worked properly in Firefox to open the preferences.

No idea how or why this works, or why the macro errors only seem to happen with the Kinto branch.

[joshgoebel]

https://github.com/mooz/xkeysnail/issues/150

[rbreaves]

Interesting, wonder if I could turn this into a throttle that is only enabled if a param is passed - ex. xkeysnail --throttle=1 ./filename.py.

[RedBearAK]

@rbreaves

The printed output seemed to show an excessive amount of press/release events for keys that weren't part of the shortcut, especially RIGHT_CTRL, but also LEFT_SHIFT. This doesn't happen with mainline xkeysnail.

https://github.com/mooz/xkeysnail/issues/150#issuecomment-1140613615

Clearing up the source of the extra events should put a lot less pressure on the uinput buffer while doing macros. Might make the delay unnecessary in most cases.

[joshgoebel]

@RedBearAK You interested in testing alpha versions of keymapper or only beta/release? I've been working on a big rethink.

[joshgoebel]

@RedBearAK One other thing you could test if you want is to DROP non-key inputs...

def on_event(event, device_name, quiet):
    # we do not attempt to transform non-key events 
    if event.type != ecodes.EV_KEY:
        _output.send_event(event) # REMOVE THIS LINE
        return

All I've ever seen come thru there are scancode and SYNs (paired with the scancodes and key events)... come to think of it that means we're also doubling up SYNs on the output as well (and sending a SYN for every SYN!), which can't help matters any.

What would happen if you just removed that line and we just DROPPED all the scancodes and related SYNs on the floor and only passed key events?

[RedBearAK]

@joshgoebel

@RedBearAK You interested in testing alpha versions of keymapper or only beta/release? I've been working on a big rethink.

Short answer, yes. Although I might need some pointers here and there to get the full log results you would probably be looking for in testing such early iterations.

Hope we can work on things like the first modifier key press after restarting xkeysnail somehow getting lost. Not sure if this only applies to the Kinto patched branch or also mainline. But it's really annoying because of all the testing of new shortcuts that I'm always doing. I always forget to tap a modifier before trying to Alt+Tab after restarting Kinto.

Anyway, I have the ability to set up VMs quickly in Boxes, and test in a clean snapshot state and revert if necessary. Shouldn't be too much trouble to test even alpha stuff, within reason.

I am in the midst of working on adding a scheme for Mac-style Option-key special character input to the Windows version of Kinto (AutoHotKey):

https://github.com/rbreaves/kinto/issues/622#issuecomment-1143509440

I can't help but think it shouldn't be too difficult to add this kind of "dead keys" ability to xkeysnail. And, the ability to use a shortcut to enable/disable it, since it can interfere a bit with accessing menu bar items with the Alt key.

Then there's the WM_NAME patch, and attempting to differentiate between main app windows and open/save dialogs and such.

I don't know exactly which directions you were planning on going with either Kinto or xkeysnail, but these are things I would be very interested in seeing added or improved.

My main/only reason to be using xkeysnail is because I use Kinto, just so that's clear.

[RedBearAK]

@joshgoebel

One other thing you could test if you want is to DROP non-key inputs

I found the function in transform.py but there is nothing in it that looks like that.

Tried just sticking that snippet in at the top of the function and got:

NameError: name 'ecodes' is not defined

Mainline transform.py also does not appear to resemble that snippet. So I'm lost as usual. Unless I paste it in, there is no line like that to remove.

Does this need another new import to work?

[joshgoebel]

I found the function in transform.py but there is nothing in it that looks like that.

Sorry, nevermind... I forget how much I've changed things already. :)

[joshgoebel]

Hope we can work on things like the first modifier key press after restarting xkeysnail somehow getting lost.

Never seen this. Of course what I'm using now has an entirely rewritten input pipeline.

Mac-style Option-key special character input

Can't we do that here already with just a simple nested mapping? Of course you'll only be able to output keys that actually exist in the kernel keyboard map, not any random UTF-8 character... the disadvantage of being low-level...

[RedBearAK]

@joshgoebel

Can't we do that here already with just a simple nested mapping?

I'm putting the reply to this in the "Umlaut" thread:

https://github.com/rbreaves/kinto/issues/622

[joshgoebel]

Thanks, I've never seen that thread. :) I'm more worried about basic modifiers right now than typing complex accented characters, but that's awesome that you're pushing this forward.