Keystrokes are not getting locked

[hisacro]

On some instances, mousemode doesn't entirely lock the keystrokes hence keys are registered as normal along with mouse movements. Unsure how to debug, this also persists on X restarts the only workaround so far is restarting my system. Any idea to proceed.

[randoragon]

I'm aware of this issue, but I have not experienced it in years. And even when I did, it was very rare and usually fixed itself after a mousemode restart. So this is a bit strange.

I believe this means that the calls to XGrabKey failed, which iirc can happen e.g. if some other program is already grabbing the keys used by mousemode. To be honest, it is my bad that these calls are not error checked properly.

I can try to fix or at least prevent this situation (e.g. make mousemode print out a warning or an error when it is unable to grab the keys). If you have a way to reproduce, would you mind applying this patch and running mousemode in a terminal to see if there is any stderr output?

diff --git a/mousemode.c b/mousemode.c
index d1697af..3e9ce1d 100644
--- a/mousemode.c
+++ b/mousemode.c
@@ -99,6 +99,21 @@ int handleKeys()
     return 1;
 }
 
+int handler(Display *display, XErrorEvent *ev)
+{
+    fprintf(stderr, "--------------------------------\n");
+    fprintf(stderr, "Error event %lu %p!\n", ev->serial, ev);
+    fprintf(stderr, "  ev->type: %d\n", ev->type);
+    switch (ev->error_code) {
+        case Success: fprintf(stderr, "  ev->error_code: success.\n"); break;
+        case BadAccess: fprintf(stderr, "  ev->error_code: BadAccess!\n"); break;
+        case BadValue: fprintf(stderr, "  ev->error_code: BadValue!\n"); break;
+        case BadWindow: fprintf(stderr, "  ev->error_code: BadWindow!\n"); break;
+        default: fprintf(stderr, "  ev->error_code: unknown error %d!\n", ev->error_code); break;
+    }
+    return 0;
+}
+
 void grabkey(int keysym)
 {
     KeyCode code;
@@ -121,6 +136,8 @@ int main()
     signal(SIGTERM, termhandler);
     signal(SIGINT, termhandler);
 
+    XSetErrorHandler(handler);
+
     if (!(dpy = XOpenDisplay(NULL))) {
         fprintf(stderr, "mousemode: failed to open display");
         return 2;

[hisacro]

I have applied the patch, let me see if I can reproduce. Previously it happened whenever I resurrect from suspend

[hisacro]

Even with the patch, I couldn't find what was getting interrupted but I found a stupid hack to regain mousemode functionality, I will make a video of it next time!

[hisacro]

Here we go!

mousemode_hack.mp4

so I'm using setxkbmap's pointerkeys, it converts keypad to mouse. Btw I have to raise another issue on right clicks not working with mousemode (do you have similar ones? I wrote a writeup on it too https://displ.nl/blog/poisoining-rat/ - 3rd video documents it)

[randoragon]

so I'm using setxkbmap's pointerkeys, it converts keypad to mouse. Btw I have to raise another issue on right clicks not working with mousemode (do you have similar ones? I wrote a writeup on it too https://displ.nl/blog/poisoining-rat/ - 3rd video documents it)

Wow, so you can get rid of keystrokes "bleeding through" by temporarily enabling this mysterious keypad:pointerkeys feature (first time I'm hearing of it, if I had known then maybe I would have never written mousemode, huh)? I don't feel knowledgeable enough on X to be able to deduce any fix in mousemode based on this, unfortunately.

What bothers me more is that the patch did not expose any errors reported by X. So, presumably XGrabKey succeeds, but behaves in an inconsistent way for some other reason.

As for the right click issue, I'm only aware that in certain GUI applications like Firefox, the context menu disappears on D key release, instead of remaining open for a second click like when you use a real "rat". This never bothered me though, because if you hold down D and use HJKL to hover over your desired menu item, the D release acts as the second click. So it's mostly a minor inconvenience. I don't recall ever seeing mousemode being straight up unable to get any right click interaction like in your video.

---

As this stands, I don't have an idea of how to tackle this issue. Perhaps there's a way to enable more verbose logging. Looking for how other, more robust open source projects use XGrabKey could also reveal some answers. In any case, I'm not planning a journey into this rabbit hole, because I don't have a way to reproduce the issue. Moreover, I've recently switched to Wayland, so I don't have much of an incentive to continue developing mousemode. I don't mind answering to issues and reviewing PRs though.

[hisacro]

Wow, so you can get rid of keystrokes "bleeding through" by
temporarily enabling this mysterious keypad:pointerkeys feature

Yeah!

(first time I'm hearing of it, if I had known then maybe I would have never written mousemode, huh)?

No! I don't think you can change the keysym from numpad for pointerkeys moreover, the acceleration and speed controlling is not documented :\
It has very specific usecase like that paper I linked at the bottom, for people with impaired hand movements.

This never bothered me though, because if you hold down D and use HJKL to hover over your desired menu
item, the D release acts as the second click. So it's mostly a minor inconvenience.

With firefox I can do this, but no so with other GUIs.

I don't recall ever seeing mousemode being straight up unable to get any right click
interaction like in your video.

It happens with few of the applications on mine, like nm-applet, nautilus, xfce4-terminal

I'm not planning a journey into this rabbit hole, because I don't have a way to reproduce the issue.

Ah, no issues! I'm very content with what mousemode can do, really appreciate this teeny tiny package that changed my workflow totally!

Moreover, I've recently switched to Wayland

Do you use something similar to mousemode there?

[randoragon]

It happens with few of the applications on mine, like nm-applet, nautilus, xfce4-terminal

Mm ok, maybe I just hadn't been using enough GUI applications to stumble upon this bug. It's a bit unfortunate, I wish the right click worked properly.

Ah, no issues! I'm very content with what mousemode can do, really appreciate this teeny tiny package that changed my workflow totally!

Happy to hear, and thank you for your awesome feedback and involvement with mousemode!

Do you use something similar to mousemode there?

No, not at the moment. It's been almost 2 months and not all of my old workflow has carried over yet.

[hisacro]

I think I found a way to replicate the issue!

Pressing Numlock while using mousemode causes the keystrokes to register, I tried on 2 devices, the behavior is same.