Struct KeyRepeat 

pub struct KeyRepeat { /* private fields */ }

Tracks the currently-held key so a driver can synthesise typematic auto-repeat. USB HID boot keyboards report only on change - a held key sends one down report and then nothing until release - so the host must synthesise repeat itself.

now, initial, and interval are in whatever monotonic unit the driver feeds in - the drivers use ServiceContext::read_tsc() cycles (hardware-proven to advance on real machines, unlike the coarse kernel tick), so initial/interval are cycle counts (e.g. ~300 ms / ~50 ms worth at the CPU’s frequency). The unit is the driver’s choice; this struct only compares and adds. decode_keyboard arms it on a fresh printable press and disarms on release; the driver calls KeyRepeat::poll every loop iteration with the current now. One per keyboard.

Implementations

impl KeyRepeat

pub const fn new(initial: u64, interval: u64) -> Self

initial/interval are in the same unit the driver passes as now (TSC cycles).

pub fn new_calibrated(ticks_per_10ms: u64) -> Self

Construct a repeat CALIBRATED to this machine’s real TSC rate. ticks_per_10ms is ServiceContext::tsc_ticks_per_10ms() (TSC cycles in 10 ms, PIT-calibrated by the kernel); it is 0 only when the TSC was not calibrated (QEMU / the T630’s periodic-timer path, which has no calibrated quantum), where we fall back to ~2 GHz cycle counts (~300 ms / ~50 ms).

The CALIBRATED path uses a deliberately CONSERVATIVE ~600 ms initial delay (not 300 ms). The math for 300 ms is provably correct (30 * ticks_per_10ms), yet the Goldmont+ Wyse still over-repeated at that threshold - its RDTSC appears to advance a little faster under load than the boot-time PIT calibration captured, so a 300 ms cycle budget elapsed in less than 300 ms of wall-clock and normal typing tripped the repeat. A 600 ms budget requires a clearly deliberate hold, absorbing that drift with margin. The interval (~50 ms) is unchanged; only the trigger threshold moved. The fallback (T630) is left at its known-good ~300 ms - the drift is specific to the calibrated part.

pub fn armed(&self) -> bool

Is a key currently held (repeat armed)? A driver uses this to decide how long to block: a short timeout while a key is down (to wake and emit repeats), a long one otherwise (the keyboard is silent, so just idle until the next interrupt).

pub fn cancel(&mut self)

Stop repeating, from OUTSIDE a decode.

A driver needs this when it can no longer vouch for the hold. A boot keyboard reports only on CHANGE, so if a release report is lost - the transaction translator discards it once its frame is gone, and the device never resends - nothing will ever arrive to disarm the repeat, and the key repeats forever. Losing contact is therefore a reason to STOP, not to keep going.

pub fn poll(&mut self, now: u64, emit: impl FnMut(u8))

Emit a repeat of the held key if one is due at now. Call once per poll iteration; a no-op until initial elapses, then fires at most once per interval.