Support for Touch Host Controller (Tigerlake+)

[Matombo]

Hi,
I know this repo is for surface devices, but the new Intel NUC M15 Laptop seems to use the same touchscreen controler. Windows recognizes it as Intel Precision Touch & Stylus or similar (currently booted on Linux but can look up the exact name if it becomes relevant). Linux sudo lspci -vvnn:

00:10.6 Digitizer Pen [0901]: Intel Corporation Device [8086:a0d0] (rev 20)
	DeviceName: Onboard - Other
	Subsystem: Intel Corporation Device [8086:2097]
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 255
	IOMMU group: 10
	Region 0: Memory at 603e1d0000 (64-bit, non-prefetchable) [disabled] [size=32K]
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [70] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-

I'm on linux-surface kernel 5.10 which correctly recognizes the MEI:

00:16.0 Communication controller [0780]: Intel Corporation Tiger Lake-LP Management Engine Interface [8086:a0e0] (rev 20)
	DeviceName: Onboard - Other
	Subsystem: Intel Corporation Device [8086:2097]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 156
	IOMMU group: 15
	Region 0: Memory at 603e1ed000 (64-bit, non-prefetchable) [size=4K]
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
		Address: 00000000fee00638  Data: 0000
	Capabilities: [a4] Vendor Specific Information: Len=14 <?>
	Kernel driver in use: mei_me
	Kernel modules: mei_me

However regardless of using the dkms or the builtin driver the ipstd service crashes on start:

● iptsd.service - Intel Precise Touch & Stylus Daemon
     Loaded: loaded (/usr/lib/systemd/system/iptsd.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Thu 2021-02-18 12:49:47 CET; 5h 30min ago
       Docs: https://github.com/linux-surface/iptsd
    Process: 1361 ExecStart=/usr/bin/iptsd (code=exited, status=237/KEYRING)
   Main PID: 1361 (code=exited, status=237/KEYRING)

Feb 18 12:49:42 test-pc systemd[1]: Started Intel Precise Touch & Stylus Daemon.
Feb 18 12:49:47 test-pc iptsd[1361]: ERROR: ../src/control.c:52: Failed to send feedback: No such device
Feb 18 12:49:47 test-pc iptsd[1361]: ERROR: ../src/control.c:75: Failed to flush buffers: No such device
Feb 18 12:49:47 test-pc iptsd[1361]: ERROR: ../src/main.c:83: Failed to start IPTS: No such device
Feb 18 12:49:47 test-pc systemd[1]: iptsd.service: Main process exited, code=exited, status=237/KEYRING
Feb 18 12:49:47 test-pc systemd[1]: iptsd.service: Failed with result 'exit-code'.

Could it be that the Surface devices use the same controller, but connect it differently than the NUC M15? Some hints that lead me to this theory:

• The surface devices seem to not have the Digitizer Pen PCI device (I have no Surface device, so my source is linux-hardware.org)
• I extracted the driver package for the NUC M15 as well as one of the Surface devices supported by this repo. I grep'd for strings found in the NUC Touchscreen driver .inf file but could not find any hints for this driver in the Surface driver package.
  My Theory: While on the Surface devices the Touchscreen controler is managed by the ME (which this driver is for) und the NUC M15 the controler is directly accessed over the pci bus, which would require a completly differend driver.

I hope I'm wrong ^^.

[StollD]

My Theory: While on the Surface devices the Touchscreen controler is managed by the ME (which this driver is for) und the NUC M15 the controler is directly accessed over the pci bus, which would require a completly differend driver.

This is pretty much correct. With Tiger Lake, Intel deprecated the old MEI based IPTS and instead moved its functions to a standalone PCI device, the Touch Host Controller (THC). Some Lenovo device is out there using it too.

Since the THC is not MEI based, I doubt this driver can be reused at all. It might be possible to reuse the iptsd daemon, if the data that the hardware outputs is the same or similar. But there is no way to be sure without having a working kernel driver.

What I find interesting is that the IPTS driver probes on your device and creates its userspace interface. That either indicates that some life is left in the old interface, or that Intel adds the interface to all of their hardware (which would be annoying for upstreaming this driver). Could you post your full dmesg?

[qzed]

I've had a quick look over the driver package for that device. There's a iTouch THC Base Driver, but that doesn't seem to have any firmware package like the old IPTS driver. There are some interesting strings in there (GetOutputHidXferPacketFromRequest, FlashlessFwDataFile, FlashlessFwStage1File, ...), not sure what to make from that yet.

There's a touchpad driver with firmware (but I think that's really for the touchpad and not the touchscreen, seems to be a PixArt PCT1836 device and it does look like it's a touchpad controller similar to this one).

There's also a HID Event Filter driver. There are references to some ACPI devices (INT33D5, INTC1051, ...) in a config file associated with that, but I couldn't find anything on them. The strings in that driver do indicate that it's for some function keys though (wireless radio button, home button, volume buttons, ... are all referenced)

So I'm wondering how that works exactly. There doesn't seem to be any obvious firmware around (unless that's baked into the hardware and just needs to be updated when it changes or baked into some driver). And unless the HID Event Filter thing is doing touch processing (which I kinda doubt due to the ACPI references), there doesn't seem to be any equivalent of a TouchPenProcessor.dll around either. So maybe that's distributed separately or already integrated into Windows by now?

[qzed]

Also having this as a PCI device without any way of controlling touch processing (be it GuC/compute kernels or user-space processing) doesn't make much sense to me. If it'd be just another touch controller that needs some lockded-down firmware for processing, why not use I2C, SPI, USB or whatever.

[StollD]

Well, the IPTS protocol can also transport HID reports instead of raw sensor data. I wouldn't rule it out that an OEM could do the processing in the touch controller firmware and only use IPTS for passing the data around.

[qzed]

Yeah, but Intel themselves doing that? I'd think the NUC devices would be a showcase of sorts for them to demonstrate how things work. Maybe chipset documentation could give us a hint.

[qzed]

There's not much more than "Touch Host Controller provides the standard SPI interface to connect to external touch ICs.". So maybe it really doesn't do processing.

[qzed]

Oh hey, apparently there's a patent application for it: US20190102032A1.pdf. Doesn't really clear things up for me though.

[Matombo]

What I find interesting is that the IPTS driver probes on your device and creates its userspace interface.

I rechecked and realized that the /dev/ipts/X devices are only there when I manually modprobe the ipts driver. The iptsd was started after that. When I start it before, I just get a "No such file or directory error".

dmesg after boot:
unloaded.txt

dmesg after modprobe ipts
loaded.txt

I use the linux-surface kernel build from here https://github.com/linux-surface/linux-surface/wiki/Installation-and-Setup#arch :

Linux test-pc 5.10.16-arch1-2-surface #1 SMP PREEMPT Mon, 15 Feb 2021 20:59:59 +0000 x86_64 GNU/Linux

and have additionally installed the dkms ipts driver via the AUR.

[StollD]

I rechecked and realized that the /dev/ipts/X devices are only there when I manually modprobe the ipts driver. The iptsd was started after that. When I start it before, I just get a "No such file or directory error".

Ah, I didnt think about manually loading the driver. That confirms that the MEI interface is gone then. It doesnt really help you, but thanks nonetheless.

[Matombo]

Thanks from my side for the quick response ^^

Now at least I know that I don't need to test further with this driver.