Skip to content

Releases: moneks1106-code/InputLab

InputLab v1.3.0 — Home, what else ran during a mouse run, a fairer mouse score, an interrupt layout you can edit, and a window that fits any display scaling

Choose a tag to compare

@moneks1106-code moneks1106-code released this 25 Oct 20:57

InputLab v1.3.0 — Home, what else ran during a mouse run, a fairer mouse score, an interrupt layout you can edit, and a window that fits any display scaling

The biggest InputLab release so far. It also carries the fixes prepared for 1.2.1, which was never published.

What's new

  • Home: your PC at a glance. The app now opens on a new first tab. The hardware in six tiles; the Windows settings
    that matter for gaming, low latency and InputLab's measurements (power plan, Energy Saver, USB and PCIe power saving,
    Game Mode, Game Bar recording, GPU scheduling, display rate, mouse acceleration, Memory Integrity, the Windows clock,
    a timer test and more), each rating with its source; the BIOS points Windows cannot read, said plainly; your mouse's
    way into the PC, the cores and your last runs. Copy summary puts it on the clipboard without your PC or user name.
    Home only reads.
  • "Before you measure". A short guide when you open a device tab: the BIOS (the developer's recommendation from
    building and testing about 50 PCs, with what each setting costs), Windows (the Gaming Power plan, linked) and how to
    measure on that tab. One tick turns it off; the amber button in the top bar opens it any time.
  • Mouse › Result: "During this run". What else ran on your PC at the same time — CPU, DPC and interrupt time, the
    busiest programs, a program that started during the run (also marked on the interval plot) — and InputLab's own
    share. Read right before and right after the run, never during it; context, never a cause, never part of the score.
    A check with and without it found no visible effect on the measurement.
  • A fairer mouse score (v2) for new runs. A gap where your mouse had nothing to send — it moved too slowly for its
    rate and DPI — no longer counts against the mouse; every other gap counts by its length. A run that moved too slowly
    says so and tells you how fast to move. Runs saved before keep their score and are never ranked against new ones.
  • The report rate and the gaps, named. "8,000 Hz class · 7,995 reports/s · 99.93 % of the slots"; the plot shows the
    1st–99th percentile as a band and the gaps by kind (late, slow movement, other).
  • System › Interrupts: edit the layout yourself. Drag your USB controllers, graphics card, audio and network onto
    the cores, see right away whether the layout follows the rules, write it (the current values are saved first, all
    devices together) and restart after your confirmation; Undo the change puts every device back. Suggest a
    layout
    fills it by the rules with a reason for every device, and a layout check under the core map says how your
    mouse's controller sits today.

Fixed

  • Mouse: "Delivery rate (host)" is the USB rate the reports arrive on (8,000 Hz at 8 kHz), not 1 ÷ the most
    common interval, which on some PCs fell on one of two peaks beside 125 µs (8,403 Hz);
    gaps are counted against that slot. Runs saved before keep their values and scores.
  • Display scaling: nothing is cut off any more. At 125–200 % pages lost parts and text was cut inside its own box.
    Every size now follows the display's scale, a page with too little room scrolls instead of squeezing, dialogs never
    reach past the screen, and the score breakdown scrolls instead of dropping its last rows. At 100 % nothing changes.
  • A mouse at its target rate no longer "differs" from it, USB timing's Export CSV asks where to save, the
    "fix is not active any more" message says what happened, and Interrupts lists an analog keyboard as a keyboard.

Honest limits

Display scaling is laid out and checked for 1920 × 1080, 2560 × 1440 and 1366 × 768 at 100–200 %; on real hardware it
was looked at on one 2560 × 1440 screen at 100 and 150 %. The interrupt layout's write and undo are checked on one PC;
a full cycle — a measurement before, write, restart, a measurement after — has run once, on a PC whose mouse was not
held up before either (no measurable change there). Everything from 1.2
still applies — see the README (Known limitations, Is it safe?).

System requirements

  • Windows 11 or Windows 10, 64-bit (x64); tested on Windows 11 only. Self-contained: the .NET 10 runtime is
    included — unzip the whole folder and run InputLab.exe.
  • Unsigned. On the first run Windows SmartScreen may say "Windows protected your PC" — click More info → Run
    anyway
    . With Smart App Control switched on, Windows blocks the app (there is no "Run anyway").
  • USB timing, the interrupt measurement, the interrupt fix and writing a layout need administrator rights (Windows asks
    each time); everything else runs without.

Verify the download

  • The zip's SHA-256 is on the release page. Check it in PowerShell:
    Get-FileHash .\InputLab-v1.3.0-win-x64.zip -Algorithm SHA256
  • Inside the zip, SHA256SUMS.txt lets you check every file — in git-bash or WSL: sha256sum -c SHA256SUMS.txt
  • BUILDINFO.txt names the source commit, the .NET SDK, the bundled .NET runtime and the pinned obfuscation-tool
    version.
  • SHA-256 of InputLab-v1.3.0-win-x64.zip:
    af491b31010b6cdfcb44c638c7aeeb7bb7e0f96f13324e18b59bb00cc91b9b90

