Performance issue:

[ragumagu]

Any one find xcape to be slow on Ubuntu 18.04? I'm using gnome3.

I have a script which sets my Spacebar to generate Ctrl when pressed down, and Space when pressed and released, and some other keys too.
xcape·-e·'Control_L=Escape;Shift_L=BackSpace;Shift_R=BackSpace;Hyper_L=space'·-t·100
But when I type fast, the space event is generated after a slight delay, which causes the text to appear after a certain delay. I want to clarify that again: When typing fast, a 'Space' is still generated, not a Control. However, if a certain shortcut could be typed as in "this is a sentence", the space between is and a is made a 'Ctrl' event and all text is selected. This generation of 'Ctrl' event is expected, but not the delayed text.

There is a question by another person on AskUbuntu about this. But there it ends unresolved, and that's it.

How to find out more about this?
Decreasing the time out does not help much.
Am I missing any necessary packages? Is this deprecated in Ubuntu 18.04?

This may be related to Issue #95: Delay prints character too late. But I remember having better feedback from xcape on Ubuntu 14.04, that is, before upgrading. Or is this the predicted behaviour?

[loota]

It's slow for me too on Ubuntu 18.04 with Gnome.

[ragumagu]

Yes. But after a few weeks, I've now gotten used to it. :)

…

On Wed, Mar 27, 2019, 9:42 PM loota ***@***.***> wrote: It's slow for me too on Ubuntu 18.04 with Gnome. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#109 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVzDPya18eA7yOB5sPJZNVcFzQezfQXKks5va5iCgaJpZM4Zkl2r> .

[loota]

It's excellent that you can live with it! But in the hopes that someone will make it faster, I'll put down my adventures. tldr no workaround yet:

• xcape slows down only when a mapped key is pressed. When running xcape in debug mode it showed that non-mapped keys are actually intercepted but it doesn't slow down then.
• There is also an interesting effect after pressing a mapped key: the next keypress, even if it is not mapped, will also produce delay. After that, there is again no delay unless a mapped key is pressed.
• sysprof profile shows that xcape is not taking much resources. However, there are calls under Xorg: DeletePassiveGrabFromList, GrabMatchesSecond and ResourceClientBits which take up about 40% of cumulative resources. I tested the profiling by mapping a key with xcape and pounding it about 50 times, which resulted in my Gnome being unresponsive for about a minute.

Logs

There are warnings to be found with journalctl when the delay happens. The warnings appear after the delay:
maalis 27 22:33:21 foomachine org.gnome.Shell.desktop[2092]: Window manager warning: Overwriting existing binding of keysym 30 with keysym 30 (keycode 13).
maalis 27 22:33:21 foomachine org.gnome.Shell.desktop[2092]: Window manager warning: Overwriting existing binding of keysym 31 with keysym 31 (keycode a).
maalis 27 22:33:21 foomachine org.gnome.Shell.desktop[2092]: Window manager warning: Overwriting existing binding of keysym 33 with keysym 33 (keycode c).
maalis 27 22:33:21 foomachine org.gnome.Shell.desktop[2092]: Window manager warning: Overwriting existing binding of keysym 34 with keysym 34 (keycode d).
maalis 27 22:33:21 foomachine org.gnome.Shell.desktop[2092]: Window manager warning: Overwriting existing binding of keysym 35 with keysym 35 (keycode e).
maalis 27 22:33:21 foomachine org.gnome.Shell.desktop[2092]: Window manager warning: Overwriting existing binding of keysym 36 with keysym 36 (keycode f).
maalis 27 22:33:21 foomachine org.gnome.Shell.desktop[2092]: Window manager warning: Overwriting existing binding of keysym 37 with keysym 37 (keycode 10).
maalis 27 22:33:21 foomachine org.gnome.Shell.desktop[2092]: Window manager warning: Overwriting existing binding of keysym 38 with keysym 38 (keycode 11).
maalis 27 22:33:21 foomachine org.gnome.Shell.desktop[2092]: Window manager warning: Overwriting existing binding of keysym 39 with keysym 39 (keycode 12).
maalis 27 22:33:21 foomachine org.gnome.Shell.desktop[2092]: Window manager warning: Overwriting existing binding of keysym 32 with keysym 32 (keycode b).

Mutter

• The source of the warnings is Mutter, Gnome's window manager. If I understood correctly, Gnome Shell is a plugin of Mutter.
• The error message seems to come from this function: https://gitlab.gnome.org/GNOME/mutter/blob/master/src/core/keybindings.c#L559
• Chart of how I guess Mutter ends up to the call index_binding. To be taken with a grain of salt as I have only little experience with C: https://tinyurl.com/y6dxnkf4

XTestFakeKeyEvent

• The calls that cause the delay are the same ones that send the desired key events, in the xcape file xcape.c function handle_key(). They are calls to function XTestFakeKeyEvent() which if commented remove the delay but also the desired effect.
• I tested a few hard coded XTestFakeKeyEvent-calls before the event loop at the start of the program and there was no delay there so it seems like there's some kind of obscure interaction between Gnome and Xcape and their ways of using X.

xcape is a bit challenging to hack for people like me with little X experience since it often hangs the whole X if you make mistakes in the code because it can start intercepting the intercepted presses and forkbomb itself skyhigh.

[loota]

I also tested xcape with Xubuntu 18.04 Live DVD in Virtualbox and it worked like a charm. Looks like Gnome 3 is the one common denominator here.

