Mouse Sensitivity issue in games using autokey

[VenusFallen]

AutoKey is a Xorg application and will not function in a Wayland session. Do you use Xorg (X11) or Wayland?

Xorg

Has this issue already been reported?

• I have searched through the existing issues.

Is this a question rather than an issue?

• This is not a question.

What type of issue is this?

Bug

Choose one or more terms that describe this issue:

• autokey triggers
• autokey-gtk
• autokey-qt
• beta
• bug
• critical
• development
• documentation
• enhancement
• installation/configuration
• phrase expansion
• scripting
• technical debt
• user interface

Other terms that describe this issue if not provided above:

gaming

Which Linux distribution did you use?

Garuda Linux Zen Kernel 6.4.12-zen1-1-zen

Which AutoKey GUI did you use?

Qt

Which AutoKey version did you use?

No response

How did you install AutoKey?

Autokey-Qt 0/96.0-4

Can you briefly describe the issue?

I am a Windows refugee that moved over to Linux full time about two to three years ago, having dual booted for years before that.

Only recently did I decide that I missed my AHK scripts I used for automation and gaming.

Making a few scripts to duplicate my AHK scripts, I noticed that while playing a game called Elder Scrolls Online (ESO), if I have script with an active hotkey (even if the script is empty/commented out), my mouse sensitivity is set to max while the hotkey is pressed down.

I have attempted to use different functions regarding keyboard and mouse functions, but have had no success in clearing the issue.

I have gone to both the Glitter and Google groups before submitting a bug, and was advised to post here.

Can the issue be reproduced?

Always

What are the steps to reproduce the issue?

1. Create a new script with the Qt version of Autokey
2. Assign a hotkey to said script
3. Go into either New World or ESO
4. Hold hotkey and move the mouse

What should have happened?

I expected the script to fire without changing my mouse sensitivity

What actually happened?

When triggering the hotkey assigned while the Autokey Qt window is open or in the system tray, mouse sensitivity is set to max

Do you have screenshots?

No response

Can you provide the output of the AutoKey command?

2023-08-31 10:26:59,030 INFO - autokey.qtapp - Initialising application
2023-08-31 10:26:59,039 INFO - autokey.qtapp - Initialise global hotkeys
2023-08-31 10:26:59,039 INFO - autokey.configmanager.configmanager - Loading config from existing file: /home/venusfallen/.config/autokey/autokey.json
2023-08-31 10:26:59,039 INFO - autokey.configmanager.version_upgrading - Checking if upgrade is needed from version 0.96.0
2023-08-31 10:26:59,040 INFO - autokey.configmanager.configmanager - Configuration changed - rebuilding in-memory structures
2023-08-31 10:26:59,040 INFO - autokey.configmanager.configmanager - Successfully loaded configuration
2023-08-31 10:26:59,040 INFO - autokey.service - Starting service
2023-08-31 10:26:59,074 INFO - autokey.iomediator.iomediator - Created IoMediator instance, current interface is: <XRecordInterface(XInterface-thread, initial daemon)>
X protocol error:
<class 'Xlib.error.BadAccess'>: code = 10, resource_id = 1733, sequence_number = 32, major_opcode = 33, minor_opcode = 0
X protocol error:
<class 'Xlib.error.BadAccess'>: code = 10, resource_id = 1733, sequence_number = 33, major_opcode = 33, minor_opcode = 0
X protocol error:
<class 'Xlib.error.BadAccess'>: code = 10, resource_id = 1733, sequence_number = 34, major_opcode = 33, minor_opcode = 0
X protocol error:
<class 'Xlib.error.BadAccess'>: code = 10, resource_id = 1733, sequence_number = 35, major_opcode = 33, minor_opcode = 0
2023-08-31 10:26:59,079 INFO - autokey.interface - XRecord interface thread starting
2023-08-31 10:26:59,079 INFO - autokey.service - Service now marked as running
2023-08-31 10:26:59,080 INFO - autokey.qtui.notifier - Creating static context menu actions.
2023-08-31 10:26:59,081 INFO - autokey.qtui.notifier - Rebuilding model item actions, adding all items marked for access through the tray icon.
2023-08-31 10:26:59,083 INFO - autokey.qtui.notifier - System tray icon notifier created.

Anything else?

No response

[josephj11]

A few initial comments:

