[Surface Pro 4] Touchscreen sensitivity issue

[lululock71]

Hi,

I'm currently having issues with my trash picked SP4. The touchscreen had been fully replaced because a whole area was broken. It had sensitivity issues as well but I found out it seems to be a software issue.

I'm especially having issues with the borders of the screen, which makes some gestures impossible to do, or simply close an app, because the buttons cannot be triggered. As far as I've tested, Chromium seems to be unaffected with this issue for some reason.

I'm currently having the exact opposite of that issue : Surface Pro 4 touchscreen not working properly, ghost touches everywhere

I made a Reddit post here.

Note that Windows 11 has no issue with the touchscreen at all, and the stylus run as well on both Arch Linux and Windows 11.

Here are some technical information :

Model : Surface Pro 4 (1724) OS : Arch Linux x86_64 Kernel : 6.3.3-arch1-1-surface DE : Plasma 5.27.5 (Wayland)

Log : ipts-log.zip During that test, I tried to focus on the borders of the screen, hence this is where I had the most issues. If you need more specific logs, I can test and provide.

Config File :

[Config]
##
## The following values are device specific and will be loaded from /usr/share/iptsd
## Only set them if you need to provide custom values for new devices that are not yet supported
##
# InvertX = false
# InvertY = false
# Width = 0
# Height = 0

[Touch]
##
## Disables the touchscreen. No touch data will be processed.
##
# Disable = false

##
## Mark contacts around the stylus as palms.
##
# CheckCone = true

##
## Ignore all touch inputs if a palm was registered on the display.
##
# DisableOnPalm = false

##
## Ignore all touch inputs if a stylus is in proximity.
##
# DisableOnStylus = false

[Contacts]
##
## How the neutral value of the heatmap will be determined.
## The neutral value is the value in the heatmap that marks regions without activity.
## Pixels with a value larger than the neutral value are considered for blob detection.
##
## Mode: The most common value from the heatmap will be used.
## Average: The average of all values from the heatmap will be used.
## Constant: The value from the NeutralValue option will be used.
##
## When this option is set to Mode or Average, the NeutralValue option can be used
## to specify an offset that will be added on top of the calculated value.
##
# Neutral = mode

##
## The neutral value of the touch sensor (Range 0 - 255).
##
# NeutralValue = 0

##
## The activation threshold for blob detection (Range 0 - 255).
## If a pixel of the heatmap is larger than this value plus the neutral value, the blob detector
## will mark the pixel as a contact and try to determine its size.
##
## This value is only used by the basic blob detector.
##
# ActivationThreshold = 24

##
## The deactiviation threshold for blob detection (Range 0 - 255).
## Once the blob detector has identified a contact it will look for adjacent pixels. If the value
## of the pixel is larger than this value plus the neutral value, it will be added to the contact.
##
## This value is only used by the basic blob detector.
##
# DeactivationThreshold = 20

##
## The temporal window for determining temporal stability of a contact.
## A contact that has not been active for the specified amount of frames is skipped.
##
# TemporalWindow = 3

##
## The minimal diameter a contact must have.
##
# SizeMin = 0.2

##
## The maximal diameter a contact can have.
##
# SizeMax = 2.0

##
## The minimal aspect ratio a contact must have.
##
# AspectMin = 1.0

##
## The maximal aspect ratio a contact can have.
##
# AspectMax = 2.5

##
## How many centimeters a contact can increase in size to be considered stable.
## Size changes above this threshold are ignored.
##
# SizeThreshold = 0.1

##
## How many centimeters a contact must move before the movement is considered stable.
## Movements below this threshold are ignored.
##
# PositionThresholdMin = 0.2

##
## How many centimeters a contact can move before the movement is considered unstable.
## Movements above this threshold are ignored.
##
# PositionThresholdMax = 2

[Stylus]
##
## Disables the stylus. No stylus data will be processed.
##
# Disable = false

##
## The distance between the stylus tip and the position transmitter, in centimeters.
## This setting adds a tilt-derived offset to the position reported by the stylus,
## with the goal of aligning it to the tip of the pen. The higher this value and / or
## the tilt of the stylus, the higher the offset will be.
##
# TipDistance = 0

[Cone]
##
## The wideness of the cone in degrees.
##
# Angle = 30

##
## How many centimeters a contact must be away from the stylus to not get blocked.
##
# Distance = 5

