IPTSD connects then stops with error "Tried to read more data than available!"

[jtrenaud1s]

Device: SP7 Intel Core i5 Kernel Version: linux-surface-5.19.4 OS: Ubuntu 22.04 Other package/modules built/installed:

• ipts (in-tree)
• ipts via dkms built from source linux-surface/iptsd@master (assumed it replaces the in-tree version)

Previously this wasn't a problem.

I built using meson, pre-installed all dependencies except for hidrd, allowing meson to clone and build it. I tested by running the daemon directly with /dev/hidraw1, it connected (though the pen didn't work)

After that test, I installed it to the system with sudo ninja -C build install && reboot

At this point, the status of the iptsd service was "masked" and "inactive", and I was unable to start it manually.

I opted to uninstall and reinstall. I still have the "masked" and "inactive" issue, but now I also can't run the daemon from the build folder manually without getting this:

$ sudo ./build/src/daemon/iptsd /dev/hidraw1
[15:31:18.827] [info] Connected to device 045E:099F
[15:31:19.671] [error] Tried to read more data than available!
[15:31:19.671] [info] Stopping

I'm using ipts built from source using dkms because otherwise the signing key would be rejected when adding it to the kernel

dmesg output:

sudo dmesg | grep "ipts\|IPTS"
[    3.517316] ipts: loading out-of-tree module taints kernel.
[    3.558221] ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: Starting IPTS
[    3.561435] ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: IPTS EDS Version: 2
[    3.568198] ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: IPTS running in doorbell mode
[    3.585150] input: IPTS 045E:099F as /devices/pci0000:00/0000:00:16.4/0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04/0000:045E:099F.0003/input/input11
[    3.610047] input: IPTS 045E:099F UNKNOWN as /devices/pci0000:00/0000:00:16.4/0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04/0000:045E:099F.0003/input/input33
[    3.610262] input: IPTS 045E:099F Stylus as /devices/pci0000:00/0000:00:16.4/0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04/0000:045E:099F.0003/input/input35
[    3.819989] hid-multitouch 0000:045E:099F.0003: input,hidraw1: <UNKNOWN> HID v0.00 Device [IPTS 045E:099F] on 
[    4.116815] input: IPTS Touch as /devices/virtual/input/input59
[    4.116928] input: IPTS Stylus as /devices/virtual/input/input60
[    4.573696] ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: Error while reading response: 0
[  347.077588] input: IPTS Touch as /devices/virtual/input/input82
[  347.078027] input: IPTS Stylus as /devices/virtual/input/input83
[  439.455095] input: IPTS Touch as /devices/virtual/input/input84
[  439.455411] input: IPTS Stylus as /devices/virtual/input/input85
[  937.049374] input: IPTS Touch as /devices/virtual/input/input86
[  937.049622] input: IPTS Stylus as /devices/virtual/input/input87

I'm noticing the extra IPTS Touch and IPTS Stylus for the first time as I type this, I assume it's from the various reinstallations.

My guess as of now is that the multiple inputs are multiplying the data and this is why I get "Tried to read more data than available" but I could be very wrong about that.

iptsd service status:

$ sudo service iptsd status
○ iptsd.service
     Loaded: masked (Reason: Unit iptsd.service is masked.)
     Active: inactive (dead)

Regardless, even when I wasn't having this issue, the pen wasn't working.

[Pairman]

Something is wrong with the auto generated iptsd.service file. It's not tuned and is left with an undefined argument. Modify the iptsd.service and delete iptsd@.service manually works for me.

My iptsd.service is like this

[Unit]
Description=Intel Precise Touch & Stylus Daemon

[Service]
User=pairman
ExecStart=/usr/local/bin/iptsd /dev/hidrawN

[Install]
WantedBy=multi-user.target

[StollD]

You are not supposed to launch iptsd manually, it is supposed to be launched through udev when it detects a hidraw device created by one of the supported drivers. The service file is parameterized, because the number of the hidraw device is not static.

So to check the status of IPTS you need to run something like sudo systemctl status iptsd@-dev-hidraw1.service, depending on your actual hidraw device.

Regarding your error, there are some changes in quos iptsd fork that I didnt port, one deals with invalid data being sent on Surface Pro 7. Howerver, I would like to rule out one thing first: Could you check if there is already an iptsd instance running (ps aux | grep iptsd)? Two instances of the daemon could interfere with each other and cause the error you reported.

[NP-chaonay]

I tested by running the daemon directly with /dev/hidraw1, it connected (though the pen didn't work)

weird...

At this point, the status of the iptsd service was "masked" and "inactive", and I was unable to start it manually.

idk if this because of new improvement to linux-surface/iptsd that make ipstd service is parameterized (see above)

I'm using ipts built from source using dkms because otherwise the signing key would be rejected when adding it to the kernel

https://github.com/linux-surface/linux-surface/issues/906 (idk if you affected from that issue, however let others helps you about that since I not experience enough about SecureBoot.) I think this issue is not resolved yet (I have not read it entirely, it so long), so the better resolution for me is to disable secure boot entirely,

and if I not wrong >=SP7 gen required compiled from linux-surface/iptsd GitHub source (or compiled one from GitHub action of that repo), the pkg from linux-surface pkg repo wont work I think at thsi moment..

[ 4.573696] ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: Error while reading response: 0

idk if this making your root problem

My guess as of now is that the multiple inputs are multiplying the data and this is why I get "Tried to read more data than available" but I could be very wrong about that.

maybe youre right about that ( My guess as of now is that the multiple inputs are multiplying the data and this is why I get "Tried to read more data than available" )

Regardless, even when I wasn't having this issue, the pen wasn't working.

so you want to tell that before that multitouch work? But pen should work too, does not it?

[NP-chaonay]

You are not supposed to launch iptsd manually, it is supposed to be launched through udev when it detects a hidraw device created by one of the supported drivers. The service file is parameterized, because the number of the hidraw device is not static.

I think he/she's outdated

@Pairman

that now only work on old version of quo/ipstd pls read what Dorian Stoll have said

[NP-chaonay]

and if I not wrong >=SP7 gen required compiled from linux-surface/iptsd GitHub source (or compiled one from GitHub action of that repo), the pkg from linux-surface pkg repo wont work I think at thsi moment..

fix that old commit (if not newer one) of quo/iptsd work too. IF I not wrong, you may mean that before using new commit of linux-surface/iptsd; you using quo/iptsd.

However why pen dont working on quo/iptsd? werid for me at this moment

[Pairman]

You are not supposed to launch iptsd manually, it is supposed to be launched through udev when it detects a hidraw device created by one of the supported drivers. The service file is parameterized, because the number of the hidraw device is not static.

I think he/she's outdated

@Pairman

that now only work on old version of quo/ipstd pls read what Dorian Stoll have said

😳

[Pairman]

You are not supposed to launch iptsd manually, it is supposed to be launched through udev when it detects a hidraw device created by one of the supported drivers. The service file is parameterized, because the number of the hidraw device is not static.

I think he/she's outdated

@Pairman

that now only work on old version of quo/ipstd pls read what Dorian Stoll have said

Idk how, or udev itself never detect my device automatically. I can only get iptsd work manually.

[pairman@fedora ~]$ sudo systemctl status iptsd@-dev-hidraw1.service
[sudo] password for pairman: 
Unit iptsd@-dev-hidraw1.service could not be found.

[NP-chaonay]

You are not supposed to launch iptsd manually, it is supposed to be launched through udev when it detects a hidraw device created by one of the supported drivers. The service file is parameterized, because the number of the hidraw device is not static.

I think he/she's outdated @Pairman that now only work on old version of quo/ipstd pls read what Dorian Stoll have said

Idk how, or udev itself never detect my device automatically. I can only get iptsd work manually.

[pairman@fedora ~]$ sudo systemctl status iptsd@-dev-hidraw1.service
[sudo] password for pairman: 
Unit iptsd@-dev-hidraw1.service could not be found.

have you using newer version iptsd from linux-surface? if not then I have to explain more thing.

I also used to outdated, but since I oftenly monitor linux-surface/linux-surface linux-surface/iptsd quo/iptsd quo/ithc-linux repo with ALL NOTIFICATION. I know what is going on. so If not like me, then it is outdated and have long time before getting that the thing have chnaged further.

[Pairman]

have you using newer version iptsd from linux-surface? if not then I have to explain more thing.

I also used to outdated, but since I oftenly monitor linux-surface/linux-surface linux-surface/iptsd quo/iptsd quo/ithc-linux repo with ALL NOTIFICATION. I know what is going on. so If not like me, then it is outdated and have long time before getting that the thing have chnaged further.

I git pull everytime and so it's weird. I have to manually put ExecStart=/usr/local/bin/iptsd /dev/hidraw1 in iptsd.service.

[NP-chaonay]

have you using newer version iptsd from linux-surface? if not then I have to explain more thing. I also used to outdated, but since I oftenly monitor linux-surface/linux-surface linux-surface/iptsd quo/iptsd quo/ithc-linux repo with ALL NOTIFICATION. I know what is going on. so If not like me, then it is outdated and have long time before getting that the thing have chnaged further.

I git pull everytime and so it's weird. I have to manually put ExecStart=/usr/local/bin/iptsd /dev/hidraw1 in iptsd.service.

... git pull from linux-surface/iptsd everytime. so weird idk maybe wait someone tell about it.

Ok but now you know that there is change about iptsd. maybe you may want to ask this problem in linux-surface matrix communication ch. idk but that is not good workaround since I think hidraw of same device can using another number in some case on further later time.

[jtrenaud1s]

I'm using the linux-surface/iptsd repo, not quo. Should I be using quo? I've got the latest 1.19.4 version of the kernel so the issue with key signing and secure boot should have been fixed according to a response to one of my previous issues on linux-surface.

I can't confirm whether multi-touch is working. So far I've only managed to have one touch at a time detected, any than one finger and it does nothing, so no pinch zooming on supported applications. The pen connects to bluetooth fine. actions performed with the pen are not detected (as far as I know, I wouldn't know what to grep to find those logs).

I'd like to know why there are multiple copies of the devices, and how I can remove extras while leaving two working devices.

[jtrenaud1s]

Oh, and when I say I ran iptsd manually, I used the command on the readme, to test it and determine which hidraw device represented the screen.

To run iptsd, you need to determine the ID of the hidraw device of your touchscreen:

$ sudo dmesg | grep hidraw

You can then run iptsd with the device path as a launch argument:

$ sudo ./build/src/daemon/iptsd /dev/hidrawN

[NP-chaonay]

Should I be using quo?

no need since that is deprecated due to have already merged to linux-surface/iptsd

secure boot

idk if that make thing fail bu it should only affect the touch driver not iptsd so if that make thing fail, single touch mode must not wrok too.

actions performed with the pen are not detected (as far as I know, I wouldn't know what to grep to find those logs).

surface slim pen 2?, if yes then the bluetooth making input device it send kind of function key but beyond F12, so currently If I not wrong, it no driver/daemon managing that. And If i not wrong, no linux app make used of pen button ( button that work via bluetooth), so if you have that daemon handling it, you would just to link to some app/script launching or tweaking something yourself if you want.

multiple copies of the devices

check first list of running service, does iptsd using >=2 service?

[StollD]

The multiple entires in dmesg come from iptsd stopping and starting. Every time it starts it creates two new virtual devices.

If there are actually two sets of devices active at the same time (e.g. selectable in sudo evtest), then you have two iptsd instances running.

[StollD]

Regarding the data error, could you please run sudo iptsd-dump /dev/hidrawN data.bin, then touch the display with two fingers, stop the program again and upload the data.bin file?

[StollD]

You could also try the changes I just pushed to the master branch, they might be able to fix this issue.

[jtrenaud1s]

You could also try the changes I just pushed to the master branch, they might be able to fix this issue.

After pulling and recompiling, the stylus works, and multitouch appears to work, managed to zoom out of firefox. The pen is being treated as the mouse (the cursor follows it). I wasn't able to use iptsd-dump for some reason.

EDIT: Pen pressure detection also works.

Eraser end works but (at least in openBoard whiteboard app) constantly swaps between the pen and eraser mode while trying to erase.

[qzed]

The pen is being treated as the mouse (the cursor follows it).

That's the way it's handled by the desktop environment and/or applications. It usually falls back to a "mouse" when there's no special pen handling.

Eraser end works but (at least in openBoard whiteboard app) constantly swaps between the pen and eraser mode while trying to erase.

IIRC you can try tuning the ButtonMinMag config option in the DFT section for that. By default that is 1000. Lowering it should make both the side-button and eraser more sensitive. Unfortunately there isn't any option to tune them separately at the moment.

[NP-chaonay]

The pen is being treated as the mouse (the cursor follows it).

That's the way it's handled by the desktop environment and/or applications. It usually falls back to a "mouse" when there's no special pen handling.

Eraser end works but (at least in openBoard whiteboard app) constantly swaps between the pen and eraser mode while trying to erase.

IIRC you can try tuning the ButtonMinMag config option in the DFT section for that. By default that is 1000. Lowering it should make both the side-button and eraser more sensitive. Unfortunately there isn't any option to tune them separately at the moment.

could I ask this, does side-button have pressure thing too? I'm using surface slim pen 2

[qzed]

Not as far as I know. It's just on/off i.e., above/below the specified magnitude.