[swipe event] Quick swiping of the screen registers as touch event

[thyttan]

Affected hardware version

Bangle 2

Your firmware version

2v15.136 (It's been present on previous firmwares as well)

The bug

If doing a swipe on the screen too quickly it will be registered as a touch at the point where the finger first hit the screen.

I'd like it if I could do faster swipes (maybe drags to) than I can today.

One way to test this:

1. Start Desktop Launcher on the watch, make sure to have the 'Direct Launch' setting disabled.
2. Do a sufficiently fast up or down swipe, aiming to start with the finger on a currently not selected app icon.
3. If the swipe was quick enough the app will be selected (instead of the expected change of Desktop Launcher page).

I'll attach videos demonstrating the effect.

[gfwilliams]

It would be good to see what you mean in a video...

But I'm afraid this is probably down to the touchscreen controller itself. I guess it's possible you may be able to configure it differently but right now Bangle.js gets its events direct from the controller, so it is that which decides what a swipe or touch is.

[thyttan]

https://user-images.githubusercontent.com/97237430/201782412-7cf63e0d-d46c-4259-97c2-24cd0e36a997.mp4

It was admittedly a little hard to trigger this for the video, as you'll see. But it happens commonly enough for me if I'm not mindful to not be too quick when doing swipes. And that's the reason I don't have the "Direct launch" option set for Desktop Launcher, I'd sometimes launch an app when I intended to move between pages.

[gfwilliams]

It would be interesting if you could try reset() then Bangle.on("drag",print);Bangle.on("swipe",print) and do some quick swipes?

I just tried here and it looks like we just don't get the any real data points from the touchscreen if we swipe quick.

I think it's possible that the touchscreen isn't actually scanned that fast - maybe 50Hz or so - to save on power. It may be it's just not capable of detecting fast swipes.

[thyttan]

Yes, seems like you're probably right.

But it does seem like drag-event is a little quicker and can notice dx!=0 and dy!=0 even though a swipe isn't emitted.

Extending your test code like this:

i = 0;
j = 0;
Bangle.on("drag",()=>{i++;print("drag "+i+":");});
Bangle.on("drag",print);
Bangle.on("swipe",()=>{print("\n");});
Bangle.on("swipe",()=>{j++;print("swipe "+j+":");});
Bangle.on("swipe",print);
Bangle.on("swipe",()=>{print("\n");});

I can get e.g. this output to console field, where I expected a "swipe 16" print in the middle:

drag 28:
{ "x": 103, "y": 139, "b": 1, "dx": 2,
  "dy": -13 }
drag 29:
{ "x": 107, "y": 118, "b": 1, "dx": 4,
  "dy": -21 }
drag 30:
{ "x": 107, "y": 118, "b": 0, "dx": 0,
  "dy": 0 }
drag 31:
{ "x": 107, "y": 110, "b": 1, "dx": 0,
  "dy": 0 }
drag 32:
{ "x": 108, "y": 104, "b": 1, "dx": 1,
  "dy": -6 }
drag 33:
{ "x": 108, "y": 104, "b": 0, "dx": 0,
  "dy": 0 }

Where I don't get a swipe event, but I do get some dy<0's in drag events indicating we could do something with that.

Maybe the swipes filter the input like this intentionally to avoid emitting swipes when it probably shouldn't?

EDIT: Here's the full session which I took the above output from:

 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v15.138 (c) 2021 G.Williams
>
drag 1:
{ "x": 60, "y": 162, "b": 1, "dx": 0,
  "dy": 0 }
drag 2:
{ "x": 60, "y": 161, "b": 1, "dx": 0,
  "dy": -1 }
drag 3:
{ "x": 60, "y": 160, "b": 1, "dx": 0,
  "dy": -1 }
drag 4:
{ "x": 60, "y": 158, "b": 1, "dx": 0,
  "dy": -2 }
drag 5:
{ "x": 60, "y": 154, "b": 1, "dx": 0,
  "dy": -4 }
drag 6:
{ "x": 61, "y": 146, "b": 1, "dx": 1,
  "dy": -8 }
swipe 1:
0 -1
drag 7:
{ "x": 62, "y": 133, "b": 1, "dx": 1,
  "dy": -13 }
drag 8:
{ "x": 64, "y": 115, "b": 1, "dx": 2,
  "dy": -18 }
drag 9:
{ "x": 67, "y": 96, "b": 1, "dx": 3,
  "dy": -19 }
drag 10:
{ "x": 67, "y": 96, "b": 0, "dx": 0,
  "dy": 0 }
drag 11:
{ "x": 85, "y": 161, "b": 1, "dx": 0,
  "dy": 0 }
drag 12:
{ "x": 85, "y": 160, "b": 1, "dx": 0,
  "dy": -1 }
drag 13:
{ "x": 86, "y": 155, "b": 1, "dx": 1,
  "dy": -5 }
swipe 2:
0 -1
drag 14:
{ "x": 89, "y": 141, "b": 1, "dx": 3,
  "dy": -14 }
drag 15:
{ "x": 92, "y": 121, "b": 0, "dx": 3,
  "dy": -20 }
drag 16:
{ "x": 61, "y": 159, "b": 1, "dx": 0,
  "dy": 0 }
drag 17:
{ "x": 61, "y": 158, "b": 1, "dx": 0,
  "dy": -1 }
drag 18:
{ "x": 64, "y": 149, "b": 1, "dx": 3,
  "dy": -9 }
swipe 3:
0 -1
drag 19:
{ "x": 72, "y": 127, "b": 1, "dx": 8,
  "dy": -22 }
drag 20:
{ "x": 72, "y": 127, "b": 0, "dx": 0,
  "dy": 0 }
drag 21:
{ "x": 77, "y": 145, "b": 1, "dx": 0,
  "dy": 0 }
drag 22:
{ "x": 77, "y": 143, "b": 1, "dx": 0,
  "dy": -2 }
drag 23:
{ "x": 79, "y": 130, "b": 1, "dx": 2,
  "dy": -13 }
drag 24:
{ "x": 79, "y": 130, "b": 0, "dx": 0,
  "dy": 0 }
>
{"t":"act","stp":0,"hrm":0}
drag 25:
{ "x": 100, "y": 159, "b": 1, "dx": 0,
  "dy": 0 }
drag 26:
{ "x": 100, "y": 158, "b": 1, "dx": 0,
  "dy": -1 }
drag 27:
{ "x": 101, "y": 152, "b": 1, "dx": 1,
  "dy": -6 }
swipe 4:
0 -1
drag 28:
{ "x": 103, "y": 139, "b": 1, "dx": 2,
  "dy": -13 }
drag 29:
{ "x": 107, "y": 118, "b": 1, "dx": 4,
  "dy": -21 }
drag 30:
{ "x": 107, "y": 118, "b": 0, "dx": 0,
  "dy": 0 }
drag 31:
{ "x": 107, "y": 110, "b": 1, "dx": 0,
  "dy": 0 }
drag 32:
{ "x": 108, "y": 104, "b": 1, "dx": 1,
  "dy": -6 }
drag 33:
{ "x": 108, "y": 104, "b": 0, "dx": 0,
  "dy": 0 }
> 

[gfwilliams]

Yeah, that's what I'm seeing too.

Maybe the swipes filter the input like this intentionally to avoid emitting swipes when it probably shouldn't?

Yes...You're seeing DY of 13 and 21 - so 34px movement in total (not much more than the height of the widget bar). I think it's fair that the touchscreen discounts that, or you'd end up 'swiping' whenever you went to just press a button and rocked your finger slightly.

I'm afraid unless you can find some magic way to reconfigure the touchscreen (it's the same one as in PineTime so maybe there is some info out there) you're out of luck

[thyttan]

Ok, thanks for helping to test this! I'll close this issue as not planned. If I find something interesting regarding this I might open it up again.