Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Occasionally all the axes that are valid for a device need to be marked as
updated for the caller's sake.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Axis changes are now still processed by libinput regardless of whether or not
the tool is in proximity, however we refrain from reporting them unless the tool
is in proximity. This stops bad distance events from being reported without
needing a huge mess of conditional statements in sanitize_axes(). The tool is
now counted as back in proximity when a tool update is received instead of when
an axis update is received.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of device-specific coordinates that the caller can't interpret without
knowing the range anyway, return mm as the default value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Avoids nasty surprises later when we divide by 0. This matters particularly
when testing a device through uinput, which can't set the resolution.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Having parantheses around tablet_has_status() is completely appropriate, but not
for setting/unsetting a status. There's no legitimate reason we'd ever be
checking the return value of tablet_(un)set_status() since it already stores
it's result in a variable. As such, having it expand with parantheses around it
means that if it's accidentally used in a conditional instead of
tablet_has_status() our compiler won't throw any sort of warning. And the subtle
differences between tablet_has_status() and tablet_set_status() are very easy to
miss when trying to debug this. Removing the parantheses causes gcc to warn if
the function is used as a conditional unintentionally.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
stdint is a lot nicer, and safer once we're in the habit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
This is a simple button mask, use that naming.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
This commit changes two things with the way distance and pressure axes are
reported:
1. Distance and pressure are made mutually exclusive. When there is a distance
event and a pressure event and the tool is in contact with the tablet, only
the pressure change will be reported. When the tool is not in contact and
both a distance and pressure change are received, only the distance update
will be received.
2. Bad distance events are not reported to the caller. There is a certain
distance a tool can be from the tablet where the tablet recongnizes that a
tool appeared, but the tool doesn't send any useful information to the
tablet. When this happens, the distance will update to it's minimum or
maximum value, and no other axis updates will be sent. Since this can give
a caller the impression that the tool is within a useful proximity of the
tablet, we filter out any distance events with a value of maximum or minimum
when the tool is not within useful proximity of the tablet.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Report the values for the distance, pressure, and tilt axes. Pressure is
normalized to a range of 0 to 1, and tilt is normalized to a range of -1 to 1.
Based off the patch originally written by Carlos Garnacho
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This event is just used to notify the caller when the tool's no longer in
proximity. When an event like this occurs, everything from evdev up until the
next EV_SYN event is discarded along with any events that occured since the last
EV_SYN event. This also silences any tool update events where the tool type is
changed to LIBINPUT_TOOL_NONE, so we don't end up filling the tool list with a
bunch of tools that aren't actually tools.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This will be used to represent a tool in use on a drawing tablet.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
These devices set the LIBINPUT_DEVICE_CAP_TABLET flag, and emit a lot more axis
information then mice and touchpads. As such, tablet events are in a whole new
group of events that is separate from everything else.
In this commit, only X and Y axes are reported in libinput.
Based off the patch originally written by Carlos Garnacho
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This capability flag would be enabled when events are driven through
a stylus, ie. on a tablet.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A button event consumed by the softbutton or clickpad code does not feed into
the tap state machine, leaving it in its current state. The touch generating
that event however may have triggered state changes.
For some tap/click combinations this gives us either double press/release
events or an inconsistent order of events. Those issues include:
* a really short physical click causes a click + tap-click
* a really short physical click on the right software button causes a right
click + left tap-click
* tap + click causes double button left press events
To avoid these, notify the tap code that a button event has occured and
process that accordingly. Depending on the state this may either continue to
the DEAD state or release the current tap button and then go to the DEAD
state.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is useful for when we use libraries which want us to provide them with
a logging callback.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libinput-util.h is needed for the linked list definitions.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Besides being a nice cleanup, this gives us proper per touch timeouts.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Currently we are using DIY timers in the touchpad softbutton and tap handling
code, and at least the softbutton code gets its wrong. It uses one timer-fd
per touchpad to set a timeout per touch, which means that if a timeout is
set for 100ms from now for touch 1, and then 50 ms later touch 2 sets a timeout
for 200 ms from now, then the timeout for touch 1 will come 150 ms too late.
This commits adds a proper timer subsystem so that we've one place to deal
with timer handling, and so that we can only get it wrong (well hopefully
we get it right) in one place.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Button states are applicable to more then just the pointer, so having a
non-generic name name for a generic enumerator value like
libinput_pointer_button_state doesn't make sense. Changing it to something
generic like libinput_button_state allows it to be reused by other devices that
may potentially be added to libinput in the future.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixed point numbers can easily overflow, and double to fixed point
conversion is lossy. Use floating point (double) where fixed point
numbers where previously used and remove the li_fixed_t type.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The direction lock was intended to avoid erroneous horizontal scroll events
when scrolling vertically (and vice versa). Some testing on my touchpad here
shows that it is too easy to accidentally lock the direction when no lock is
intended (e.g. moving around an image). And quite hard to figure out what a
pure vertical gesture is.
I get movements from 90 degrees to 70 degrees for something my brain would
consider vertical scrolling. Depending on the hand position, the fingers
actually perform a slight curve, not a straight line.
Hence - drop the direction lock, but increase the threshold a little. It
doesn't totally avoid horizontal scroll events but keeps them minimal.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Avoids having to #define any values we're trying to use.
Header file is from Linux 3.15-rc8.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
KEY_MICMUTE was added relatively recently (3.1 with 33009557bd: Add
KEY_MICMUTE and enable it on Lenovo X220), so provide a fallback definition
similar to how we do it for KEY_LIGHTS_TOGGLE to fix compilation with older
toolchains.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add support for the top softbutton area found on some laptops.
For details of how this works, see the updated
doc/touchpad-softbutton-state-machine.svg diagram.
Basically this mirrors the state-machine for the bottom softbutton area, with
one exception, if a finger stays at least inner timeout milliseconds in the
top button area and then moves out of it, it will be ignored rather then
become the pointer. This is done so that people using the top buttons together
with a trackstick and accidentally move their finger out of the upper area
don't get spurious pointer movements from the finger on the trackpad.
This behavior is indentical to xf86-input-synaptics, which also ignores
movements from touches which start in the top button area.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rename some clickpad softbutton area variables to have bottom in their
name, this is a preperation patch for adding top softbutton area support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