InputLab v1.2.0 — Interrupts: which CPU core holds up your mouse, measured, and a fix you can undo

Choose a tag to compare

@moneks1106-code moneks1106-code released this 17 Oct 18:56

InputLab v1.2.0 — Interrupts: which CPU core holds up your mouse, measured, and a fix you can undo

InputLab 1.2.0 adds System › Interrupts. It shows which CPU core each device's interrupts use, measures during a
10-second mouse test whether a driver holds up your mouse's USB work there, and — only when it does — moves your mouse's
USB controller to another core. Reversible, and measured before and after.

What's new

  • A core map. A tile per CPU core with the devices whose interrupts are expected there: USB controllers (the one your
    mouse hangs on marked), graphics card, audio, network, NVMe and SATA. Read only, no administrator rights.
  • Measure: move your mouse for 10 s. A Mouse Motion test while Windows Performance Recorder (part of Windows)
    records the kernel's interrupts and deferred calls (Windows asks for administrator rights). You get: on which CPU your
    mouse's USB work really ran, how long it waited after its interrupt, which driver it waited behind, and whether that
    driver runs in your monitor's refresh beat. On the two PCs it was developed with, the mouse waited behind the NVIDIA
    graphics driver on CPU 0 — on a 500 Hz monitor in its exact 2000 µs beat.
  • The fix, only after a finding. "Move my mouse's USB controller to CPU n" moves only that controller's interrupts to
    another physical core. You see the change before it happens; the current values are saved first; it takes effect
    after a restart; Undo the change puts them back exactly. A setting made by hand or by another tool can be reset
    to Windows' default the same way.
  • Before and after. After the restart: "Measure after the fix", then both measurements side by side. If nothing
    measurably improved, the tab says so and points to the undo.
  • Fixed: the mouse report speaks about mouse reports (not controller reports), fills its environment rows (VBS,
    Memory Integrity, Energy Saver, Steam, …) and names the numbers behind its problem text.

Honest limits

The measurement and the fix are checked on two PCs (Ryzen 9800X3D, NVIDIA graphics). Each measurement and each change
needs administrator rights; a game with a kernel anti-cheat must be closed (it blocks the recording). A desktop
measurement shows less load than a game, and firmware interrupts (SMIs) are invisible to Windows. The fix needs a
restart and changes only one device's interrupt affinity — no MSI or priority settings, no boot settings. It is
offered only when the measurement finds your mouse held up; sharing CPU 0 alone is common and often harmless. Everything
from 1.1 still applies — see the README (Known limitations, Is it safe?).

System requirements

  • Windows 11 or Windows 10, 64-bit (x64); tested on Windows 11 only. Self-contained: the .NET 10 runtime is
    included — unzip the whole folder and run InputLab.exe.
  • Unsigned. On the first run Windows SmartScreen may say "Windows protected your PC" — click More info → Run
    anyway
    . With Smart App Control switched on, Windows blocks the app (there is no "Run anyway").
  • USB timing, the interrupt measurement and the interrupt fix need administrator rights (Windows asks each time);
    everything else runs without.

Verify the download

  • The zip's SHA-256 is on the release page. Check it in PowerShell:
    Get-FileHash .\InputLab-v1.2.0-win-x64.zip -Algorithm SHA256
  • Inside the zip, SHA256SUMS.txt lets you check every file — in git-bash or WSL: sha256sum -c SHA256SUMS.txt
  • BUILDINFO.txt names the source commit, the .NET SDK, the bundled .NET runtime and the pinned obfuscation-tool
    version.
  • SHA-256 of InputLab-v1.2.0-win-x64.zip:
    2eedb81c29a45f108aa19eae7e45ca7a6de6569456dbea20c3730c752b4f703e

InputLab v1.1.1 — mice named as they name themselves

Choose a tag to compare

@moneks1106-code moneks1106-code released this 16 Oct 22:52

InputLab v1.1.1 — mice named as they name themselves

A patch release with two fixes after the first reports from the field. Everything from 1.1.0 (USB timing) is
unchanged.

