InputLab v1.4.0 — a driver check for your mouse's worst gaps, every driver between your mouse and Windows, the interrupt measurement as pictures, and a fairer mouse score for fast mice

InputLab v1.4.0 — a driver check for your mouse's worst gaps, every driver between your mouse and Windows, the interrupt measurement as pictures, and a fairer mouse score for fast mice

What users and the developer found since 1.3.0, measured and fixed.

What's new

• Driver check: what ran on the core of your mouse's USB work in its gaps. System › Interrupts › Measure now
  also follows every gap of the run (over two report periods, as the run counts its gaps: 250 µs at 8 kHz) back through
  the report that closed it — the mouse's USB interrupt, Windows' USB work (its DPC), the arrival at InputLab — and
  splits the gap over three stages: no USB interrupt came (the mouse or its receiver sent nothing, before Windows),
  the USB work waited behind another driver on the same core, or Windows passed the report on late. A driver is named
  only when its own time (interrupts nested inside it subtracted) explains the gap or the wait; a wait with nothing
  recorded says so. The card names the driver's device and installed version (NVIDIA's as NVIDIA numbers it), where
  its interrupts are set and who set them, a fix only where the maker or Microsoft documents one, and the worst gap
  gets its own sentence. Move … off CPU n opens the layout editor with that device on the quietest free core of
  the same measurement (on an Intel hybrid CPU a P-core for a graphics card and an E-core first for the rest, on a
  dual-CCD X3D the CCD without the V-Cache first); nothing is written before Write. The next measurement of the
  same mouse compares the gaps held behind a driver and the worst gap with this one — after a driver update as after
  a layout. Measured as Windows handles the reports, never as an input-lag number: a driver "coincided" with a gap
  and could have delayed each report by at most the time it ran there. Checked against four real recordings: the
  NVIDIA driver on the mouse's core on two PCs, a LAN driver sharing that core but running 18 µs of its own, and a
  677 µs wait that nothing recorded explains.
• Where each device's interrupt setting came from. The Interrupts table and the driver check say whether a device
  runs on Windows' default or a setting of its own, and whose: InputLab's (with the date of its change), its
  driver's (Windows' own NVMe driver sets "spread" and high priority itself), or another program's (with the date the
  setting was written). For a network adapter the card adds receive-side scaling and interrupt moderation, which place
  its work on cores the table does not show.
• Drivers on Home. A new group, on the right under the cores (the last runs moved under the BIOS card, so both
  columns end about together), lists the last measured driver check — the only rating there: "No driver held up
  your mouse", or the driver that did, with a click to System › Interrupts — then the graphics, network and Wi-Fi
  drivers and the USB controllers' as installed (provider, version — NVIDIA's as NVIDIA numbers it, also on the graphics
  tile — and date), and the network adapters' power saving as their drivers have it set (Energy-Efficient Ethernet,
  selective suspend, the vendors' own switches such as Green Ethernet, whether Windows may turn the adapter off).
  InputLab does not look up whether a newer driver exists — it has no network access — and a version or a power
  setting alone says nothing about the mouse, so these lines carry no colour; the power-saving line says where to
  switch a setting off, and to measure before and after.
• Your mouse's path. Home › Drivers and the driver check name every driver your mouse's reports pass through,
  from Windows' mouse driver down to the USB controller (mouclass › mouhid › HidUsb › USBHUB3 › USBXHCI on most
  PCs), read from each device's driver stack. A driver another program put there — a USB capture filter such as
  USBPcap (often installed with Wireshark), a mouse tool, a maker's software — is named with its file's product and
  version and the program it came with: it sees every report, and its time counts inside Windows' USB work, so the
  driver check cannot show it apart. Shown, not rated: keep it if you use it; to see whether it costs anything,
  measure, remove it, restart Windows and measure again.
• System › Interrupts shows a measurement as pictures. The result used to be half a page of sentences and
  figures. Now: a meter for the waits over 50 µs against the measurement's own line (0.3 %) with the run's key
  figures; What this means, one line per finding in plain words with what you can do (a driver on your mouse's
  core, gaps your mouse sent nothing in, reports Windows passed on late, a driver from another program in the path);
  the USB work's waits as one stacked bar, the run as a wave (the longest gap in each 100 ms, every gap over
  two report periods as a dot in the colour of what happened), what the gaps were as a donut, what ran on your
  mouse's core as bars, the time each CPU spent in interrupts and DPCs, and your mouse's path as chips. A comparison
  before and after a change shows paired bars. Every sentence, the worst gaps as a table and how it was measured are
  one click away under Details. The core map sits in a card with a legend: each core shows its devices as pills,
  "free" when it holds none, and after a measurement its time in interrupts and DPCs as a bar. The table names
  every device's driver as installed ("Windows' own", "NVIDIA 617.42", "Realtek 1125.31.50.603"), audio and NVMe too.
