linux-surface / iptsd

Userspace daemon for Intel Precise Touch & Stylus
GNU General Public License v2.0
86 stars 39 forks source link

Need to disable multi-touch #91

Open horvathcsabalaszlo opened 1 year ago

horvathcsabalaszlo commented 1 year ago

Hi,

I have getting constant ghost touches on Surface 4 pro (think because of heating). This makes the device unusable. (On the virtual keyboard, i can see some keys are constantly pressed, in selection mode random presses are shown.) No matter how hot the device is, the BIOS and the boot screen keyboard works fine, without ghost touches.

Is there any wan to disable the multi-touch support only? Simply stopping the iptsd service stops the whole touch input. iptsd-reset-sensor also.

I'm running KDE neon, 20.04, which is basically Ubuntu/Debian. I tried newer and older versions from
https://github.com/linux-surface/iptsd/actions but does not install because of dependencies, or does not work at all.

Is there any way to disable the multi-touch feature? Or are there any parameters to pass to the iptsd demon to do some fine-tuning?

As i read that stopping the service should only disable multi-touch, i think that there should be another driver in the kernel, but how? Maybe it is missing. During the installation, the touch did not work, so i think it is missing from Kubuntu/KDE neon by default.

Thanks for any help :)

NP-chaonay commented 1 year ago

is that the same device as this?

https://github.com/linux-surface/iptsd/issues/82#issuecomment-1288151460

horvathcsabalaszlo commented 1 year ago

is that the same device as this?

#82 (comment)

Yes. I have done some tests (previously many things were misleading), replaced LCD, and it's almost perfect now, but would be good to have a single-touch solutions, because even the faulty screen was working good in the BIOS.

Maybe single-touch mode was there in intel-ipts module? And it's not in iptsd?

horvathcsabalaszlo commented 1 year ago

Another observations : No ghost touches with the new screen until the CPU heats really up. Around 60 degs it touched itself like crazy. Will try to add insulation... But again, no matter how hot is the tablet, the BIOS and boot screen keyboard is OK. So single-touch mode will be a salvation :D

Another strange thing is that if the screen is somewhat lifted, and the CPU temperature is high, the ghost touches also appear. But this is completely nonsense, as the screen is cold... But if i press the screen longer, they began to spread.

With KDE's desktop effects (mouse tracking, touch visualization) one can see where the ghost touches appear 8-O

NP-chaonay commented 1 year ago

@horvathcsabalaszlo

As i read that stopping the service should only disable multi-touch,

idk if some older device/driver have different behaviour that it entirely disable all when iptsd usersapce service is stopped

i think that there should be another driver in the kernel,

absolutely sure, with out kernel driver (driver in kernel) you cannot have methods for kernel/OS/system to communicate to device, so iptsd userpsace service would not communicate it too.

so i think it is missing from Kubuntu/KDE neon by default.

idk about this whether it is existed by default or not, and I may not understand this correctly

but what I have said recently about intel-precise-touch/iptsd installation is should be enough to make the driver and iptsd installed and ready to use after next reboot. (which your case is done but not work properly T_T)

(previously many things were misleading)

ok

but would be good to have a single-touch solutions, because even the faulty screen was working good in the BIOS. Maybe single-touch mode was there in intel-ipts module? And it's not in iptsd?

same as reply to As i read that stopping the service should only disable multi-touch,

with addition that in my device (SLS) with the driver from quo and old quo's version of iptsd service; I can put in single mode when iptsd is not getting data from driver. This may acts diffferently accross driver/devices.

But again, no matter how hot is the tablet, the BIOS and boot screen keyboard is OK. So single-touch mode will be a salvation :D

I am bet about 75% that it is iptsd/driver problem not hw, If I not rememeber wrong, this have also affected by some devices some driver (but idk if he/she using iptsd or in single mode) on linux.

I think it is problem on cutting signal noise from driver data. so if single mode only work and used, iif the problem still existed then probably driver problem, or else the iptsd problem.

Ok two last thing 1) Im using SLS Ubuntu on quo driver (not latest now) wiht old quo's version of iptsd (the latest iptasd is not in quo's repo now but in linux-surface github repo), no ghost touches ever happens 2) the issue #82 I think this shoud be closed and link that to this page instead. the non-parametrices iptsd is come from old version of iptsd, If i not wrong nowaday iptsd have only parameterized method.

horvathcsabalaszlo commented 1 year ago

Yes, the #82 can be closed. This is quite a duplicate.

"so i think it is missing from Kubuntu/KDE neon by default.

idk about this whether it is existed by default or not, and I may not understand this correctly

but what I have said recently about intel-precise-touch/iptsd installation is should be enough to make the driver and iptsd installed and ready to use after next reboot. (which your case is done but not work properly T_T)"

I mean that as i remember, until 5.3 kernel the intel ipts module was in use; maybe that provided a single-touch interface when the daemon wasn't running, or so. Don't know, because i'm digging into iptsd since the troubles began :D

