AFK BUG

[Omarion1st]

• I am on the latest ActivityWatch version.
• I have searched the issues of this repo and believe that this is not a duplicate.

• ** Win 11 build 26200 **:
• ** v0.13.2 **:

Describe the bug

<AFK Time Not Measured. -->

To Reproduce

Expected behavior

<An afk for almost 1 hour but wasn't there -->

Documentation

all in the box should be afk

I set the afk to be measured after 1 min of no activity

[github-actions]

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! 🙏

[0xbrayo]

Were you using a gaming controller?

[TimeToBuildBob]

@0xbrayo's intuition is right — if a gaming controller is connected, it's very likely the cause.

Why this happens:

aw-watcher-afk on Windows uses GetLastInputInfo() from the Win32 API to track the last user input. The catch: GetLastInputInfo() counts input from any HID device — keyboard, mouse, and USB/Bluetooth gaming controllers alike. Controllers commonly generate continuous low-level input events even when not actively used:

• Analog stick deadzone drift — even a stationary stick produces tiny axis values that register as input
• Wireless adapter keepalive packets — some USB dongles generate HID events just from staying paired
• Background polling artifacts — certain controllers report button/axis state every poll, resetting the idle timer continuously

The practical result: the idle timer never reaches your 1-minute threshold, so AFK is never declared.

Workaround:

1. Disconnect the controller (USB unplug or Bluetooth disconnect) when you're not actively gaming
2. Confirm AFK detection works normally without the controller connected

Long-term fix:

The proper fix in aw-watcher-afk would be to filter GetLastInputInfo() by device type (distinguishing keyboard/mouse HID from gamepad HID), or use RegisterRawInputDevices() with a device-class filter so only pointer/keyboard events reset the idle timer. There's prior art for this in screen-saver suppression code — game launchers like Steam suppress screensavers via SystemParametersInfo(SPI_SETSCREENSAVERRUNNING) rather than generating synthetic input, which is exactly the problem here.

If you confirm the controller is the cause, a follow-up issue in aw-watcher-afk specifically about gamepad HID filtering would be the right place to track the fix.