SP8 touchscreen and pen support

[luca-viggiani]

Hi I'm sure that this has already been asked before (maybe several times), but I can't find where. And I know there's some work ongoing about getting touchscreen and pen work on SP8. So what's the status and where can I track it? Thanks!

[j4ckgrey]

@quo i didnt get touch working at first so I did enter poll mode (this command: sudo modprobe -r ithc; sudo modprobe ithc poll rx0 logregs dyndbg=+pflmt),

Thank you for this. Just got a SP8, and sudo modprobe -r ithc; sudo modprobe ithc poll rx0 logregs dyndbg=+pflmt worked to get my touchscreen working too (single touch)!! That's amazing!! Infinite thanks you guys are awesome.

On arch, it's just a matter of following the installation guide, then installing ithc after installing the dependencies with pacman, which on arch obviously are: sudo pacman -S dkms linux-surface-headers then install ithc as explained here https://github.com/quo/ithc-linux then reboot, then run sudo modprobe -r ithc; sudo modprobe ithc poll rx0 logregs dyndbg=+pflmt

Having single touch makes it quite tabletable for me!!

This command allows you to use touch only when you run, which means you have to run the command everytime you restart etc. Run "sudo make set-nosid" to get touch working without having to do this everytime (works only in Ubuntu, couldnt get it to work in arch), and install iptsd experimental for multitouch, works fine as well.

[NP-chaonay]

@quo i didnt get touch working at first so I did enter poll mode (this command: sudo modprobe -r ithc; sudo modprobe ithc poll rx0 logregs dyndbg=+pflmt),

Thank you for this. Just got a SP8, and sudo modprobe -r ithc; sudo modprobe ithc poll rx0 logregs dyndbg=+pflmt worked to get my touchscreen working too (single touch)!! That's amazing!! Infinite thanks you guys are awesome. On arch, it's just a matter of following the installation guide, then installing ithc after installing the dependencies with pacman, which on arch obviously are: sudo pacman -S dkms linux-surface-headers then install ithc as explained here https://github.com/quo/ithc-linux then reboot, then run sudo modprobe -r ithc; sudo modprobe ithc poll rx0 logregs dyndbg=+pflmt Having single touch makes it quite tabletable for me!!

This command allows you to use touch only when you run, which means you have to run the command everytime you restart etc. Run "sudo make set-nosid" to get touch working without having to do this everytime (works only in Ubuntu, couldnt get it to work in arch), and install iptsd experimental for multitouch, works fine as well.

idk if can using poll and the others permanently by set "ithc.poll=1 ithc.rx0 ithc.logregs ithc.dyndbg=+pflmt" in cmdline or if not able then maybe settings in modprobe (or distro's module loader setting). intremap=nosid seem to be kernel cmdline and i cannot find where to set in /proc /sys so maybe require reboot. while these ithc parameter can re-apply by reloading (some driver's parameter can change on run-time by change file in sysfs procfs)

[xrishox]

now that we have working multi-touch with iptsd and ithc are there any plans of incorporating them into this project and the repositories that this project runs?

[j4ckgrey]

now that we have working multi-touch with iptsd and ithc are there any plans of incorporating them into this project and the repositories that this project runs?

I had the same thought today, would be much easier.

[aleksfadini]

I second that, I am also using both, and they work pretty well!

[qzed]

I don't have any particular objections against that, as long as @quo thinks it's ready and @StollD as doesn't have any issues with that either.

[j4ckgrey]

I don't have any particular objections against that, as long as @quo thinks it's ready and @StollD as doesn't have any issues with that either.

I just wanna mention that there were still some troubles regarding archlinux for example, i couldnt get it installed as i remember ("sudo make set-nosid" in particular, otherwise touch wont work without it) then i was forced to go back to ubuntu. IPTSD doesnt work on Ubuntu 20.04 focal fossa, same goes tothe edid for 120hz ..... not sure if including them in the kernel would fix those things. Please enlighten me!

[StollD]

I don't have any particular objections against that, as long as @quo thinks it's ready and @StollD as doesn't have any issues with that either.

