Touch report rate is the sensor's position samples per second

What it is

Touch report rate is how many times per second the touch sensor hands a contact coordinate upstream, usually in hertz. It describes how dense the position samples are, not how many times the display lights a frame, and not how often an onTouch callback runs. A 120 Hz panel paired with a 240 Hz touch IC can deliver two coordinates between vertical syncs. Calling report rate “refresh rate” collapses the input clock and the output clock into one number.

Why it happens

A projected-capacitive panel polls its electrode grid on a scan cycle; the controller estimates a centroid for each contact blob and ships a packet to the SoC over interrupt or bus. Report rate is bounded by scan time, filtering, multitouch tracking cost, and bus bandwidth. Vendors sometimes split scan rate from report rate: the IC can scan faster internally and merge adjacent samples before reporting, trading density for power. The event spacing the app sees is therefore a clock-sliced point series, not continuous motion on glass. Effective report rate on the same device also drops for five-finger chords, large contact area, or a wet edge, because the controller spends the interval disambiguating blobs.

Studying it

Timestamp coordinate packets at the kernel or probe the controller interrupt with a scope or high-speed camera; do not treat the datasheet hertz as the measurement. Independent variables include simultaneous contact count, contact area, swipe speed, charging state, and whether glove mode is on. Dependent measures are mean inter-sample interval, interval jitter, burst drops, and the interval at which the app thread actually reads events. A datasheet 240 Hz sampled by a main thread that wakes every 16 ms is application-side decimation, not sensor report rate.

Where it stops holding

Report rate is not end-to-end latency. Samples can be dense and the compositor can still wait for the next frame, so the finger still looks late. Gamepad-style touchpads, infrared frames, and some resistive panels use different scan logic; their hertz figures are not comparable. Power-saving paths may drop reports near zero while idle, so the first milliseconds of motion look sparse then dense. Treating a resting-desktop report rate as the in-game rate overestimates the sample density available during movement.

Applying it

• Plot touch-interrupt intervals on their own trace in a performance panel or systrace; do not overlay them on GPU frame time as one metric.
• For inking, virtual joysticks, and fast swipes, put a target report rate in the hardware brief, not only a display refresh rate.
• At acceptance, compare high-speed footage of the finger against event timestamps: if packets per second miss the claimed value, design against the effective report rate.

Related

• Same group: C2.17.2 Super-refresh report rates feed predictive rendering with earlier samples · C2.17.3 Undersampled fast swipes look lagged and polygonal · C2.17.4 Software interpolation cannot fully replace a hardware report rate
• Nearby: C2.10 Touch latency and directness · C2.01 Finger contact area and touch centroid
• Search terms: touch report rate · sampling rate · touch controller