How it works
Reports and connections
A pad doesn't send each press as it happens. Many times a second it sends a report: its whole state at that moment, every button, stick and trigger, and on some pads motion, touch and battery too. The computer hands the reports on to games, and to PadBench.
Reports and the polling rate
A report is a few dozen bytes, laid out as the pad's maker chose: a bit for each button, set while it is held, and a number for each stick axis and trigger, from 0 to 255 on most pads and finer on some. How many reports a pad sends a second is its polling rate, in hertz: often 125 or 250, 1,000 on many arcade boards, such as those running GP2040-CE, and up to 8,000 on a few recent pads.
A press goes out with the pad's next report, so the time between reports, 8 ms at 125 Hz and 1 ms at 1,000 Hz, is the longest a press can wait to leave the pad. That is what a higher polling rate buys: presses sent sooner, and timed more finely.
Some pads send a report at every chance they get, whether or not anything changed; others send one only when something did, so their count falls while nothing moves, though nothing is wrong.
Read more in Polling rate and timing
USB, Bluetooth and dongles
Over USB, the computer collects a pad's reports at the pace the pad asks for as it is plugged in: at most once a millisecond on a full-speed link, which most pads use, and up to every 125 µs, 8,000 times a second, on a high-speed one. A cable gives the steadiest timing.
Over Bluetooth, the pad and the computer's radio agree on a pace, usually slower than a cable's, and the radio shares its time with everything else it talks to, so reports come less evenly, sometimes in bursts. The Timing tab shows this as a wider spread and longer gaps.
A wireless dongle is the pad's own radio on a USB plug: the computer sees a USB device, at the pace the dongle asks for. A dongle may send the computer more reports than it hears from the pad, repeating the latest, so its rate says how often the computer hears from the dongle, not how fresh each report is.
HID and XInput
Most pads are HID devices, Human Interface Devices, like keyboards and mice. Each comes with a descriptor that says where its buttons and axes sit in its reports, so a computer can read a pad it has never met, though many pads keep their richer parts, such as a Sony pad's touchpad and motion, in a layout of their own that the reader must know. What many pads call their DirectInput mode is this kind.
Xbox pads, and pads in their XInput mode, which many PC pads start in, are read on Windows through XInput, Microsoft's own way. XInput hands over a pad's state, its buttons, sticks, triggers and battery, rather than its reports, for at most four pads, and it says only that the state changed, not when the pad reported. That is why the Windows app counts state changes for an Xbox pad, not reports.
Why one pad can read differently
A pad can present differently on each connection and in each mode: other ids, another report, even another name. A DualShock 4 or a DualSense on Bluetooth starts in a reduced report, without its touchpad, motion or battery, until something switches it to its full one. Many pads present as an Xbox pad in one mode and as a Switch or PlayStation pad in another, and PadBench shows the pad each mode presents as.
Each browser also reads pads its own way: it numbers the buttons by its own mapping, may apply a dead zone of its own, as Chrome and Firefox do for Switch pads, whose sticks then rest at exactly 0, and hands the page its readings at its own pace. When one pad reads well in one browser and oddly in another, the difference is usually the browser's.