HID over I2C transport for laptop and tablet touchpads, touchscreens, and keyboards
The standard transport that lets the kernel talk to HID input devices wired over an I2C bus rather than USB, which is how almost every modern laptop and tablet touchpad and touchscreen is connected. It handles both the ACPI0C50/PNP0C50 binding common on x86 machines and device-tree variants from vendors like Elan, Goodix, and FocalTech.
recommendation
It should stay in the kernel because it is the transport that nearly every contemporary laptop and tablet relies on for its touchpad and touchscreen, and there is no alternative driver covering the same role. Upstream activity is very much alive, with 2025 commits adding new device IDs such as the FocalTech FT8112, fixing Dell S4 suspend behavior, tightening Elan timing, and patching a buffer overflow.
repository signals
sources
- lore.kernel.org
Recent upstream work touched i2c-hid power-management behavior, indicating active maintenance rather than retirement.
- cateee.net
LKDDb describes this as generic HID-over-I2C support for keyboards, touchpads, touchscreens and other HID devices, showing broad device scope.
- cateee.net
LKDDb shows the ACPI transport binding (including ACPI0C50) remains present in current kernels, matching common x86 laptop/tablet deployments.
- learn.microsoft.com
Microsoft documents HID-over-I2C devices as widely used in modern laptops and tablets, supporting that this hardware class is still current in 2025.
codex reasoning notes (technical)
Real driver directory: module_i2c_driver entry points are present in i2c-hid-acpi.c, i2c-hid-of.c, i2c-hid-of-elan.c, and i2c-hid-of-goodix.c (checked via local shell rg). Upstream activity is clearly live: local git log shows 2025-2026 fixes/new IDs (Dell S4 touchpad issue, FocalTech FT8112, ELAN timing, buffer-overflow fix), and the cited lore URL came from MCP lore_substr_subject on 'i2c-hid'. Deployment remains high because this is the standard HID-over-I2C transport for laptop/tablet touchpads and touchscreens; LKDDb and Microsoft URLs were obtained by web search. No natural replacement driver exists for the same use case; this directory is the transport layer itself, so removal/deprecation is not justified.