Sensitivity: Handle sensitivities < 1.0 without rounding errors

Background: We tell the xf86 core that our x and y ranges are the
overall range of the trackpad.  The xf86 core scales the supplied
values in the same way for relative and absolute pointers.  The result
is that at sensitivity 1.0, the scale of the whole trackpad
corresponds to the scale of the whole screen (so for example moving
the pointer from the very LHS to the very RHS of the screen can be
achieved by moving a finger from the very LHS to the very RHS of the
trackpad).

On some modern machines the resolution of the screen is much higher
than the resolution of the trackpad.  When this occurs, due to
rounding error, it can be impossible to reach the bottom and right
edges of the screen.  This is because even a 1-unit movement on the
trackpad is multipled by a >1-pixel pointer movement, and pointer
movements which would take the pointer off the screen are ignored.
(Arguably this is some kind of bug.)  In any case the user will
probably want to be able to control the pointer position with 1-pixel
accuracy.

This requires mtrack to specify a higher resolution.  Otherwise, the
fact that the values provided by mtrack to xf86 are integers means
that attempts to set the sensitivity to values < 1.0 are not properly
effective - resulting in "lumpy" response.

Fix this as follows:

 * Split sensitivity_val into sensitivity_big and _smalldiv,
   both >= 1.0, such that sensitivity_big/sensitivity_smalldiv is the
   specified sensitivity.

 * Multiply the size we tell xf86 by sensitivity_smalldiv.

As a result, when sensitivity is < 1.0, instead of scaling down
motions (resulting in unwanted rounding), we scale up the nominal size
(resulting in a lower scaling factor being applied by xf86).

When the sensitivity is > 1.0, everything behaves as before.

There is no change to the visible configuration.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Sensitivity: Introduce mconfig_get_sensitivity and _set_

In a moment, we are going to make the in-use representation of the
sensitivity more complicated.  We will need accessor methods for use
by the configuration machinery.

Provide these accessor methods now, to reduce noise in the substantive
patch.  For now they just access the single double.

Rename the variable so that we catch all of the references.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

debian/changelog: Start work on sensitivity

debian/changelog: finalise 0.3.1-1+iwj2

Offsets: Use ymin value for bottom edge features

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Offsets: Use xmin offset for button zones

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Offsets: In button zone code, cope with negative "pos" values

Coordinates might be negative, so we need a separate boolean rather
than using -1 as a sentinel.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Offsets: Introduce cfg->pad_xmin and ymin, and cap_get_xmin, ymin

These are going to be needed to cope properly with pads whose origins
are not at (0,0).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

debian/changelog: finalise 0.3.1-1+iwj1

Button zones: Export bottom_edge_zones in MTRACK_PROP_BUTTON_EMULATE_SETTINGS

For backward compatibility this property can now be either 3 or 4
items.  When we generate it, we generate 4 items, but we accept
setting only 3 items.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Button zones: Provide BottomEdgeZonesEnable

Many modern laptops have a clickpad, with some faint legend on the
surface suggesting that the bottom portion is a pair (usually) of
buttons.

Some users who are used to laptops which had separate physical buttons
below the trackpad have developed the habit of putting one finger on
the physical button, and using another finger to mouse.

This user behaviour can be supported if we:
 - ignore touches in the "button" area for all purposes, except
 - decide which button was pressed, if the user clicks the clickpad,
   by looking at which touch(es) are present in the button area

This is a novel combination of the behaviours of the BottomEdge and
ButtonZones options.  Provide a new BottomEdgeZonesEnable option,
(including documentation and static configuration).

The current code does not support users who have a habit of generating
and using chorded button events on mice with physical buttons.  (That
is, users who have configured application(s) to process simultaneous
clicks of different buttons meaningfully differently to single-button
clicks.)  I think this should be regarded as a bug in the
implementation I am introducing in this patch.  Fixing this would be
feasible without new config options or changes to other semantics but
would involve more rework of the zone processing in gestures.c than I
currently have time for.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Button zones: Refactor, preparatory to BottomEdgeZones

I intend to add a new feature BottomEdgeZones which reuses the Zone
machinery, but is going to use a different source for the effective X
coordinate which selects the zone.

Break out the computation of `pos'.  pos==-1 means the zone feature is
not in use or not applicable to the event.

No functional change in this commit.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Button zones: Remove inexplicable pad_with/2 offset

When button zones are in use, the code attempts to calculate which
zone the finger is in.  The left and right edges of the zones are
calculated according the nths of pad_width, where n is the number of
zones.

These left and right sides are compared with `pos', and the zone is
the one where left<=pos<=right.

This would all be correct if pos were the touch's x coordinate.
However, inexplicably, it isn't: it has had pad_width/2 added.

The git history does not reveal an explanation for adding pad_width/2.
Removing it makes the button zones work.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Debugging: Print each touch's state bitmask in mtstate_output

The user is expected to decode the hex (with reference to the bit
numbers defined in mtstate.h).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

common.h: bitmaps: Provide PRBITMASK

This is a printf format specifier, a la PRIx32 et al.  This avoids us
having to write %#x explicitly, which would be annoying if bitmask_t
ever changed its type.

No use sites introduced in this commit, so no functional change yet.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

mtrack-test.c: include <unistd.h>

Otherwise we get an implicit declaration warning about close().

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

common.h: Add missing include of <mtdev-plumbing.h>

Otherwise we get an implicit declaration warning about mtdev_empty.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Abolish uses of %+d

(EE) BUG: triggered 'if (f[f_idx])'
(EE) BUG: ../../os/log.c:565 in vpnprintf()
(EE) Unsupported printf directive '+'

DEBIAN/.GITIGNORE

DH_AUTORECONF

.gitignore: Add *~

In particular, although emacs generally doesn't generate ~ backup
files when working in a git tree, autoreconf does generate
config.h.in~, which should be ignored.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

xf86-input-mtrack (0.3.1-1) unstable; urgency=medium

  * Upload to unstable.
  * Fix debian/copyright format.

# imported from the archive