Fix LVGL touch

[Riksu9000]

LVGL reads the touch position twice for some reason. The first time it is read, tapped is true and set to false. The second time it is read, tapped value is false, so LVGL thinks all touches are rapid taps.

The touch is read in lv_task_handler(), so by setting the value to false manually after it fixes the issue.

LVGL reads the touch point every 20ms so if lv_task_handler() is run early, the touch isn't read but it's still cleared. This is why the touchProcessed variable is needed.

This will fix #491 while #492 isn't ready.

[kalaspuffar]

Using booleans for these events? Is it because of multi thread. I remember creating a search box with suggestions and adding a delayed reading of 300 ms before triggering the search in order to be sure of intent. Perhaps the reading of a touch event needs a value for how long a press should be in order to register intent?

Just a thought.

[Riksu9000]

Using booleans for these events? Is it because of multi thread. I remember creating a search box with suggestions and adding a delayed reading of 300 ms before triggering the search in order to be sure of intent. Perhaps the reading of a touch event needs a value for how long a press should be in order to register intent?

Just a thought.

LVGL has it's own way of detecting click events. All LVGL needs is the "cursor" position and whether it is clicked (or touching in the case of a touchscreen) and LVGL handles the rest. The current way this is implemented in InfiniTime isn't quite as intended, and this PR fixes an issue with the current implementation. I've been working on a better implementation at #492, but it still has some issues so this PR is just to fix a bug in the mean time.

[hatmajster]

I've been testing this yesterday and yes, it fixes the metronome laggines. Now its almost perfectly snappy.
Doesn't seem to fix anything else, the draw app seems to work exactly the same, pong too (i thought that it would be more responsive here, probably there are other bottlenecks). Works nicely

[JF002]

This will fix #491 while #492 isn't ready.

Does this mean that I shouldn't merge this branch if I plan on merging #492?

[Riksu9000]

This will fix #491 while #492 isn't ready.

Does this mean that I shouldn't merge this branch if I plan on merging #492?

Depends on how soon #492 will be ready, which might be very soon now. Not so sure anymore

[Riksu9000]

No longer needed.