Also, my Ubuntu 18.04 tests have been in virtual machine, but the Debian KDE test was not a virtual machine.

Fedora has already Wayland so xcape won't probably work there at all.

[ragumagu]

The delay feels like something that comes with running an empty for loop, or buffering the text. I do not know what logs to refer to, though.

[loota]

This was a lie: "I tested a few hard coded XTestFakeKeyEvent-calls before the event loop at the start of the program and there was no delay there". My apologies.

The program took a long time to start and my inexperience with c caused me to use printf-statements without newlines, which were not flushed immediately, and this confused me.

There is definitely a delay and xorg goes to 40% when running a minimal program, which does not happen on Xubuntu:

#include <X11/extensions/XTest.h>
#include <X11/keysym.h>

/* Compile this using
g++ numloc.cpp -lXtst -lX11
*/

int main()
{
  Display* display= XOpenDisplay(NULL);
  XTestFakeKeyEvent(display, XKeysymToKeycode( display, XK_Num_Lock ), true, CurrentTime);
  XTestFakeKeyEvent(display, XKeysymToKeycode( display, XK_Num_Lock ), false, CurrentTime);
  XCloseDisplay( display );
}

Even more curious is that the above program does not produce the hangover effect, that is, when you press a key after the program terminates and there's the delay of a second before the press happens and Xorg goes to 40% cpu. This program does do that:

#include <X11/Xlib.h>
#include <X11/extensions/XTest.h>
#include <X11/keysym.h>
/* gcc -o minimal-xtestfake minimal-xtestfake.c -lXtst -lX11 -Wall -Wextra  && ./minimal-xtestfake */
int main() {
    Display *display;
    display = XOpenDisplay(NULL);

    XTestFakeKeyEvent (display, XK_Num_Lock, True, 0);
    XTestFakeKeyEvent (display, XK_Num_Lock, False, 0);

    XCloseDisplay(display);
}

A possible workaround could be to compile the program as C++

[loota]

Compiling as C++ (and the required casting of a few mallocs and callocs) did not help. The computer said a definite no.

I found out the difference between the above code examples: the latter one was ran immediately after compiling with shell operator &&. The previous program will also produce the hangover effect if it is run similarly, and neither program will produce the hangover effect if ran in a separate command.

Compiling xcape in a separate command did not work around the delay.

[loota]

I tested with Linux Mint 19 with Cinnamon with xcape from apt and there was no problem.

I installed xubuntu-desktop to my Ubuntu virtual machine, and when using a Xubuntu session xcape works ok.
apt install tasksel
tasksel install xubuntu-desktop

[mcnelson]

Same behavior on Fedora/GNOME. Caps lock key as single-press == escape (and holding == ctrl) is too slow to be useful. It's especially noticeable in Vim when leaving insert mode and making other keystrokes too fast immediately after.

I'm interested in helping diagnose this.

[salgadobreno]

I've got Caps lock key as single-press == escape (and holding == ctrl) setup on my Dell XPS 15 and in the work desktop. On the desktop it's not slow at all and works ok, on my laptop though, it's more like a 4 second freeze on the machine any time a "Caps->Esc" happens... For a "Caps->Ctrl" there's no noticiable delay.

[quicknir]

Having the exact issues as described by @loota . It's slow to generate the escape when I hit ctrl, and then the first keystroke after is also delayed. Any solution/fix for this?

[quicknir]

@loota can you post the changed code/makefile to make it work with c++ if you still have it handy?

[rafaeln]

xwrits was giving me the same kind of trouble, so I finally decided to try caps2esc and since I was already there, I also gave space2meta a try. These tools only do what they say. They don't allow any customization, but I ended up concluding what they do is already all the customization my keyboard needed for now, and they have the advantage of always working (even on gui-less ttys)

[loota]

@quicknir Sorry, I don't have the C++ code anymore. And it didn't make it work any better anyway.

[vkargov]

As stated previously by Loota, this seems to be a somewhat well known issue with Mutter/Gnome 3. It seems like multiple utilities are affected by this. Here are a couple of links that describe a possible workaround (can be time consuming to pull off, as you'll need to manually recompile Mutter, and could introduce some new glitches).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1858#note_818548

And here is the corresponding Ubuntu Launchpad issue:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1777708

I will admit I haven't tried it (I have a weird setup which makes pulling up Wayland dependencies that Mutter needs a chore), but I have a good degree of confidence it would help.

Alternatively, you can just switch to another window manager such as Xfce. I can confirm that using Xfce fully eliminates the freeze.

[morenathan]

IDK if this is related but I get substantial pausing when using Xcape under XFCE too actually. It will take a tremendous amount of time to process the second mapped key usage, then unfortunately that causes all my other keyboard shortcuts to "stop" working as well.

What is actually happening is some kind of queuing. I don't know what to do debug this issue. But it essentially means not using Xcape, which is a huge hit. This was never an issue until the last few months.

I'm on ArchLinux under Linux 5.18.10-zen1-1-zen, XFCE4 4.16, Xorg 21.1.4

[phong-phan]

Same behavior on Fedora/GNOME. Caps lock key as single-press == escape (and holding == ctrl) is too slow to be useful. It's especially noticeable in Vim when leaving insert mode and making other keystrokes too fast immediately after.

I'm interested in helping diagnose this.

Hi have you be able to fixed this yet? This is exactly what i'm facing right now....

[sarmong]

@letsgologan Seems like this project is abandoned. A nice alternative is keyd

[phong-phan]

Oh thank you, i will give it a try.