You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[x ] I have searched the issues of this repo and believe that this is not a duplicate.
Windows 26H2:
0.13.2
Describe the bug
so when i play a game on a controller the afk watcher thinks that there is input all the time and it makes the time i was actually afk count as regular time
To Reproduce
Expected behavior
i want the afk watcher to not take a connected bluetooth controller as input
Documentation
Additional context
if you cannot fix it then i understand but it would be amazing if you guys did it
Hi there!
As you're new to this repo, please make sure you've used an appropriate issue template and searched for duplicates (it helps us focus on actual development!). We'd also like to suggest that you read our contribution guidelines and our code of conduct.
Thanks a bunch for opening your first issue! 🙏
Windows AFK detection uses the Windows last-input counter. We need to see what resets it before choosing a controller-specific fix.
I opened ActivityWatch/aw-watcher-afk#90 with an opt-in, read-only diagnostic and comparison instructions. It reports idle time and aggregate mouse/keyboard injection flags, without recording keys, text or cursor coordinates. It does not change your AFK settings or suppress input.
Could you provide:
Controller model and any mapper/virtual-controller software (and versions).
Actual Windows version/build from winver.
Whether idle time increases during two untouched 120-second runs: controller disconnected, then connected with the same game/mapper state.
If you have Python 3 installed, download the script linked in the instructions and run py -3 .\windows_input_diagnostic.py --duration 120. Small output excerpts around idle resets are enough; review them before sharing. Please check that harmless mouse/key input appears near the start and end of each run.
Local unit tests pass, but I have not run the native hooks on Windows or reproduced your Bluetooth-controller behavior. Injected events can also come from accessibility/remote-control tools, and unflagged events are not necessarily physical input. No production filter is proposed yet.
Activity
github-actions commentedon Oct 3, 2026
Hi there!
As you're new to this repo, please make sure you've used an appropriate issue template and searched for duplicates (it helps us focus on actual development!). We'd also like to suggest that you read our contribution guidelines and our code of conduct.
Thanks a bunch for opening your first issue! 🙏
TimeToBuildBob commentedon Oct 3, 2026
Windows AFK detection uses the Windows last-input counter. We need to see what resets it before choosing a controller-specific fix.
I opened ActivityWatch/aw-watcher-afk#90 with an opt-in, read-only diagnostic and comparison instructions. It reports idle time and aggregate mouse/keyboard injection flags, without recording keys, text or cursor coordinates. It does not change your AFK settings or suppress input.
Could you provide:
If you have Python 3 installed, download the script linked in the instructions and run
py -3 .\windows_input_diagnostic.py --duration 120. Small output excerpts around idle resets are enough; review them before sharing. Please check that harmless mouse/key input appears near the start and end of each run.Local unit tests pass, but I have not run the native hooks on Windows or reproduced your Bluetooth-controller behavior. Injected events can also come from accessibility/remote-control tools, and unflagged events are not necessarily physical input. No production filter is proposed yet.