The problem is with newer drivers that ifi install from the Git, it simply does not work; it should be a dependency, what is missing in KDE Neon 20.04

"I am bet about 75% that it is iptsd/driver problem not hw, If I not rememeber wrong, this have also affected by some devices some driver (but idk if he/she using iptsd or in single mode) on linux." I think it's both. On Sf Pro 4, it is a common problem that the screen has ghost touches, because of heating. Some undervoltage helps, but not finally. And if i turn on the touch marking in KDE, it can be clearly seen that red marks are coming on random places when the screen is hot, and the length of touch is over a threshold. KDE marks first touch with blue, and second with red, the ghosts are mostly red. But for some reason, ghost touches never appear in the BIOS or on the "Surface" screen, where a virtual keyboard is present. No matter, how hot is the machine.

"I think it is problem on cutting signal noise from driver data. so if single mode only work and used, iif the problem still existed then probably driver problem, or else the iptsd problem." Yes, but the driver problem means it can be corrected :) HW error will be a harder deal :)

Maybe i must try Neon 22.04, or latest Debian, which is compatible with newer modules. To fight heating, undervoltage is not possible because of the fw, but a lighter OS is.

Thanks for your help :)

horvathcsabalaszlo commented 1 year ago

Had time to test with Windows with the previous faulty screen. No or minimal ghost touches, no matter how hot is the screen and system. Maybe the Windows driver is in single-touch mode. At least it did not do anything with two fingers. (But on Linux it doesn't also.) After Windows, installed Debian, ghost touches came back. Tried to install the Git version (Debian bullseye 11.5), and did not work at all.

NP-chaonay commented 1 year ago

@horvathcsabalaszlo

provided a single-touch interface when the daemon wasn't running, or so.

on ithc driver, it does that, but since your device is SP4 so the used driver is not ithc but ipts, and as have said, idk if the driver auto set single mode approch in case daemon shutdowned.

But maybe good idea to implement that into ipts.

The problem is with newer drivers that ifi install from the Git, it simply does not work; it should be a dependency, what is missing in KDE Neon 20.04

wait so does that mean the ipts driver from github that I let you install, dont work? if yes then could you tell what is the error during building/install

But for some reason, ghost touches never appear in the BIOS or on the "Surface" screen, where a virtual keyboard is present. No matter, how hot is the machine.

For some case, it is not necessary to be HW bug,

maybe MS may already know that the significant noise is come from heat,

and they have made EFI driver

(that operates touching during in Surface UEFI an EFI bootloder such as grub)

that have avoid that noise,

noted that that EFI driver is loaded by Surface UEFI and in used until it pass controll from EFI mode to OS (such as Windows/Linux kernel).

So for this mentioned case (HW noise is existed but EFI driver can handle it)

maybe or not maybe that it is hw flaw,

but the main point is not from the hw itself,

so for this case then it should be that Windows driver can handle it good as well.

To re-saying, if both EFI/Windows drivers do good job, then I cannot say it is hw flaw as a main point of problem,

because all MS-made driver can able to handle it, and this should be managed by Linux driver instead (which will becoming todo bug of linux driver)

PS: pls staytuned for this comment, I editing in place. PS2: okey I have finsihed editing in placed, because I gonna put remianed in another new comment

horvathcsabalaszlo commented 1 year ago

Yes, it would be a good feature. Another thing which helped me a little to lift the priority of iptsd .)

NP-chaonay commented 1 year ago

@horvathcsabalaszlo continue from that comment

Yes, but the driver problem means it can be corrected :) HW error will be a harder deal :)

🎯In real world problem, not every HW error necessary to be sovled by fix at HW level, some case can be fix (as workaround or even as non-workaround solution)

🎯Example on x86 cpu there is security vulnerability of meltdown/spectre, currently there is no published HW that have that fix on the HW, so I mean that every x86 CPU we using nowaday have security vulnerability,

but calm down, the vulnerability got patched and prevented by workaround of kernel (on part of estimately CPU/memory management part)

🎯when I talk about workaround, IMO it is mean that it may not be suitable to be permanent but we have to do this solution as this moment of time or due to some limitation, so when that limitation is gone then we may wanna making bettter solution

IMO on another defination of workaround is that the solution should be fixed by the other side (other from our side) too, but the other side wont fix it or cant fix due to any limitation, the example of the limitation is I have made game console emulator, but due to something the bug occured on side of console manufacturer, but that that console manufacturer wont fix it because it the company is not discontinued the product.

🎯For example I create Intel GPU driver but there is problem on Win11 desktop renderer but not have problem on Linux/other OS.

I found later that the problemitself dont have main problem on hardware but the Win11 itself,

but since Microsoft cannot fix the bug in time, it is required that Intel have to do workaround by changing something on their driver, and waiting for MS fixing it

