One USB cable, no driver disc
The controller enumerates as a standard USB HID digitizer. Windows, Android, Linux and ChromeOS already know what that is, so a stock-size frame is a plug-and-play part: screw it on, plug in, touch. The exceptions matter, and they are listed here rather than buried in a datasheet footnote.
Which systems run without a driver
Tested on the versions listed. “None” in the driver column means the operating system provides it; nothing is installed from our side.
| Operating system | Versions tested | Driver | Multi-touch | Points | Notes |
|---|---|---|---|---|---|
| Windows 10 / 11 | 1909 – 24H2 | None | Yes | 20 | Enumerates as HID-compliant touch screen. Calibration is in Control Panel → Tablet PC Settings |
| Windows 7 SP1 / 8.1 | x86 / x64 | None | Yes | 10 | Needs the touch components present in the image; a stripped embedded build may not have them |
| Windows IoT / Embedded | WES7, Win10 IoT | None, but the image must include Touch | Yes | 20 | Add the Touch and Tablet PC packages to the image, or the HID device is ignored |
| Ubuntu / Debian | 18.04 – 24.04, Debian 10 – 12 | hid_multitouch (in kernel) | Yes | 20 | Works on X11 and Wayland. If only the pointer moves, the module is not loaded |
| Yocto / Buildroot | kernel ≥ 3.8 | Enable CONFIG_HID_MULTITOUCH | Yes | 20 | Most custom kiosk images ship without it — one config line |
| Raspberry Pi OS | Bullseye / Bookworm | hid_multitouch | Yes | 10–20 | Bookworm on Wayland is fine; some minimal images report single touch until the module loads |
| Android | 7 – 14, incl. RK3568 / RK3588 / Amlogic | None | Yes | 20 typical | Vendor kernels vary; an .idc file fixes a build that maps touch to a mouse |
| ChromeOS | 100+ | None | Yes | 10 | Works as a touchscreen, including in kiosk mode |
| macOS | 10.13 – 15 | None exists | No | 1 | Reports as a mouse. There is no HID multitouch path for third-party panels and we do not ship a driver |
| iPadOS / iOS | — | — | No | — | Not a HID host for external touchscreens; a pointer at best |
Capped by the OS, not by the frame
The single most common misunderstanding on a 32 or 40-point frame: the hardware reports 40 contacts, and the host accepts whatever its HID descriptor allows. On Windows 10 / 11 and current Android boards that is 20 — so a 40-point frame presents as a 20-point device, and nothing is broken. The 10-finger ceiling people quote comes from the old Windows 7 touch stack. This table is what actually reaches your application.
| Operating system | Max simultaneous | Detail |
|---|---|---|
| Windows 10 / 11 | 20 | The HID descriptor declares the contact count and Windows 8 and later accept up to 20. A 32 or 40-point frame ships flashed to a 20-contact descriptor on Windows builds, so 20 fingers is the working figure |
| Windows 7 | 10 | The older digitizer path stops at ten; for a Win7 fleet we flash a 10-contact descriptor so behaviour matches the datasheet |
| Android | 20 typical | Framework and vendor kernels carry 20 on RK3568 / RK3588 boards; a few vendor images map touch to a mouse until an .idc file is added |
| Linux | 20 via libinput | The kernel and libinput carry 20; your application decides how many it reads |
| ChromeOS | 10 | Same stack as Android underneath, capped lower on current builds |
| macOS | 1 | Single pointer, no multitouch |
One command per system
Before you suspect the hardware, confirm what the host sees. These are the checks we ask for on a support call, and they settle the question faster than any photo.
| System | What to run or look at |
|---|---|
| Windows | Device Manager → Human Interface Devices. Look for “HID-compliant touch screen”. If it says mouse, the descriptor is wrong — send us the label photo. |
| Linux | lsusb for the device, dmesg | grep -i hid for the driver, libinput list-devices for what the stack sees, evtest for live coordinates. |
| Android | getevent -l on adb shell. A working digitizer streams ABS_MT_POSITION_X; a mis-mapped one streams REL_X like a mouse. |
| ChromeOS | chrome://system → input devices. Touch appears as a touchscreen device, not a pointer. |
| macOS | System Information → USB. The controller appears; no touchscreen device is created. That is the expected behaviour, not a fault. |
Six integration traps
The OS calls it a mouse
The controller was flashed with a mouse descriptor, usually on a spare board. It still moves the cursor, which is why it gets mistaken for a working unit. One reflash fixes it and the tool ships with the order.
It works on the bench, not in the product
The product's port provides less current than the bench hub, or the cable run is longer. A 40-point frame peaks near 320 mA; a port rated 500 mA with a 5 m passive cable may not hold it.
Multi-touch dies after a kiosk image update
The new image ships without hid_multitouch, or blacklists it. Single touch still works, so it reads as a hardware downgrade.
Coordinates are mirrored or rotated
The display is rotated in software but the frame is not rotated in the controller. Set orientation in the calibration tool, then check the OS rotation matches.
Offset grows with display scaling
Windows at 125 % or 150 % scaling moves the mapping origin. Either run 100 % or recalibrate at the scaling the product ships with — not both.
Touch stops when the screen sleeps
The USB port is suspended with the display. Disable selective suspend for that port, or power the controller from a port that stays alive.
Test on your own board
Every one of these questions is answered by one sample on your own hardware, and that is the cheapest test in this business. We ship a single unit for evaluation, with the calibration tool, the installation sheet and a test checklist matched to your host. Run it on the board you will actually ship, at the OS version you will actually image, before you cut a housing or pay for tooling.
Driver and compatibility questions
Do I need to install a driver on Windows?
Why does my 40-point frame only register 20 fingers?
Does it work on a Mac?
What about a Raspberry Pi?
Can I use it with an Android media box?
Is there an SDK or API?
Tell us the host board.
Send the SoC, the OS version and the cable length in your design. We will tell you whether a stock controller works or which descriptor it needs.