If the kernel driver is ready we should include it.

Regarding iptsd, I had hoped that I would have the time at some point to dive into all of the HID stuff, so that we could adapt iptsd to use the HID interface on all platforms (GuC based IPTS, IPTS on gen7 and ITHC). I also wrote some code for it but ran into some issues with the data format, where I didnt have the time to think about the best solution yet.

[quo]

I was hoping to find a better fix for the irq source id issue, so the intremap=nosid workaround wouldn't be necessary. The best I have been able to come up with is a patch to disable the sid check for ITHC only instead of globally (see https://github.com/quo/ithc-linux/issues/2).

Since other than that the driver seems to work fine, I'm ok with including it in the surface kernel. You'll have to add the above patch as well.

As for iptsd, feel free to merge my changes. Unfortunately I haven't had time to test the parser changes on older SP models yet (but if anything's broken it should be trivial to fix).

I still want to add tilt support in the short term (should be fairly straightforward, see https://github.com/quo/iptsd/issues/3), and also make the pen signal detection / position fitting a little more robust, but I just haven't had the time.

[StollD]

I took a look at your changes, I actually just made some very similar ones on the hid branch of iptsd. The DFT stuff seems simple enough to port. Once I get the whole daemon working with the HID based driver, I can either try to port it myself, or ping you so you can make a pull request. Whatever you prefer.

Other than that I hope the code will just work (tm) with the ITHC driver in HID mode. Since you say in the README that the mode is not recommended: Is that just because there is no HID-enabled iptsd, or is there anything else that doesnt work well in that mode?

[quo]

Would be great if you could port it. Feel free to use the parts you like and ignore the rest :) (and don't worry about credit or anything, I'm happy as long as my code gets used somewhere).

I do recommend adding something like the Block abstraction I made; it makes the parsing code easier to read and is a little less error-prone than manually tracking sizes and seeking/skipping through the data.

And yeah, the main reason the readme says HID is not recommended is that it has not really been tested sufficiently. The ithc driver currently does enable HID by default if the touch device is not an MS device, because on the Lenovo X1 Fold the THC is connected to Wacom hardware which sends normal HID reports.

[StollD]

I pushed a port of @quo's code into the dft branch on iptsd. I would be interested to hear if that branch

• works on gen7 and above
• behaves like (or at least similar) to the iptsd from @quo

If you have a Surface 7 Pro, Surface Laptop 3 or Surface Book 3 you will need to build the ipts module from the hid branch: https://github.com/linux-surface/intel-precise-touch/tree/hid

$ git clone https://github.com/linux-surface/intel-precise-touch
$ cd intel-precise-touch
$ git checkout hid
$ make
$ sudo systemctl stop iptsd
$ sudo rmmod ipts
$ sudo insmod ipts.ko

If you have a Surface Pro 7+ or later, you will need to use ITHC from @quo in HID mode:

$ git clone https://github.com/quo/ithc-linux/
$ cd ithc-linux
$ make
$ sudo insmod build/ithc.ko hid=1

[aleksfadini]

Thank you! I'd be happy to test this on my SP8. So I should run all of the commands you mentioned above, including the first section that builds the ipts module from the hid branch?

Currently multi touch and pen work, but I'm using the git ipts and ithc, and passing intermap=nosid at boot (I'm assuming you'd like me to test if it works without that parameter).

[StollD]

You only need to run one of the sections, depending on what device you have. SP8 uses THC, so you need ITHC.

Since you already have a working setup, all you really need to do regarding the kernel is add ithc.hid=1 to the kernel commandline, and then build and launch iptsd from the dft branch.

[StollD]

Here is how you build and run iptsd. since a bit has changed:

$ git clone https://github.com/linux-surface/iptsd
$ cd iptsd
$ meson build --wrap-mode=forcefallback
$ ninja -C build
$ sudo ./build/src/daemon/iptsd /dev/hidrawN

You can find the hidraw device name by running this command:

$ dmesg | grep -i hidraw | grep -E '(IPTS|Intel Touch Host Controller)'

[StollD]

