Bump evdev to get past a bug, hopefully

[bkirwi]

I've been running into a sporadic issue where, after being paused / unpaused by a launcher, the app will stop responding to pen input. Finally got a stacktrace out; the wacom thread seems to be stuck indefinitely here, when trying to recover from events that were dropped during the pause:

#0  bitvec::slice::BitSlice<bitvec::order::Lsb0, u8>::sp_iter_ones_first<u8> (self=<optimized out>) at /home/bkirwi/.cargo/registry/src/github.com-1ecc6299db9ec823/bitvec-0.21.2/src/slice/specialization.rs:169
#1  0x005053d8 in bitvec::slice::iter::{impl#14}::next<bitvec::order::Lsb0, u8> (self=0x74efda88) at /home/bkirwi/.cargo/registry/src/github.com-1ecc6299db9ec823/bitvec-0.21.2/src/slice/iter.rs:2299
#2  0x00503090 in core::iter::adapters::map::{impl#2}::next<evdev::constants::AbsoluteAxisType, bitvec::slice::iter::IterOnes<bitvec::order::Lsb0, u8>, fn(usize) -> evdev::constants::AbsoluteAxisType> (self=0x74efda88) at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/core/src/iter/adapters/map.rs:103
#3  evdev::sync_stream::compensate_events (state=<optimized out>, dev=<optimized out>) at /home/bkirwi/.cargo/registry/src/github.com-1ecc6299db9ec823/evdev-0.11.1/src/sync_stream.rs:437
#4  evdev::sync_stream::{impl#2}::next (self=0x74efdbf0) at /home/bkirwi/.cargo/registry/src/github.com-1ecc6299db9ec823/evdev-0.11.1/src/sync_stream.rs:499
#5  0x004f18e8 in libremarkable::input::ev::{impl#0}::start::{closure#0} () at /home/bkirwi/Code/libremarkable/src/input/ev.rs:101

I haven't gone deep enough to totally confirm, but it appears to be an issue in evdev / bitvec, and there are a few recent bugfixes touching that code in the relevant projects. Bumping the patch version shouldn't hurt, and so far seems to be helping. (If it happens again even with this change, I'll open a proper issue.)

[LinusCDE]

Nice catch!

Seems fine to me (but haven't specifically tested it)

Side note: Can this also happen when switching apps? I know that launchers who support multiple apps cancel inputs during sleep by overflowing the (kernel internal?) ringbuffer with useless events. So an overflow protection (if even possible in this case) might hurt more than help.

[bkirwi]

Side note: Can this also happen when switching apps? I know that launchers who support multiple apps cancel inputs during sleep by overflowing the (kernel internal?) ringbuffer with useless events. So an overflow protection (if even possible in this case) might hurt more than help.

if i understand the evdev docs right, the kernel should insert a "you've missed some events" event in the buffer if the consumer doesn't consume events promptly enough, which the library notices and generates synthetic events to compensate for. (though i haven't looked into how that process works.) i also don't have a great sense of how this all interacts with the launcher behaviour you mention... as long as it doesn't overwrite that "you've missed some events" event, maybe it all works out? certainly i didn't seem to have any issues with the launcher interaction, before this bug cropped up at least...

i haven't seen the bug in the last ~2 days i've been running with this patch, so optimistically declaring this a success. i'll open a proper issue if it recurs, or if we decide there's more to do with the launcher / evdev interactions.