v0.3.2

One fix. Download GloriousAutoPollingRate.exe below and drop it over your existing copy.

The tray icon survives an Explorer restart

If Explorer crashed or you restarted it, the icon vanished and never came back. The app carried on running and carried on switching your polling rate, just with no icon and no way to reach the menu short of ending it in Task Manager.

Explorer announces a rebuilt tray by broadcasting a message called TaskbarCreated, which is the cue to add the icon again. That was never handled here, and not by oversight: broadcasts only reach top level windows, and this was a message only window, which is the natural choice for a process with no interface. The window is now an ordinary top level window that simply never shows itself, so the message arrives and the icon comes back.

Verified by restarting Explorer against both builds. On v0.3.1 the icon is gone afterwards. On this one it is still there, with the correct tooltip and the right colour for whichever rate is live.

Nothing else changed. If your Explorer never crashes, v0.3.1 behaves identically and there is no need to hurry.

v0.3.1

A bug fix release. Download GloriousAutoPollingRate.exe below, drop it next to your existing copy, and run it.

Notifications only announce one thing now

Opening the tray menu and choosing Reload program list used to fire two notifications back to back, and again on every click. A notification now means one thing: a program on your list opened and the active rate went on. Dropping back to the inactive rate is silent, and nothing you do from the menu yourself notifies, since you already know you did it.

Three ways a notification could repeat or go missing were fixed underneath that:

• A failed process scan used to be read as "nothing is running", which would drop your rate mid game and make the recovery a tick later look like a fresh start, notifying again. A scan that cannot tell now holds the previous answer.
• The process buffer was a fixed size and a full buffer was taken at face value, so on a machine with a very large number of processes a watched game could flicker in and out. It grows instead.
• A notification is no longer lost if the write to the mouse fails at the moment a game starts. It is delivered by the retry that succeeds.

The tray menu gives its memory back

Opening the menu loads the Windows shell libraries, and nothing released them afterwards, so a single right click left the process elevated for the rest of the session. On an install that had been up under an hour, that was about 19 MB. Measured across a real open and close now: 1280 KB before, 4436 KB with the menu on screen, 1388 KB once it closes.

A byte order mark no longer breaks the first program in your list

If your editor saves processlist.cfg as "UTF-8 with BOM", the invisible mark stuck to the first line and that program silently never matched, with no error to explain it. Leading marks are now ignored in all three config files.

Also

The README has a Credits section for RazerAutoPollingRate, which inspired this.

v0.3.0

About 130 times less work per tick, and a footprint table you can trust.

The scan got much cheaper

The tool checks every two seconds whether a listed program is running. That check used to be a CreateToolhelp32Snapshot walk, which builds a snapshot of every process before anything is compared, so stopping early on a match barely helped. It cost about 3.6 ms a call, and got worse under exactly the conditions that matter: measured during a Counter Strike 2 session it rose to 5.6 ms typical and 7.2 ms worst.

It now asks EnumProcesses for the process ids, about 20 us, and remembers each id's executable name, because that never changes. A steady state tick is one syscall plus a few hash lookups.

Approach	Typical	Worst
Toolhelp snapshot, before	3603 us	6695 us
EnumProcesses plus a name cache, now	27 us	67 us

In the running app that took process CPU from 0.14 percent of one core to 0.01 percent, and the working set now stays under 1 MB instead of growing to 5.9 MB.

The footprint table was wrong, and now is not

Every row that mattered has been remeasured. CPU was listed as 0 percent when it was measurable. The working set was listed as under 1 MB, which was true only for an instant after the startup trim. The executable was listed at 0.46 MB when it was 0.50 MB. The README now shows real numbers and says how they were taken, including the fact that Windows accounts process CPU in steps of about 15.6 ms, so per scan figures come from timing the function directly rather than from division.

Model O2 Pro 4K

Glorious CORE's own device table lists the Model O2 Pro 4K as the same kind of device as the D2 Pro 4K, on the same vendor collection, with the same feature flags, at receiver id 258A:2035 against the D2 Pro's 258A:2036. Since that D2 Pro id matches what was captured for this tool independently, the rest of the row is worth trusting.

If you have one, a protocol.toml next to the executable containing one line should do it:

pid = 0x2035

Every field you leave out keeps its built in value, so the captured rate commands carry over. This has not been tested on real hardware. An issue saying whether it worked either way would be welcome.

Fixes

• --list produced no output at all. The single instance guard returned before the flag was handled, so it did nothing whenever the tray copy was running, which is the normal case. It now runs first and writes devices.txt next to the executable, since this is a windowed binary with no console and stdout goes nowhere.
• CAPTURE.md claimed a protocol.toml replaces the built in protocol entirely. It does not, and believing it would have cost a Model O2 Pro owner a pointless capture session.
• Added the tray icon in both states and the change notification to the README images.

Upgrading

Replace the exe. Nothing about your processlist.cfg or settings.toml changes.

v0.2.0

Simpler. Two rates, a list of programs, nothing else to configure.

The rule

If any program on your list is running, you get the active rate. Otherwise the inactive rate. Running, not focused, so alt tabbing out of a game mid match keeps the rate high.

What changed

• Both rates come from the tray menu. Right click, pick an active and an inactive rate. Applied instantly and remembered.
• Programs live in processlist.cfg. One .exe per line, # for comments. Choose Edit program list from the tray to open it.
• Starts with Windows by default, through the per user Run key. No administrator rights, no installer. Turn it off from the tray and nothing is left behind.
• Focus mode and per program rates are gone. They were the complicated part and the single rule above replaces them.
• The protocol moved into the binary. Nothing about HID reports appears in a file you would normally open. It is written down in docs/PROTOCOL.md, and a protocol.toml still overrides it for a different mouse.

Upgrading from v0.1.0

Replace the exe. Your old config.toml is no longer read and can be deleted. Rates are now in the tray menu, programs in processlist.cfg, and both files are created for you on first run.

Verified

Captured the USB traffic while driving a full cycle. With notepad.exe listed, the tool sent 500 Hz at startup, 4000 Hz when Notepad opened, and 500 Hz again when it closed.

v0.1.0

Per application polling rate switching for the Glorious Model D2 Pro 4K, as a tiny Windows tray tool.

Plug and play on the Model D2 Pro 4K

The per rate HID reports are captured and included, so there is no capture step before first use. Download the exe, run it, then edit the config.toml that appears next to it to list your programs.

Supported rates are 125, 250, 500, 1000, 2000 and 4000 Hz. The 4K dongle does not offer 8000. Other Glorious models need their own capture, see docs/CAPTURE.md.

What it does

• Follows the focused window, or any running process, and sets the mouse polling rate to match.
• Drops to a low rate when nothing matches, to save battery.
• Optional tray notification on each change.

Footprint

• 0.46 MB executable, no installer, no runtime, no C dependencies.
• About 1.7 MB of private memory, working set trimmed under 1 MB.
• 0 percent CPU while idle. Focus mode waits on Windows events rather than polling.

Built in Rust against the Win32 and HID APIs directly.