evdev-tablet.c:545:1: warning: missing initializer for field 'device_added' of
'struct evdev_dispatch_interface' [-Wmissing-field-initializers]
and similar
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We need to *subtract*, not *add* the minimum to determine the
range-effective value. For example: if (min, current, max) is
(100, 100, 1000) then the normalized value would be 0.0, not 0.2.
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because the axes that tool reports can change depending on the tool in use, we
want to be able to provide functionality to determine which axes each tool can
support.
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>
With tablets that don't support serial numbers, we can't guarantee that the tool
objects are unique. Because of this, this can give clients the false impression
that a tool without a serial number is being shared between tablets when it very
well might not be. So we keep tools without serial numbers in a list that's
local to the tablet they belong to, and keep tools with serials in a list that's
global within the libinput context.
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>
Because the values for each axis were stored in struct tablet_dispatch in
millimeters, coordinates were not being translated properly to screen
coordinates. This stores the values internally as raw coordinates, and only
translates them to millimeters if the client asks for it.
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>
Since the orientation of the tablet can potentially change, this naming scheme
makes a lot more sense then VERTICAL and HORIZONTAL does since they don't
reflect the actual physical movement.
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>
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>
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>
A proximity-in event is something we want, especially since the current drafted
wayland spec has a proximity-in event. Adding this also makes our events more
consistent. And since we can just report the current tool in use with
proximity-in events, we can get rid of the tool-update event.
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>
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>
Because bad distance events still trigger calls to tablet_flush(),
tablet_flush() will see that the tablet is out of proximity and assume it's an
appropriate time to send a proximity-out event, even when we've already sent
one. This results in multiple proximity-out events being sent in a row instead
of just one.
In addition, the bad distance events test has been modified to pick up on this.
We shouldn't be receiving /any/ events when we get false distance events from
evdev anyway.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We've got big plans for handling pad buttons, and the interface will likely
be different for those. Meanwhile, discard any pad button events so no-one can
get too used to them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The actual data provided by current tablets is not anywhere close to accurate.
While it'd be nice to have this in mm, this is unlikely to happen anytime
soon. Use the same 0..1 normalized range as pressure has.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Given that tablets may not have the same x/y resolution, raw or normalized
values are mostly meaningless and likely to be handled the wrong way.
Providing x/y in mm is the only constant, meaningful value.
Signed-off-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>
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>
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>
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>