There are also prebuilt packages for the distributions we support: https://github.com/linux-surface/iptsd/actions/runs/2699184935

Download the artifact called <your distro>-latest, unpack the zip file and install the package inside. Then reboot, and load the kernel module (if not done automatically with DKMS etc.). The service should start automatically and multitouch should work.

You can run this to check if the service was automatically started

ps aux | grep iptsd

[aleksfadini]

dmesg | grep -i hidraw | grep -E '(IPTS|Intel Touch Host Controller)'

I'm in the process of compiling iptsd from the dft branch. The command above doesn't give any result. I'm looking for my hidraw number. I have 0 to 4.

# dmesg | grep -i hidraw | grep -E '(IPTS|Intel Touch Host Controller)'
[root@AgileFenix aleks]# dmesg | grep -i hidraw
[    2.256346] hid-generic 0019:045E:0922.0001: hidraw0: <UNKNOWN> HID v1.11 Device [Microsoft Surface 045E:0922] on 01:15:01:07:00
[    2.291113] hid-generic 0019:045E:0922.0002: hidraw1: <UNKNOWN> HID v1.11 Device [Microsoft Surface 045E:0922] on 01:15:01:06:00
[    2.456272] hid-generic 0019:045E:09AE.0003: input,hidraw1: <UNKNOWN> HID v1.11 Keyboard [Microsoft Surface 045E:09AE] on 01:15:02:01:00
[    2.462163] hid-generic 0019:045E:0991.0004: hidraw2: <UNKNOWN> HID v1.11 Device [Microsoft Surface 045E:0991] on 01:15:02:05:00
[    2.466238] hid-generic 0019:045E:09B0.0005: input,hidraw3: <UNKNOWN> HID v1.11 Keyboard [Microsoft Surface 045E:09B0] on 01:15:02:02:00
[    2.470312] hid-generic 0019:045E:09AF.0006: input,hidraw4: <UNKNOWN> HID v1.11 Mouse [Microsoft Surface 045E:09AF] on 01:15:02:03:00
[    2.682376] hid-multitouch 0019:045E:09AF.0006: input,hidraw4: <UNKNOWN> HID v1.11 Mouse [Microsoft Surface 045E:09AF] on 01:15:02:03:00

Which one is it?

4 doesn't seem to work:

$ sudo ./build/src/daemon/iptsd /dev/hidraw4
[15:10:54.317] [error] Display size is 0

[qzed]

Those look all like Surface Aggregator devices (on account of the 01:15:...). Is the ithc module loaded and in hid mode?

[aleksfadini]

Sorry, I think the ithc module is loaded but not in hid mode. I'm building this while using the latest SP8 multitouch experimental "fixes", which included the iptsd from @quo and no hid mode (I suppose). How would I check?

[qzed]

As far as I can tell you need to specify hid=1 when loading the module, e.g. sudo insmod build/ithc.ko hid=1 as mentioned by @StollD above.

[StollD]

If you have it installed via. DKMS, you can add ithc.hid=1 to the kernel commandline.

[StollD]

I pushed the configs for SP7+ and SP8 to the dft branch. Running git pull should fix the display size error.

[aleksfadini]

I'm still getting the display size error after a git pull. I even deleted the folder and re-cloned and rebuilt (from dft) to make sure.

Are we sure 4 is my hidraw device?

$ sudo ./build/src/daemon/iptsd /dev/hidraw4
[sudo] password for aleks:
[15:50:11.836] [error] Display size is 0

[StollD]

Are we sure 4 is my hidraw device?

We are sure that it isnt because your ithc is not in HID mode. Since hidraw4 is a different device, the device ID will not be the one thats in the config I pushed, so it still wont find one and error out.

[aleksfadini]

I am not sure what I'm missing. I have installed ithc via dkms, as explained earlier in this thread. In my GRUB I have:

GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet i915.enable_psr=0 ithc.hid=1"

So I'm expecting HID to be on, yet I still get:

