search

baskerville / plato

Document reader
Other
1.26k stars 104 forks source link

Asymmetric phantom touch events? #118

Open baskerville opened 4 years ago

baskerville commented 4 years ago

I have only witnessed this on the Glo HD: sometimes, when waking up from suspend using to power button, Plato ends up in a state where it would appear that the touch contacts are not getting emptied, as if a finger down event was received without the corresponding finger up event. When I tap one of the icons, the finger down and finger up events are received (I can see the inversion feedback), but parse_gesture_events fails to generate a tap event.

(It might only happen when the screen was touched before pressing the power button.)

NiLuJe commented 4 years ago

That sounds similar to an issue @poire-z notices on his Glo HD w/ KOReader, where touches after a suspend may end up being detected as holds.

poire-z commented 4 years ago

notices on his Glo HD w/ KOReader, where touches after a suspend may end up being detected as holds.

Yes, that happens. But it's most often the followup of a first issue that happens before I do the suspend (I think it only happens to me when I suspend because of that first issue - not when I suspend when everything is fine - although when evething is fine, I don't suspend with the button, but with a gesture). I described it at https://github.com/koreader/koreader/issues/4431#issuecomment-455847181. KOReader is not in a loop (the power button event is handled correctly), but touch seems dead (as if the device has freezed). Has that already happened to you @baskerville ? I dunno if it's some touch layer hardware bug - or something in KOReader's code that could mess with the event timings or something (it could be stuck in a finger down state and not process further event, dunno really). Suspending & resuming have KOReader issue a echo "a" > /sys/devices/virtual/input/input1/neocmd which seems to reset/wakeup the touch layer (and then, I have that first tap detectd as hold - but I can live with that :) Some URLs I have kept that were related to all that: https://github.com/koreader/koreader/issues/1862 https://github.com/koreader/koreader/issues/1943 https://github.com/koreader/koreader/issues/4431 https://www.mobileread.com/forums/showthread.php?t=269515 https://www.mobileread.com/forums/showthread.php?t=297102

NiLuJe commented 4 years ago

Oh, I'd forgotten about that part ;p.

The neonode IR grid not waking up is a (kernel?) bug/race that affects the H2O, too, and I can definitely reproduce that one (even in Nickel, if you suspend and then quickly (but not necessarily immediately) resume, there's a small, but significant window of time where you'll definitely end up with dead input on resume).

Hence the forced wakeup in KOReader ;). (Which also works in Nickel, if you happen to have shell access at the time).

As for the other issue, my naive assumption was that the timestamps of input events are wonky on resume, but that may be a red herring.

baskerville commented 4 years ago

@poire-z No, I never experienced the behavior you described.

@NiLuJe parse_gesture_events would still work fine with wonky timestamps.

occivink commented 4 years ago

I've had this happen on my Aura One on stock software, even on very recent versions (<1 month ago)