[DFT]
# PositionMinAmp = 50
# PositionMinMag = 2000
# PositionExp = -0.7
# ButtonMinMag = 1000
# FreqMinMag = 10000

Finger VS Stylus Test : Here, I just generated a blank canvas, put Krita in fullscreen mode (hidden interface) and ran my finger around the screen. Then, I took my stylus (Wacom Bamboo Ink v2) and did the same. Blue is my finger, red is the stylus. Even tho I can't do a straight line with neither my finger or the stylus, we can see that the stylus input is way cleaner than the finger (I don't know if this is intended behavior). Weirdly enough, Krita gets input from the top right corner, while KDE is not.

I have another SP4 which needs reassembly. I can try if it has the same issue as well if needed.

EDIT : I just remembered that according to the seller I bought the screen from, it is supposed to be a SP5 screen (LG model) with a different display ribbon. But I still use the Ntrig board from the old screen because the new one didn't work. I don't know if it is worth mentioning.

[StollD]

I took a look at the data you recorded and to me it mostly seems fine. No ghost touches, and no touches that get misdetected as palms.

I see three main issues here: jitter, stability, and the screen border itself.

That the contacts iptsd reports jitter a lot is a known issue: https://github.com/linux-surface/iptsd/issues/127. If you want, you could try the latest development build, which contains a fix for this: https://github.com/linux-surface/iptsd/actions/runs/5090530045, scroll down and download the artifact <your-distro>-latest, inside is a package you can install.

iptsd considers contacts unstable if they were not registered for three consecutive frames. In your data, sometimes you lift your finger extremely fast so that iptsd only sees the contact for two or one frame and discards it. You could try to lower the TemporalWindow option to 2 and see if that improves things for you.

The touch processing code relies on finding clusters of pixels that are above a certain threshold, and then fitting an ellipse onto it. It happens to work mostly ok on the screen border, where it can only see half of the actual contact, but there can be some inaccuracies.

All of these can play some role here. As you noticed, the touchscreen works in Krita, so it is most likely, that something is happening that confuses KDE and causes it to ignore your inputs. Maybe the jitter causes it to think you are doing some sort of gesture. Or maybe iptsd doesnt report the contact if you tap to close an app. Or the contact is detected as being so large that it goes over all three buttons and KDE doesn't know what it should actually do.

Sadly I dont really know what to recommend in this case. I also use KDE, on a Surface Book 2, and minimizing a fullscreen window with the touchscreen works fine. Maybe I have conditioned my fingers to touch a slightly lower spot when aiming for the window controls, thats something you could try. Or the development build that I linked above. That should definitly fix the jitter in Krita.

[lululock71]

Thank you for your reply.

I just tried the package you linked me and it doesn't seem to help with my specific issue. I'm not even sure if it helped with the jitter.

I did the same test again in Krita (green line) and I see no real difference with before (blue line) :

I also tried modifying the TemporalWindow value to 2 as you mentioned but it also didn't help.

I have indeed noticed that sometimes, I can reach the window buttons if I click slightly lower than the button itself but it often get "caught" by other buttons bellow. I just tried to change the screen scaling to 225% (from 200%) in hope that the title bar would get bigger but after a reboot, the touchscreen doesn't work at all. Putting scaling back to 200%, reboot, the screen works as before... Scaling to 300% is way too big to be practical and 100% is insanely small.

I also noticed that I have to "hold" the touch for about 1s to see the button getting highlighted by the press.

Looks like some mess between drivers, KDE and Wayland...

Maybe a custom KDE theme with bigger title bar icons would help in my case in the meantime, but it feels very hacky.

EDIT : Found a setting in the Window decoration menu to increase the size of the title bar icons but it doesn't affect Firefox...

EDIT 2 : Found a quick "fix" to increase Firefox title bar icon size. That doesn't help with the initial issue but it makes the touchscreen much more usable for me. Sharing this trick here if the other fixes mentioned here didn't help.

[StollD]

Recent versions of KDE have a tablet mode that makes the interface easier to use with a touchscreen. It increases the size of the title bar and adds more spacing between the buttons. For me it enables automatically when I detach the keyboard, but you can configure it in the system settings (under workspace settings, or simply search for tablet).

[lululock71]

Tablet mode works out of the box with the SP4, just apps like Firefox don't react correctly to it because it is GTK based.