search

linux-surface / iptsd

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

[Pro 2017] Finger detection unstable. #10

Open tarmack opened 4 years ago

tarmack commented 4 years ago

On the Surface Pro 2017 the finger detection is unstable. When touching the screen the finger gets detected fine and the location is pretty stable however, for short intervals (one frame?) the finger gets "not detected".

I removed palm/thumb marking of the touch points to see if the finger got marked isPalm accidentally, it did not make a difference.

Does anybody have an idea on how to go about debugging this?

tmarkov commented 4 years ago

Besides being marked IsPalm, there is one more case when a touch can be ignored: if the contact area is increasing rapidly, see https://github.com/linux-surface/iptsd/blob/master/touch.go#L26.

The idea is, when placing a palm, at the very beginning the contact area may be small enough to think it's a finger and trigger a click. But sometimes, usually for a single frame, that can also activate during regular touch, and cause it to skip a frame.

You can make sure that's the problem by commenting out this check. If so, it should be possible to fix that by making that check apply only to "new" touches. In what cases does that actually pose a problem?

tarmack commented 4 years ago

I changed both the GetPalm() to return directly and commented the section you mentioned. These changes do not resolve the issue.

Can anyone help me get detailed debug information so that I can chase the location where the glitch could originate? Are there detection thresholds or resolution knobs that I can play with to see if that can improve the situation?

StollD commented 4 years ago

You could try reducing the threshold here: https://github.com/linux-surface/iptsd/blob/2de748df81ec82df39d3fb009a8ecc92625dab59/processing/contact.go#L4

Although I am not 100% sure what impact this has with the new contact detection algorithm. IIRC during testing, when I increased the value I had to put more pressure onto the screen to cause a touch event, so maybe lowering it could help in this case?

tarmack commented 4 years ago

Reducing the touch threshold did not make a difference (it did make ghost appear when I lowered it enough). I am putting the evtest output I posted in issue #11 here as that was actually single touch and I am getting my issues confused.

Looking at it with evtest, I suspect that the portion below may help in finding the issue:

Event: time 1594587835.910232, -------------- SYN_REPORT ------------
Event: time 1594587835.923414, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 7142
Event: time 1594587835.923414, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 1298
Event: time 1594587835.923414, -------------- SYN_REPORT ------------
Event: time 1594587835.924158, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1594587835.924158, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 0
Event: time 1594587835.924158, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 0
Event: time 1594587835.924158, -------------- SYN_REPORT ------------
Event: time 1594587835.924768, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 0
Event: time 1594587835.924768, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 7141
Event: time 1594587835.924768, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 1296

It looks like id -1 shines trough, if I'm not mistaken that is an internal value to mark touches that are duplicates.

I also noticed this section where the reports seem to get split, although that could just be an output thing?

Event: time 1594587834.800965, -------------- SYN_REPORT ------------
Event: time 1594587834.801807, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 1302
Event: time 1594587834.801807, -------------- SYN_REPORT ------------
Event: time 1594587834.813589, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 7147
Event: time 1594587834.813589, -------------- SYN_REPORT ------------
Event: time 1594587834.826758, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 7146
Event: time 1594587834.826758, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 1303
Event: time 1594587834.826758, -------------- SYN_REPORT ------------
Event: time 1594587834.839983, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 1304
Event: time 1594587834.839983, -------------- SYN_REPORT ------------
Event: time 1594587834.840771, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 1302
Event: time 1594587834.840771, -------------- SYN_REPORT ------------
Event: time 1594587834.855186, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 7145
Event: time 1594587834.855186, -------------- SYN_REPORT ------------
Event: time 1594587834.869894, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 1301
StollD commented 4 years ago

The linux event system is a state machine, just like HID. If the value for ABS_MT_POSITION_X doesn't change between two reports, the event is not sent out again. So these incomplete reports just mean that one of the values has not changed since the last time.

The value -1 for ABS_MT_TRACKING_ID means that that the current slot (ABS_MT_SLOT_ID) doesn't contain a touch, or that a previous touch was lifted.

tarmack commented 4 years ago

In that case all this shows is that the touch indeed gets marked as lifted for a single "frame" randomly.

Is there any way I could test if this problem is actually originating in the hardware or the driver? Maybe a report comes in late or all zeros or something like that.

By the way, thank you for your fast responses!

StollD commented 4 years ago

Is there any way I could test if this problem is actually originating in the hardware or the driver? Maybe a report comes in late or all zeros or something like that.

Thats going to be a bit difficult, or at least annoying, because multitouch in ipts doesn't really have a concept of reports. All we get is a buffer filled with capacitive heatmap data from the touch sensor. All the parsing / interpretation of that data needs to be done from scratch, and if that breaks you get to keep the pieces.

What you could do is print the whole heatmap data, but I don't think that is the issue. I have no idea what the actual issue could be either though...

tarmack commented 4 years ago

I made some efforts in finding the origin on the problem. I added a counter in processing/touch.go:Inputs() to print a line when all data points are zero. This print triggers irregularly when holding a finger still on the screen. It seem to me that there is indeed a problem where the buffer can be all zero when it should not be.

I'll keep digging.