Calibration must survive reboots. Options:

Recommended: Implement calibration persistence in a companion user-mode Windows service. The KMDF driver remains stateless regarding persistent storage, enhancing stability.

Your KMDF HID minidriver should expose a private IOCTL for calibration data injection. Example:

// In your EvtDeviceIoControl handler
case IOCTL_TOUCH_SET_CALIBRATION:
    // Parameters: XScale, YScale, XOffset, YOffset, Threshold
copy_from_user(&calib, inputBuffer, sizeof(CALIBRATION_DATA));
// Store in device context
devContext->XScale = calib.XScale;
devContext->XOffset = calib.XOffset;
// Apply clipping to avoid invalid coordinates
devContext->CalibrationValid = TRUE;
break;

Best Practice: Protect calibration parameters with a spinlock or mutex, as they are accessed both in IOCTL context and interrupt DPC.

The typical pipeline:

Touch HW → I2C → KMDF HID Minidriver → HID Class Driver → Windows Touch Input
                          |
                    Calibration (transform)

The minidriver receives raw HID reports (touch, pressure, contact ID, etc.), applies a calibration transform, and forwards modified reports up the stack.

Before addressing calibration, it is essential to understand where the KMDF minidriver sits. Windows provides a native Hidi2c.sys driver stack. However, many vendors choose to write a proprietary KMDF HID minidriver to handle specific hardware quirks, power management, or proprietary calibration protocols.

The stack typically looks like this:

Edge distortion (common in projected capacitive touch) may require a second-order polynomial or a lookup table. Implement this in the minidriver only if the controller’s firmware lacks native correction.