What Touch Driver Porting Involves for Linux and Android

A touch driver port has five parts:

1. Hardware wiring — the controller’s bus, interrupt, and reset lines connected and powered correctly.
2. Kernel configuration — the driver for your touch controller enabled in the kernel build.
3. Device tree description — the node that tells the kernel where the controller is and how to talk to it.
4. Input handling — the controller’s reports turned into kernel input events.
5. Coordinate mapping and Android config — axis direction, rotation, calibration, and the input device configuration file.

Most porting effort is in the last two parts. The kernel driver itself is usually vendor-supplied or mainline; your job is configuration, integration, and verification.

Hardware Wiring First: I2C, Interrupts, and Reset Lines

Porting begins on the bench, not in the kernel config. Verify three things before writing a device tree:

• Bus connection — touch controllers commonly sit on I2C; confirm the address, pull-ups, and voltage levels match the controller datasheet.
• Interrupt line — the controller asserts an interrupt when touch data is ready; it must reach a GPIO the SoC can use as a wake and event source.
• Reset and power sequencing — many controllers need power, a reset pulse, and a settling time before the first I2C transaction; get the sequence from the datasheet.

Check with a bus analyzer or a simple register read before blaming the driver. If the controller does not answer on I2C, no kernel configuration will fix it.

How to Configure the Linux Kernel for a Touch Controller

Enable the driver that matches your controller family in the kernel configuration. The practical questions are:

• Is the driver in mainline, or is it a vendor out-of-tree driver?
• Which dependencies does it need (I2C framework, input subsystem, interrupt controller)?
• Does the automotive BSP already carry the driver, or must it be added to the build?

Keep the display driver out of this task: LCD and backlight driver configuration belongs to the display driver topic, and interface selection belongs to the interface guides. The touch driver enables an input device; the display driver enables pixels. They are different subsystems and different ports.

Writing the Device Tree Node for a Touchscreen

The device tree node tells the kernel how to reach the controller. A typical touch node includes:

• Compatible string — matching the driver.
• Bus address — the I2C address (or SPI chip-select) of the controller.
• Interrupt property — the GPIO and trigger type for the touch interrupt.
• Reset GPIO — if the driver manages reset.
• Controller-specific properties — such as touch size limits, axis inversion, or firmware-selected settings defined by the driver binding.

Copy the node from the driver’s binding documentation, then adjust the bus, interrupt, and reset values for your board. A wrong interrupt trigger (level vs edge) is one of the most common causes of “touch works in the driver probe but never reports events.”

Touch Coordinate Mapping: Axis, Rotation, and Calibration

Once events flow, coordinates may be mirrored, rotated, or offset relative to the display. Work through the mapping in this order:

1. Check raw axis direction — compare a touch at each corner against the reported coordinates.
2. Fix inversion and rotation — usually in the device tree or driver properties, not in user space.
3. Scale to the display resolution — confirm the touch range maps to the panel’s active area.
4. Verify calibration — PCAP controllers normally ship factory-calibrated; if a calibration step is needed, the method belongs to the calibration guide.

The goal is a coordinate transform you can state in one sentence—”panel top-left is (0,0), X increases to the right”—and verify with a test pattern.

Android Input Configuration: IDC Files and Gesture Settings

On Android, the kernel input device is described by an input device configuration (.idc) file. The file sets:

• Touch device type — declaring the device as a touchscreen so the framework processes it correctly.
• Axis ranges and calibration — mapping kernel axis ranges to the display.
• Gesture and palm settings — where the vendor driver exposes tunables for palm rejection or glove mode.

Place the .idc file where Android expects it, name it to match the kernel device, and verify with a touch test app that taps, drags, and multi-touch behave correctly before moving on to the UI.

Frequently Asked Questions