Anelok: The slide

Werner Almesberger werner at almesberger.net
Tue Jan 13 03:34:57 UTC 2015


Paul Boddie wrote:
> I like the availability of both tapping and sliding, the former being useful 
> when the latter starts to get impractical (perhaps due to an excess of 
> credentials to manage).

Hmm, I'm more thinking of the opposite use case: slide for large
distances, tap if you're just one or two entries away.

Background:

Samples from the capacitive sensors are converted by fw/2014/touch.c
to positions in the range 0-63, corresponding to vertical display
pixels.

Samples from touch.c are then turned into tap, press, and slide
events by fw/ui/input.c To register a sliding / swiping motion, the
sensor has to be actuated for a minimum time (currently 200 ms,
SWIPE_MIN_MS) and the position has to change by a minimum distance
(currently 20 pixels, SWIPE_MIN_MOVE) from the point of first
contact.

Once a swipe is detected, input.c reports the initial movement to
the current user of the input system and then calls it continuously
for further movements.

Since text list entries have a height of 11 pixels (LINE_Y in
fw/ui/textsel.c), the list would jump very far when crossing the
threshold. Since this would feel weird, limit_swipe in fw/ui/sel.c
limits the initial jump to moving to the adjacent entry plus
covering 3/4 of that entry's height.

After that, movement of the list follows whatever the user does.
Since sliding can also accumulate short movements one can then just
quickly repeat the movement for larger distances.

Now, it may make sense to temporarily lower the threshold at the end
of a slide operation so that Anelok will respond more quickly to the
next swipe. After all, if a swipe is to be followed by a long press
(that could be mis-interpreted as a swipe if there is movement
during the press and the distance threshold is too low) there will
probably be a short pause between the two.

Getting all these parameters right will certainly require some more
fiddling. At the moment, the biggest nuisance is the automatic
calibration of the sensor (fw/2014/touch.c:normalize) that kicks in
whenever there is fairly static input for a while, the idea being
that this means that the sensor is idle.

Alas, the algorithm can sometimes be fooled to calibrate while the
sensor is being actuated (or exposed to some temporary distortion of
the field), which means that sensing will be very confused for a
while. The problem sorts itself out by just letting Anelok rest for
something like half a minute, but still ...

- Werner



More information about the discussion mailing list


interactive