kernel: laptop touchpads over I2C-HID

A laptop's touchpad is on the chipset's I2C bus, found only through ACPI
(PNP0C50 / ACPI0C50), and SchOS had no I2C at all, so the touchpad of
every recent laptop did nothing.

kernel/acpi/i2c_hid.c drives the DesignWare I2C controller every x86
chipset uses (AMDI0010 on Ryzen) by polling, speaks HID over I2C to the
device the _DSM points at, and feeds the reports through the USB HID
parser. On AMD the interrupt pin's level is read every tick, so a report
is read exactly when one is waiting; elsewhere the input register is polled.

The touchpad is driven in mouse mode, which it starts in after a reset:
motion, clicks and taps become /dev/input/event1 like any mouse. The HID
parser now prefers a descriptor's relative pointer over an absolute one
for this, and takes descriptors from transports other than USB.

Untested on hardware: QEMU emulates no I2C touchpad.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S1giNvrHTrPMPw7V6x1kQ4

include/dev/hid.h

@@ -0,0 +1,17 @@
+#pragma once
+
+#include "core/types.h"
+
+// HID over transports other than USB. The report parser and the keyboard and
+// pointer paths are kernel/drivers/usb/hid/usb_hid.c's; a transport hands
+// over the report descriptor once and every input report after it.
+
+// The device described by `desc`, or 0 if it is neither a keyboard nor a
+// pointer. `what` names it in the log.
+void *hid_attach(const uchar *desc, int n, const char *what);
+// One input report, report ID included when the device uses them.
+void  hid_attached_input(void *h, const uchar *rep, int len);
+
+// I2C-HID: the touchpads (and some keyboards) of laptops. Started once ACPI
+// and kernel threads are up; see kernel/drivers/i2c/i2c_hid.c.
+void  i2c_hid_start(void);