sudo dmesg | grep -i hidraw
[    2.202810] hid-generic 0019:045E:0922.0001: hidraw0: <UNKNOWN> HID v1.11 Device [Microsoft Surface 045E:0922] on 01:15:01:07:00
[    2.236413] hid-generic 0019:045E:0922.0002: hidraw1: <UNKNOWN> HID v1.11 Device [Microsoft Surface 045E:0922] on 01:15:01:06:00
[    2.474442] hid-generic 0019:045E:09AE.0003: input,hidraw1: <UNKNOWN> HID v1.11 Keyboard [Microsoft Surface 045E:09AE] on 01:15:02:01:00
[    2.479415] hid-generic 0019:045E:0991.0004: hidraw2: <UNKNOWN> HID v1.11 Device [Microsoft Surface 045E:0991] on 01:15:02:05:00
[    2.484620] hid-generic 0019:045E:09B0.0005: input,hidraw3: <UNKNOWN> HID v1.11 Keyboard [Microsoft Surface 045E:09B0] on 01:15:02:02:00
[    2.488598] hid-generic 0019:045E:09AF.0006: input,hidraw4: <UNKNOWN> HID v1.11 Mouse [Microsoft Surface 045E:09AF] on 01:15:02:03:00
[    2.614290] hid-multitouch 0019:045E:09AF.0006: input,hidraw4: <UNKNOWN> HID v1.11 Mouse [Microsoft Surface 045E:09AF] on 01:15:02:03:00

So I don't know which hidraw to use, and still get the "display zero" error. I get

sudo ./build/src/daemon/iptsd /dev/hidraw0
[16:15:04.928] [error] Display size is 0

for hidraw 0, .. to 4.

[StollD]

Can you post the entire output of dmesg please?

[aleksfadini]

Thank you for looking into this and I apologize for my cluelessness in this. dmesg.txt

[qzed]

Those are still all Surface Aggregator HID devices. You're looking for something that doesn't have the on 01:15:... at the end.

And it looks like ithc doesn't want to load:

[    2.693583] ithc 0000:00:10.6: ithc_probe: hid_add_device failed with -110
[    2.693586] ithc: probe of 0000:00:10.6 failed with error -110

Error -110 is ETIMEDOUT. Unfortunately I don't know anything about the ithc driver, so I can't say why this happens. I guess @quo would know more.

[qzed]

Do you still have intermap=nosid set?

[aleksfadini]

Do you still have intermap=nosid set?

Ahhh! No I do not, because I thought I needed to take it out to test. Good point, will put it back and try again!

EDIT: It worked! I could build it and test it. Testing results: touch and multi touch work but it's a bit buggy. For example, pinching in google maps works for a second, that stops registering any touch, and a single touch becomes registered with right click. I would say the earlier solution was more reliable. Mind you, I am running it with intermap=nosid and with the experimental ithc I have compiled from earlier.

[StollD]

Is the iptsd from quo you were running before still active by any chance?

[aleksfadini]

Is the iptsd from quo you were running before still active by any chance?

It might indeed be! What would be a way to check on that?

[qzed]

Assuming you've started it via the systemd service, systemctl status iptsd.service. To stop it run systemctl stop iptsd.service.

[aleksfadini]

Thank you, I understand this was obvious in hindsight. After disabling the ipsd service, the functionality is still buggy, but in a slightly different way. I tested extensively, and the pinch motions are particularly buggy (ex. if you pinch 5 times in a row, with the same motion, and pause between pinching, number 3-5 will not work. If you wait longer, pinch 6 will work). . I'd say the @quo iptsd was more stable for multi-touch, but this branch works better for the pen.

For some reason the SP8 Pen now works perfectly, including the back button (eraser). The middle button does nothing. On the other hand, with the @quo iptsd, the pen was buggy (sometimes missing lines) but the middle button was detected, although it would work a bit randomly.

I can make a small video if needed (let me know)

[StollD]

The only touch related difference between the two iptsd's should be this change, that I backported from the C version: https://github.com/linux-surface/iptsd/commit/f20c82b6d8e8acd21ba6b146b424540212e2a771

Could you try reverting the change, and see if that changes the touch behaviour? Run the following command in the iptsd source dir and then rebuild.

