Improving touch event handling could improve responsiveness greatly.

[Riksu9000]

VID_20210708_145542.mp4

I was working on improving the touch handling and found some potential big improvements.

By adjusting registers on the touchscreen controller, we can get an interrupt on touch state change. I believe currently we only get interrupts from gestures. The single tap gesture has a long delay, which is why currently the watch responds sluggishly.

/*
[7] EnTest - Interrupt pin to test, enable automatic periodic issued after a low pulse.
[6] EnTouch - When a touch is detected, a periodic pulsed Low.
[5] EnChange - Upon detecting a touch state changes, pulsed Low.
[4] EnMotion - When the detected gesture is pulsed Low.
[0] OnceWLP - Press gesture only issue a pulse signal is low.
*/
static constexpr uint8_t irqCtl = 0b00110000;
twiMaster.Write(twiAddress, 0xFA, &irqCtl, 1);

Here's where I'm at currently.
https://github.com/Riksu9000/InfiniTime/tree/improved_touch_handling
Most things work fine, but with some apps touch seems inconsistent. Sometimes taps will "buffer", when a tap seems to get ignored, but tapping elsewhere will apply the missing tap. The first touch is more consistent than subsequent touches. Arc in metronome might flicker between max and min positions.

I'm starting to run out of ideas, so any help would be appreciated.

This potential can easily be tapped into in some cases by simply enabling TouchModes::Polling. This works on Timer on develop branch and it improves usability greatly.

EDIT: I was studying FreeRTOS and I thought that touch events should really be handled in a separate task. Then we could also enable EnTouch, and the handling could be really simple. I'll look into this more.

[JF002]

On your video, the reactivity of the touchscreen seems to be really improved!

Your discovery about the configuration of the irq pin is really interesting because that'll also a finer control of the touch panel!

As you noticed, for now, InfiniTime uses the touch IRQ only to detect gestures : tap, swipes,... But some apps needed to know the absolute position of the finger when it's moving. That's why we implemented these TouchModes : gestures or polling. Polling is a bit more expensive because it needs to poll the touch controller periodically.

This potential can easily be tapped into in some cases by simply enabling TouchModes::Polling. This works on Timer on develop branch and it improves usability greatly.

I think LVGL implements its own mecanism to detect taps/clicks. Maybe there's a conflict between the gestures (that are translated into taps) and the tap detection of LVGL? Maybe we don't need the tap gesture from the touch controller?
I'll try to think about it and test your branch when I'll have some time!

[Riksu9000]

I have now created a touch event handler task. This has fixed all inconsistensies with buttons, but some issues still persist.

The "buffering" behaviour is still present on checkboxes, and the arc in metronome is still acting weird. I wonder if this has something to do with LVGL rather than the touch handling.

Launching InfiniPaint causes the screen to desync slightly.

In ScreenList, accidentally scrolling on the last page will send a click on a button. This might not be hard to fix, but I haven't looked into it much. This is probably related to this quirk in LVGL:

When we press the screen outside of a button, slide our finger on top of a button and release, a click event is sent. This can even be seen in this online LVGL example. Interestingly this override prevents that from happening in QuickSettings.

Most problems in Issue #491 get fixed with this new handler, but some weird behaviour still persists.

Here's the new branch
https://github.com/Riksu9000/InfiniTime/tree/new_touch_handler

[Riksu9000]

I think I just solved everything. The up event (0 = Down, 1 = Up, 2 = Contact) in the touch controller either doesn't work, or the behaviour isn't as expected. We don't need it if we use the number of touch points value instead, and this seems to fix all the recent issues (#491) in new_touch_handler branch.

I was planning to fix the problems separately and have this touch handler come after, but should I just fix this branch up, and open a PR to merge everything at once?

I'm pretty sure this branch even fixes the issue with Twos game reading double gesture.

[Riksu9000]

Merged.