Fixed

  • Mice are named as they name themselves. The mouse picker and your saved runs now show the name the mouse
    reports itself (its USB product string, e.g. "Endgame Gear OP1 8k v2 Gaming Mouse"). The vendor table behind it is
    only a fallback, now checked against the USB-IF vendor list. 1.1.0 and earlier called an Endgame Gear mouse
    (vendor 3367) a "Finalmouse", a Finalmouse (361D) a "Pulsar" and a Keychron (3434) a "Wooting", and showed chip makers
    such as SinoWealth as the brand. Saved runs with such a label are corrected when they load; measurements and scores
    are unchanged. Thanks to the users who reported it.
  • USB timing says why Windows refused the trace. The recording always runs with administrator rights, so the old
    message "it needs administrator rights" was wrong. Windows refuses it while a game's kernel anti-cheat is still
    loaded (seen with EA AntiCheat). The tab now says so: close the game, wait a moment and try again. InputLab does not
    try to work around an anti-cheat.

System requirements

  • Windows 11 or Windows 10, 64-bit (x64); tested on Windows 11 only. Self-contained: the .NET 10 runtime is
    included — unzip the whole folder and run InputLab.exe.
  • Unsigned. On the first run Windows SmartScreen may say "Windows protected your PC" — click More info → Run
    anyway
    . With Smart App Control switched on, Windows blocks the app (there is no "Run anyway").
  • USB timing needs administrator rights for each recorded test (Windows asks); everything else runs without.

Verify the download

  • The zip's SHA-256 is on the release page. Check it in PowerShell:
    Get-FileHash .\InputLab-v1.1.1-win-x64.zip -Algorithm SHA256
  • Inside the zip, SHA256SUMS.txt lets you check every file — in git-bash or WSL: sha256sum -c SHA256SUMS.txt
  • BUILDINFO.txt names the source commit, the .NET SDK, the bundled .NET runtime and the pinned obfuscation-tool
    version.
  • SHA-256 of InputLab-v1.1.1-win-x64.zip:
    60f73282e40677e48b2f04377d37531dec67af5d29d380877f4e60ff1a3eeb22

InputLab v1.1.0 — USB timing: your mouse at the USB controller and at the app, on one clock

Choose a tag to compare

@moneks1106-code moneks1106-code released this 16 Oct 20:39

InputLab v1.1.0 — USB timing: your mouse at the USB controller and at the app, on one clock

InputLab 1.1.0 adds USB timing to the Mouse level. On its USB timing tab, press "Start USB Timing" and see every report twice: when
Windows' USB stack received it, and when it reached InputLab — the way a game gets it. Every hiccup is marked where it
started: before Windows (the mouse, its radio or its sensor) or inside your PC.

What's new

  • USB timing (Lab). On the Mouse level's new USB timing tab, the start button reads Start USB Timing: the
    quick test set in the setup row, and it also records the USB stack's own completion events (Event Tracing for Windows; Windows asks
    for administrator rights for each such test). On the other tabs Start Quick Test stays without it, so your
    score is measured undisturbed. Afterwards every report is paired with its USB completion — on the
    developer's 8000 Hz receiver, every single one.
  • One clock, three lanes. The time between reports at the USB controller, how long Windows took to hand each report
    to the app, and the time between reports at InputLab. Each lane centres its typical value, the numbers follow the
    zoom, and single reports appear as dots when you zoom in. Zoom buttons (whole run down to 1 ms), wheel zoom down to
    half a millisecond, Shift+drag to zoom to a range, an overview strip, hover for one report's numbers, CSV export.
  • The chain in one picture: your mouse › USB controller › InputLab, with the numbers on each link
    ("every 125 µs", "hand-over 50 µs typical, 99 % within 95 µs").
  • A measurement check. The recording makes Windows do extra work on the path InputLab measures. So every run with
    it is compared with your latest runs of the same mouse and test without it, and the tab says plainly whether the
    recording changed anything. Such runs are marked and kept apart in Compare. The trace asks Windows only for the events
    it reads, which halves its extra work.
  • Fixed: mouse sessions now name their real capture path (Raw Input mouse); 1.0.0 labelled them with the
    controller's model. Older runs show the corrected label; measurements and scores are unchanged.

Thanks

A big thank-you to XBAB-Tech for pointing out how much ETW-based timing adds to a
mouse test. Their MousePlotter pairs the mouse's USB completions from
Event Tracing for Windows with Raw Input, and that is what got InputLab's USB timing started. InputLab's
implementation is its own; no code was taken.

Honest limits

USB timing is checked with one wireless mouse on an 8000 Hz receiver. Its USB-side times come from Windows' USB stack,
not the USB cable, and it is not a click-to-screen latency. It covers USB devices on Windows' current USB stack (not
Bluetooth, not older EHCI controllers). It never changes the delivery score. Everything from 1.0.0 still applies — see
the README (Tested hardware, Known limitations, Is it safe?).

System requirements

  • Windows 11 or Windows 10, 64-bit (x64); tested on Windows 11 only. Self-contained: the .NET 10 runtime is
    included — unzip the whole folder and run InputLab.exe.
  • Unsigned. On the first run Windows SmartScreen may say "Windows protected your PC" — click More info → Run
    anyway
    . With Smart App Control switched on, Windows blocks the app (there is no "Run anyway").
  • USB timing needs administrator rights for each recorded test (Windows asks); everything else runs without.