• A fairer mouse score (v3) for new runs. An 8 kHz mouse that skipped single 125 µs slots and made up for them was
  capped at 5.0 like a 1 kHz mouse missing whole milliseconds. v3 caps hold-ups of 1 ms or more and a mouse that fills
  fewer than 95 % of its rate's slots; skipped ticks still cost the Stutters row, and a really bad run now falls below
  5.0. Runs saved before keep their score and are marked "· v2" or "· v1" in Compare.
• The mouse result says how the gaps sit: made up for ("the reports came late rather than missing") or missing,
  and whether they cluster in one stretch of the run or are spread over it. At 8 kHz, bunched reports are named as held
  on the PC side. "What to do" names what really limits the run.
• USB timing judges Windows too. It no longer says "Clean all the way" when Windows held many reports: it names
  the share held more than half a report period longer than the fastest hand-over (62.5 µs at 8 kHz), names the slots
  the mouse left empty at the USB controller, finds a hold in a fixed part of every millisecond and which clock it
  keeps, and counts the USB reports that never became a mouse move (also in the CSV export).
• "Suggest a layout" spreads your devices over the cores, one per core on its first thread, instead of stacking
  them on the CPU's last thread. On a Ryzen with two CCDs and 3D V-Cache, the graphics card and the rest go onto the
  CCD without the V-Cache; the mouse stays on the V-Cache CCD.
• A measurement never runs on every device at once. With "All mice" or "All controllers" in the picker, a run
  first takes the only device connected or asks on its overlay which one to measure (click or move it); nothing of the
  run starts before that, so the measured window holds only the measurement. A virtual controller (Steam Input,
  DS4Windows) is never measured; with a Steam Controller or Steam Deck, the message says there is no physical pad to
  measure.
• The history keeps 1,000 runs, is read faster and in the background: Compare no longer freezes the window.

Fixed

• A device switched off in Windows stood on its core. System › Interrupts read every device's interrupt setting,
  also one switched off in Device Manager, and placed it on the core that setting names, although it has no
  interrupts. Now InputLab asks Windows whether a device runs: one switched off stands on no core, the table says
  "off: switched off in Windows", the core map lists it under "Switched off in Windows", and the layout editor
  never moves it.
• Home rated a second display kept at a lower rate on purpose. With a 360 Hz display and a second one at 60 of
  75 Hz, the Display rate line turned yellow ("60 of 75 Hz"), as if the PC had a 60 Hz display. Now only the fastest
  display is rated, the one games run on; every display is listed by its own name with its rate ("AORUS FO27Q3:
  360 Hz, its highest, your fastest · 27B2G5: 60 Hz (offers 75 Hz)"), the others without colour.
• Home said "Memory Integrity is on" when only its switch was set. It now asks Windows' Code Integrity whether it
  runs: "On" only then, otherwise "Set to on, not running".
• Home said "Not set" for GPU scheduling (HAGS) that Windows runs. It now asks the graphics adapters, so a
  driver's default shows as "On (the driver's default)", as in Windows › Display › Graphics.
• USB timing could pair each report with the USB report before its own when Windows held every other report; the
  shown hand-over is right again.
• Core parking on Intel hybrid CPUs (E- and P-cores apart) and on dual-CCD X3D Ryzens (explained, no off button);
  Ryzen AI 300 laptops are no longer taken for a dual-CCD X3D; and smaller ones (the "limited by …" line, the
  plot's legend, a tooltip, the live view's amber, the controller's status line, a lighting controller shown as a
  keyboard and PCI locations in Windows' language on the USB map, the XInput cross-check's counts, the Stick Motion
  coverage text, the advice for a run limited by spread and gaps, USB timing's measurement check and Home's timer
  tooltip). Wireless reads radio dropouts at 4 and 8 kHz too: gaps from 1 ms, and slots a receiver left
  empty.

Honest limits

Mouse score v3 was checked against the developer's history of 294 runs (190 unchanged, 91 higher, 10 lower). USB
timing's Windows judgement comes from one user's 2 and 4 kHz runs and the developer's 8 kHz runs. Home's Memory
Integrity line was checked against Windows' own reading on one PC, where it is off; its GPU scheduling line on one
PC, where HAGS is switched on. Everything from 1.3 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.4.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.4.0-win-x64.zip:
  6c9dfe9cf6c87c562d79615af896616e75d25d36128e9afbcdbfd0dd91816230