-
Notifications
You must be signed in to change notification settings - Fork 0
Standard Touch Mode
This is the mode the driver uses by default (raw_mode=0) and the one that's actually stable
and usable day to day.
The device supports two very different output modes:
| Mode | How it's entered | What it sends | Coordinates |
|---|---|---|---|
| Standard HID (default) | Just... don't send GET_FEATURE/SET_FEATURE
|
Report ID 0x40 (TouchScreen), Report ID 0x01 (Pen) |
Pre-computed by firmware |
| Raw heatmap |
GET_FEATURE(id=4) then SET_FEATURE(id=4, val=1)
|
Report ID 0x0C-tagged frames (~4302 bytes of capacitive/DFT sensor data) |
None — raw sensor data, needs blob detection |
Windows always requests raw heatmap mode, because its own touch stack
(TouchPenProcessor0C19.dll) needs the raw sensor data to do its own DFT-based multi-touch
processing. But the device's own firmware is fully capable of producing ready-to-use single
-touch coordinates on its own, in the default mode — nobody has to ask for it, it's what the
device does unless told otherwise.
This driver, in its default configuration (raw_mode=0), simply never sends
GET_FEATURE/SET_FEATURE at all — reaching state 4 (DONE) directly after the report
descriptor exchange (see Architecture) — and the device happily streams
Report ID 0x40/0x01 with real coordinates at roughly 10ms intervals, no calibration or
signal processing required on the Linux side.
- TipSwitch: 1 bit (touch down/up)
- X: 16-bit (0–32767 logical range)
- Y: 16-bit (0–32767 logical range)
- Report size: 6 bytes total (1 report ID + 1 tip byte + 2 X + 2 Y)
Fed straight into the kernel's HID input subsystem via hid_input_report() — no custom
processing needed, hid-generic + the standard hid-input quirk handling take it from there.
Standard Digitizer Pen collection fields: InRange, TipSwitch, BarrelSwitch, Invert, Eraser,
X, Y, TipPressure. Also forwarded directly via hid_input_report().
Small reports (like the 8-byte 0x40 report) once triggered a length-check bug: the
available-buffer check (avail = rblen - 8) was computed against the wrong baseline, so
rl > avail incorrectly dropped every standard-mode report. Fixed by passing rl - 2 to
hid_input_report() (subtracting the 2-byte content-length-field overhead) and checking
rl - 2 <= avail. If you ever see standard-mode reports silently vanishing, this is the kind
of off-by-a-few-bytes bug to look for first.
Multi-touch (2+ simultaneous fingers) is not available in this mode — the firmware's built-in coordinate computation only tracks one contact point. Getting real multi-touch requires the raw heatmap mode and blob detection covered in Multi-touch Experimental, which is not yet reliable enough for daily use.