Unresponsiveness and stuttering when used with kdotool on Plasma

[pintassilgo]

It's a bit hard to describe, but today my browser (Firefox) froze a bit while I was doing regular things such as holding right-click and moving up/down, that's a gesture I have configured in extension to scroll to the top or to the bottom of the page. Sometimes it wasn't as strong as a freezing, but at least noticeable frame drops. On stopping makima systemd unit, everything was fixed, so there's clearly an issue here.

Now, one more issue. I was trying Space Cadet 3D Pinball, a classic game bundled with some old versions of Microsoft Windows, available in Linux as Flatpak. The key to use left flipper is Z, and I noticed it wasn't working when I tapped the key quickly, I need to hold it a bit for the flipper to work. Again, as I suspected, stopping makima fixed the issue.

So I tried previous versions to find which one caused the regression. I can say v0.8.8 is the last good one. v0.9.0 is affected.

[cyber-sushi]

Hello!

I'm unable to replicate this one, my CPU usage on Makima is usually around 0.0% to 0.1%, how high is it on your computer?

The key to use left flipper is Z

Is your Z key remapped or is it just the default event? How many devices did you map? What device type are they? Have you checked if this is related to the integration with kdotool on Plasma? For example, if you just remove the kdotool executable from PATH (and thus Makima will work without querying kdotool) do you still have this issue?

[pintassilgo]

Sorry for my imprecise wording, I didn't effectively measured CPU usage, the actual issue from my first paragraph is the noticeable slowness/freezing when I do that common task with the mouse. I supposed it's related to high CPU usage, but who knows.

Is your Z key remapped or is it just the default event? How many devices did you map? What device type are they?

I have a simple remap for mouse and other for keyboard. Not related to Z key. Here they are:

Kb:

[remap]
KEY_CAPSLOCK = ["KEY_ENTER"]
KEY_LEFTSHIFT-KEY_CAPSLOCK = ["KEY_CAPSLOCK"]

Mouse:

[remap]
BTN_EXTRA-SCROLL_WHEEL_UP = ["KEY_VOLUMEUP"]
BTN_EXTRA-SCROLL_WHEEL_DOWN = ["KEY_VOLUMEDOWN"]
BTN_SIDE-SCROLL_WHEEL_UP = ["KEY_LEFTCTRL", "KEY_LEFTSHIFT", "KEY_TAB"]
BTN_SIDE-SCROLL_WHEEL_DOWN = ["KEY_LEFTCTRL", "KEY_TAB"]

Have you checked if this is related to the integration with kdotool on Plasma? For example, if you just remove the kdotool executable from PATH (and thus Makima will work without querying kdotool) do you still have this issue?

Good catch. Yes, it's related. If I remove kdotool from PATH and restart makima, there's no issue. And I'm not even using app-specific remapping, I just tested it the other day.

[pintassilgo]

By the way, I just confirmed this "kdotool integration" is responsible for what we discussed yesterday. Without kdotool, most of my wheel movements aren't recognized when I try to quickly change volume by a lot, the same limitation as the other remapping tools I tried.

[cyber-sushi]

Without kdotool, most of my wheel movements aren't recognized

This is really odd, are you testing with the 0.9.2 Makima executable?

When kdotool is not present, does Makima print "Running on KDE but kdotool doesn't seem to be installed. Won't be able to change bindings according to the active window." in systemctl status makima? (this only happens on 0.9.x)

Also, it seems like I'll have to take a field trip on my KDE live ISOs to understand why kdotool is doing weird stuff

[pintassilgo]

This is really odd, are you testing with the 0.9.2 Makima executable?

Yes. But just to make it clear, I don't usually have issues with wheel. It's only that specific scenario I said yesterday. If I hold forward button and do one complete turn of the wheel very quickly, volume only changes by 15% or something like that. As I said, I always guessed this is a limitation of the KDE Plasma widget which handles the volume key. Because I don't have this issue in other uses of the wheel. For instance, backward button + turning wheel very fast to switch tabs works perfectly fine. The wheel alone to scroll the page is also OK...

For some reason, the kdotool integration fixed this slowness in changing volume, allowing me to change it quickly. But as I found out today, this came with unwanted regressions - this issue here.

does Makima print

Yes, it does.

[cyber-sushi]

Okay, thank you a lot for the detailed info

I'll se if I can find a solution and maybe I'll ask the KDE devs if they can implement a D-Bus API to communicate with KWin in a more effective way, because a lot of tools could benefit from that

I'm also editing the title of the issue in case someone happens to pass by

[pintassilgo]

OK, thanks.

When kdotool is not present, does Makima print "Running on KDE but kdotool doesn't seem to be installed. Won't be able to change bindings according to the active window." in systemctl status makima? (this only happens on 0.9.x)

By the way, I just checked again what we talked about the other day. I placed kdotool in ~/local/bin, then kdotool is recognized in Konsole because that directory is in PATH. But even after restarting makima, status still prints kdotool doesn't seem to be installed. So the systemd unit can't get the whole PATH, only the root PATH or something like that, so I'd need to place kdotool in /usr/bin/ if I indent to use it with makima.

[cyber-sushi]

Oh right, yes, I did look into that

Basically, when system services are initialized, they only have a small batch of env variables, and their PATH only contains the default PATH, which doesn't include user directories

Makima automatically grabs your user variables from systemd --user show-environment and dumps them into the service, however I had specifically made it so it doesn't overwrite variables that are already present to avoid messing up the variables that the user might have set through Environment=... in the systemd unit, which means that it also does not overwrite the default PATH that is already present

A solution would be to special-case PATH and make it so it's chained with the already present PATH, I think this would be the cleanest way to handle it

[pintassilgo]

Thanks for the explanation.

Just adding that now, after rebooting my PC, changing volume is fast again even without kdotool. So I was wrong in this comment.