(so if MS dont fix it because MS rely on Intel workaround and not wanna fix it without that workaround, then it is assumed that the workaround have to enabled until the problem got solved either by the problem or something related chnages)

Maybe i must try Neon 22.04, or latest Debian, which is compatible with newer modules. To fight heating, undervoltage is not possible because of the fw, but a lighter OS is.

Personally I recommended Ubuntu, btw fighting heating will be passived solution and maybe not worth it if that main point of problem comes from iptsd/driver that cannot cutting out the noise of HW.

The another way that I want to give a try for undervoltage is to reduce min/max clock speed of both CPU/GPU

so let this a try CPUmin=(at minimum as possible) CPUmax=1Ghz GPUmin=(at minimum as possible) GPUmax=(at minimum as possible but increase the value if it make graphic fps too low for your satisfaction)

NP-chaonay commented 1 year ago

also pls give booting to non-surface kernel a try

but first make sure that github ipts driver and iptsd is correctly installed before trying this trick

I have seen report in linux-surface matrix member saying this work

horvathcsabalaszlo commented 1 year ago

Yes, i exactly meant that the touch problems can be corrected on SW level :) (For processors, there are AMD ones which suffer much less from the brach prediction security problems :D ) Anyway, if the driver's noise filtering is not perfect, it worth to help it while the device is in daily use :)

I tried the simplest undervolting, as run the Surface from battery - it lowers the clock then :) It can heat up to have ghost touches, but not much as from wall power.

I'll try the non-surface kernel on a test device, next week :)

NP-chaonay commented 1 year ago

which is stable; i have seen that no matter how hot is the tablet, in the BIOS and boot screen the touch is reliable.

from: https://github.com/linux-surface/iptsd/issues/89#issuecomment-1292552720

I waana tell you something idk if you got it before. (idk even have I tell this btw)

disable multimode maynot solve it if problem of noise filtering is cause at driver

since EFI driver and linux driver (which operate in single mode) is different ones

StollD commented 1 year ago

So, basically:

With the kernel driver and the iptsd that are shipped in the repositories, the hardware will always run in multitouch mode. Multitouch mode means, that the device will not generate coordinates. Instead it generates capacitive heatmap data, which can tell which areas of the screen are currently touched. To convert this data into coordinates, you need to process it (basically you run blob detection and then try to detect and filter out everything that doesnt look like a finger).

What can happen is that the touchscreen automatically recalibrates itself, and as a result becomes more sensitive towards electicity. This can happen for example if you suspend the device and the touchpad and the touchscreen are close to each other. Both use the same technology, so they interfere. If the touchscreen recalibrates itself, it will produce noise in the heatmap. Because the processing in iptsd is self-made, it does not have any noise reduction capabilities. Nor does it have the ability to calibrate the touchscreen sensor manually.

The only way to fix this issue without rebooting is by issuing a reset command to the sensor. In the iptsd from the repo that can be done by calling iptsd-reset-sensor.

In the new iptsd, some things are handled differently. Firstly: The iptsd from the master branche will NOT work with the kernel driver that is shipped in the repo. You MUST install the ipts driver from the master branch of https://github.com/linux-surface/intel-precise-touch

Second: The new driver will reset the sensor more often, so after suspending it should not go crazy anymore. iptsd-reset-sensor doesnt exist anymore.

Third: The new driver will automatically set the hardware to singletouch mode. This means that the heatmap processing is done in firmware, with proper noise reduction. iptsd will manually change the hardware to multitouch mode when it starts, and go back to singletouch mode when it stops.

So to answer your question: If you want to disable multitouch you dont need iptsd. Building and installing the ipts kernel driver from its master branch will already give you working singletouch. If you want multitouch with the new driver, you will need to install and start the iptsd from github actions. To revert to singletouch, just stop iptsd again.

horvathcsabalaszlo commented 1 year ago

Thanks @StollD :)

"Instead it generates capacitive heatmap data, which can tell which areas of the screen are currently touched." Oh, thanks :) I only have seen the data which evtest spits out, and that seemed to something which can be processed as touch coordinates.

iptsd-reset sensor, as i mentioned in the other post, is strange here. For first run, it worked fine, but for second, it completely disabled the touch. Previously when i tried, it always destroyed the touch interface. Strange...

Thanks for clarification on the kernel and driver; i'll try the new driver and kernel next week. And maybe soon that will be in the repo also.

"Third: The new driver will automatically set the hardware to singletouch mode." That's what i'm waiting for :) And singletouch also :)

horvathcsabalaszlo commented 1 year ago

In the new iptsd, some things are handled differently. Firstly: The iptsd from the master branche will NOT work with the kernel driver that is shipped in the repo. You MUST install the ipts driver from the master branch of https://github.com/linux-surface/intel-precise-touch

Yeah, thanks! This was the information i needed :) Built the driver, install was fine, and it is working without iptsd, and seems stable on 100% brightness, which killed the previous version quickly. Will test further, but it's seeming OK! :)