e43f56c619
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
17 lines
735 B
C
17 lines
735 B
C
#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);
|