$ git revert f20c82b6d8e8acd21ba6b146b424540212e2a771

[aleksfadini]

Thank you very much for digging deeper into this. Just to make sure I am not missing anything, after using the git revert command, when rebuilding I get this:

$ meson build --wrap-mode=forcefallback
Directory already configured.

Just run your build command (e.g. ninja) and Meson will regenerate as necessary.
If ninja fails, run "ninja reconfigure" or "meson --reconfigure"
to force Meson to regenerate.

If build failures persist, run "meson setup --wipe" to rebuild from scratch
using the same options as passed when configuring the build.
To change option values, run "meson configure" instead.
[aleks@AgileFenix iptsd]$ ninja -C build
ninja: Entering directory `build'
[8/8] Linking target src/daemon/iptsd

Was it correctly rebuilt, including the revert changes? Or should I have deleted the build directory entirely after git revert?

Because the same bugginess seems to happen.

EDIT: I tested more extensively, I do think that after the revert, the driver works exactly as it did with the @quo ipts. And I think that one has some bugginess as well, that I hadn't noticed before. I will show it in a video to clarify. On the other hand, the version before git revert had much better pen support: by that I mean that the middle button was ignored, but the drawing was consistent. Now it is a bit more erratic (same that happened with @quo experimental ipts which allowed multitouch)

[aleksfadini]

Showing pinch issues and pen issues in this video. I found a way to reproduce them reliably. The pen is reliably fixed with the latest ipts from @StollD (at the price of losing the pen middle button functionality). Applying git revert mentioned introduces the same pen issues again (which existed in the @quo ipts).

https://youtu.be/96ToS8E6m1s

I would like to clarify that the work you guys are doing is amazing, and the latest branch (before applying git revert) is basically giving us reliable pen and almost-working multitouch, which is great and clearly sufficient to have a great experience on the SP8. If it wasn't for you, I would have never bought this device. (I wish there was a way to make Microsoft aware of this and maybe provide some funding, I'd be happy to reach out to them).

[StollD]

I tested more extensively, I do think that after the revert, the driver works exactly as it did with the @quo ipts.

That is good to know, thank you.

On the other hand, the version before git revert had much better pen support

To be honest, I have no idea why that would happen, giving the reverted commit does not touch anything related to the stylus. Could this be just random differences in behaviour between two test runs?

@qzed found that on Surface Pro X, changing this value from 1000 to 4000 yielded some improvements. Maybe you could try that? https://github.com/linux-surface/iptsd/blob/dft/src/daemon/dft.cpp#L17

https://youtu.be/96ToS8E6m1s

The pinch / zoom issue looks a bit like palm detection is kicking in, marking one contact as a palm. As a safety measure, contacts that were marked as a palm once will stay a palm forever, until they are lifted. This might simply come down to tweaking the thresholds a bit. Make sure that you are not pressing too hard, otherwise it could confuse your finger for a palm.

[StollD]

Issue discussing pen issues on quo's iptsd, for reference: https://github.com/quo/iptsd/issues/5

[StollD]

The pinch / zoom issue looks a bit like palm detection is kicking in, marking one contact as a palm. As a safety measure, contacts that were marked as a palm once will stay a palm forever, until they are lifted. This might simply come down to tweaking the thresholds a bit. Make sure that you are not pressing too hard, otherwise it could confuse your finger for a palm.

I think this might be what is causing your initial issues as well (before the revert of that commit). Its kinda hard to figure out remotely, but I dont have any issues with that commit (and the touch processing between SB2 and SP8 should be identical).

What you could try is switching to the advanced (or "qzed") touch processor. Maybe that can handle your fingers better :P Put this into /etc/ipts.conf

[Touch]
Processing = advanced

[aleksfadini]

What you could try is switching to the advanced (or "qzed") touch processor. Maybe that can handle your fingers better :P Put this into /etc/ipts.conf

[Touch]
Processing = advanced

Indeed, this made multi touch and pinching more reliable for me!!

Furthermore, I did more testing, and using the ipts from dft (and without the git revert command, so really starting from scratch in a new git clone folder, switching to dft), the pen works perfectly (all 3 buttons recognized in krita) and the multitouch almost perfect with the "qzed" processor. The only thing that happens is that after 5 pinches in a row without releasing touch, it gets interpreted as palm rejection as you pointed out.

So the latter would be what I would like as a user to be in the repository - I understand that my single preference is very unimportant in the grand scheme of things and you guys manage this, but that's my 2 cents. In short, it's awesome and everything works with this ipts.conf config above and the latest iptsd/dft. Both pen and multitouch. Speaking for myself, using xorg/i3 and arch.

Would love for someone else to test this as well, and I can help with setting up the test on arch if someone else runs into trouble like I did.

[j4ckgrey]

Is it still happening? are the drivers gonna get included in the Surface Kernal? If so, will the 120hz Edid be included too?

[StollD]

The plan is to merge the drivers into the surface kernel once everything is ready, yes.

Bit offtopic for this, but for the EDID, I dont like the idea of including EDID hacks in the kernel because I think that could get messy and annoying to maintain. I vaguely remember that someone said it works fine on Ubuntu default kernels, which would mean the issue is probably caused by an upstream regression and should be reported / fixed there.

[zed-wong]

Hi @quo, I'm using SP8 running Ubuntu 22.04 and I've done all these:

git clone https://github.com/quo/iptsd
cd iptsd
meson build
ninja -C build
sudo ./build/src/daemon/iptsd

It all went well. The last step shows:

[01:37:18.107] [info] Vendor/product: 045E:0C37
[01:37:18.111] [info] Opened /dev/ithc

But the touch screen still doesn't work. So I tried make set-nosid and it still doesn't work.

$ sudo make set-nosid
make: *** No rule to make target 'set-nosid'.  Stop.

How can I make it work? Thanks!

- Neofetch
OS: Ubuntu 22.04 LTS x86_64
Host: Surface Pro 8 
Kernel: 5.18.12-surface

[StollD]

Are you running that command in the iptsd directory or the ithc-linux directory? You need to run it in the ithc-linux directory.

[zed-wong]

Are you running that command in the iptsd directory or the ithc-linux directory? You need to run it in the ithc-linux directory.

Thank you! I ran it in the ithc-linux directory and it succeed.

echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT intremap=nosid"' > /etc/default/grub.d/intremap-nosid.cfg
update-grub
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Sourcing file `/etc/default/grub.d/intremap-nosid.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.18.12-surface
Found initrd image: /boot/initrd.img-5.18.12-surface
Found linux image: /boot/vmlinuz-5.16.17-surface
Found initrd image: /boot/initrd.img-5.16.17-surface
Found linux image: /boot/vmlinuz-5.15.6-surface
Found initrd image: /boot/initrd.img-5.15.6-surface
Found linux image: /boot/vmlinuz-5.15.0-41-generic
Found initrd image: /boot/initrd.img-5.15.0-41-generic
Memtest86+ needs a 16-bit boot, that is not available on EFI, exiting
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done
sync

But the touchscreen is still not working. I'm gonna try to reboot to see if it works.

[zed-wong]

It's working now! But the multi-touch is not working yet.

[zed-wong]

It's working now! But the multi-touch is not working yet.

I tried the method quo mentioned above. The multi-touch works. I tested three fingers drag up/down/left/right and those are working properly. But two fringers drag up/down, two fingers click and single long press didn't work.

[StollD]

iptsd does not do any gesture detection. It merely determines the positions of all fingers on the display and sends that to userspace. The userspace will then do its own gesture detection.

GNOME Shell for example doesn't have any two finger gestures, only three finger ones. If you want to try a two finger gesture, try zooming in Firefox.

[zed-wong]

iptsd does not do any gesture detection. It merely determines the positions of all fingers on the display and sends that to userspace. The userspace will then do its own gesture detection.

GNOME Shell for example doesn't have any two finger gestures, only three finger ones. If you want to try a two finger gesture, try zooming in Firefox.

Zooming in Firefox doesn't work. It also doesn't work with my touchpad though, have to press on ctrl.