Verify the download

  • SHA-256 of InputLab-v1.1.0-win-x64.zip:
    616b2bf26e7414fee9b028ad6dacb264cb98458841e80a7b14232cc8f4c2c461

  • The zip's SHA-256 is on the release page. Check it in PowerShell:
    Get-FileHash .\InputLab-v1.1.0-win-x64.zip -Algorithm SHA256

  • Inside the zip, SHA256SUMS.txt lets you check every file — in git-bash or WSL: sha256sum -c SHA256SUMS.txt

  • BUILDINFO.txt names the source commit, the .NET SDK, the bundled .NET runtime and the pinned obfuscation-tool
    version.

InputLab v1.0.0 — mouse, controller, USB map, power and the wireless doctor in one app

Choose a tag to compare

@moneks1106-code moneks1106-code released this 16 Oct 12:09

InputLab v1.0.0 — mouse, controller, USB map, power and the wireless doctor in one app

The first InputLab release. InputLab merges AleksMouseTester and AleksControllerTester into one free Windows
tool: it measures how evenly your mouse's and your controller's reports arrive in Windows, shows where every USB
device hangs and what is worth checking, explains the power settings that are said to slow input (and changes
them on a click, with Restore), and helps find why a wireless mouse stutters.

What's in it

  • Controller — everything AleksControllerTester 1.0.3 had: the live view, the quick tests Stick Motion,
    Idle Drift, Button Burst, Trigger Sweep and Stick Range, Advanced / Lab, Timeline and Compare.
  • Mouse — a live view, Scan (move it), the quick tests Mouse Motion (the delivery score), Mouse
    Idle
    and Mouse Click Burst, with Result, Timeline (every interval, a button lane) and Compare.
  • System › USB map — every USB controller, hub, socket and device with its link speed and polling interval.
    One sentence says how things stand; a list says what is worth checking and why, with its source. No score. Re-plug
    a device and the map reads itself again and names what moved. Tell it where a socket sits and what is next to it,
    and the radio checks can use that.
  • System › Power — USB selective suspend, USB 3 and PCI Express link power management, processor states, core
    parking, Energy Saver and whether Windows may switch your input devices off: what each does, what is actually
    known, where to change it — or one click, with the original saved first and Restore.
  • Wireless — pick your receiver: its way into the PC, two questions only you can answer, the Wi-Fi band and the
    2.4 GHz crowd around you, active Bluetooth devices, the dropout pattern of your last Mouse Motion run, and a
    before / after of two runs, even across a socket change.
  • Import — "Import from AleksMouseTester" and "Import from AleksControllerTester" on the Compare pages copy your
    old runs in. The old files are only read.
  • ♥ Support at the top right of every level, as before: voluntary, nothing is unlocked by it.

Honest by design

InputLab reports Windows host input-delivery timing — not the device's internal scan rate or USB polling, not
click-to-screen latency. The USB map and the power view give no score: they say what is fine, what is worth
checking and what cannot be told. A change counts when the quick test before and after shows it.

Tested hardware and limits

One controller (GameSir G7 HE, USB cable, Xbox-compatible HID + XInput) and one wireless mouse on an 8000 Hz
receiver, on one Windows 11 PC with an AMD processor. The Wi-Fi part of the Wireless level has not yet been
verified on a PC with Wi-Fi; Bluetooth devices, more controllers and more mice are not tested yet. Since Windows 11
24H2 the Wi-Fi list needs location access for desktop apps (the page says where to switch it on). The full list is
in the README (Tested hardware, Known limitations, Is it safe?).

System requirements

  • Windows 11 or Windows 10, 64-bit (x64); tested on Windows 11 only. Self-contained: the .NET 10 runtime is
    included — unzip the whole folder and run InputLab.exe.
  • Unsigned. On the first run Windows SmartScreen may say "Windows protected your PC" — click More info → Run
    anyway
    . With Smart App Control switched on, Windows blocks the app (there is no "Run anyway").
  • Your data stays in Documents\InputLab; AleksMouseTester and AleksControllerTester keep running side by side.

Verify the download

  • SHA-256 of InputLab-v1.0.0-win-x64.zip:
    1d9b8a7cb7994d7a3eac1209d686968ecf93b4b1a032afc8f103f75eb86b5b50

  • The zip's SHA-256 is on the release page. Check it in PowerShell:
    Get-FileHash .\InputLab-v1.0.0-win-x64.zip -Algorithm SHA256

  • Inside the zip, SHA256SUMS.txt lets you check every file — in git-bash or WSL: sha256sum -c SHA256SUMS.txt

  • BUILDINFO.txt names the source commit, the .NET SDK, the bundled .NET runtime and the pinned obfuscation-tool
    version.