Since the current version of AutoKey does not recognize mouse events as part of triggers, there's no reason (with respect to AutoKey) to do what you are doing. Am I missing something here?

The current version of AutoKey only detects hotkey presses. It does not detect or react to a hotkey (or any other key) being held down. You can write scripts to interact with such behaviors, but they have to be triggered by something else.

What happens if you do the same thing when AutoKey is not running at all?

Depending on your desktop environment (DTE) settings, holding down one or more keys for longer than a configurable delay may cause keyboard autorepeat to kick in and start emitting multiple keypress events. This is usually enabled by default.

Those opaque Bad access error messages are really hard to track down. One thing that seems to cause them is when AutoKey attempts to claim access to (grab) a hotkey combination that is already in use by something else. In particular, newer versions of KDE grab myriads of hotkey combinations for excessively obscure functions.

Unfortunately, hotkeys are set by separate applications and AFAIK, there are no utilities to help figure out which hotkeys are assigned to what, so you have to search manually.

[VenusFallen]

Seems you are missing something. Maybe I didn't clarify. I'm not using AutoKey to move the mouse, only click the left mouse button. However, that seems to be immaterial to what is happening, as a blank script with a hotkey set still affects mouse speed while the hotkey is being used.

The issue here, is that in specific programs the hotkey itself is what is causing the issue, not what is in the script.

To expand on KDE, the hotkeys being used are not being grabbed by the DE, as I ensured they arent in use. I have also set hotkeys for AutoKey that are both in use and not in use by specific applications (in this case, some specific games), and the results are the same.

Is there an output I can record and present?

[josephj11]

The output you already provided looks like it came from an AutoKey trace. That's our only debugging log/information.
If that's not trace output, you can run one and recreate the issue.

The only thing I can think of to try would be to go into AutoKey settings and deselect Enable AutoKey monitoring. That would tell us if AutoKey is actively involved in the problem or if merely having it running is enough to break things. I'm not sure how this would help, but it's one more clue.

What I'm still not getting is why you would "hold" a hotkey for any reason. AutoKey is designed to detect and respond when they are momentarily pressed and released. If doing so causes keyboard autorepeat to kick in, that would probably launch an additional AutoKey thread for each detected keypress and that would cause system load and memory utilization problems. I'm also not sure how AutoKey works internally. I would guess that a hotkey is detected upon a key release event, but I don't know what, if anything, is going on between the key press event and the key release event. If doing something like this was taxing your system, I would expect things to slow down and be less responsive, not go faster.

[VenusFallen]

So i figured Id take a video to better show what it is I'm trying to explain.
https://www.youtube.com/watch?v=ukrIfYpPDkY&ab_channel=VenusFallen

As of this comment, the video still has 20 minutes on HD rendering, but itll likely be done by the time you see it.

I demonstrate the typical mouse speed, the hotkey functioning as it should in terms of the script, and then wwhat happens when the hotkey is held. I then comment out the script, and repeat. Notice how it has nothing to do with what is in the script, but the fact that a hotkey is being used.

I have now also tested on both X11 and Wayland with the same result.

While you are correct, Im not intending to hold the hotkey down by any means, a simple quick click will still send the cursor into a quick frenzy. Im holding it here for the demonstration purposes.

Turning Monitoring off, autokey no longer works inside some applications.

[josephj11]

OK. This is going to have to wait for developer attention.

IIUC, things are fine until you press the hotkey. Once you do so, the mouse becomes hyper sensitive.

It looks like the problem persists after you release the hotkey. Does it ever stop without terminating AutoKey and restarting it?

From the video, it looks like you will kill your opponent before he even knows you are there! LOL

Seriously though, we currently have only one part time developer, so it may be some time before this gets looked at.

You might want to try installing the GTK front end. The code base is very different, so it might not have this problem. This would also tell us whether this is a front end or core issue. I know Arch makes it complicated to do that.

[VenusFallen]

It only exists while I have the hot key pressed. In the video I held it down for demonstration, however even if I just press and release, it will jolt the mouse very quickly in the direction it's moving.

Illl give the GTK version a go

[VenusFallen]

Just to report back, the GTK version has the same issues for me

[josephj11]

I think we have this issue clarified now.

We have to wait until a dev looks at it.

[VenusFallen]

Thats fantastic, thank you!