Behavior for axis events in the same event frame as the BTN_TOUCH is to
always send axis events before any tip state.
Behavior for button events in the same event frame as the BTN_TOUCH is to
order button events to happen when the tip is in proximity, i.e. after the tip
event on tip down and before the tip event on tip up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The tablet tip works like a button in the kernel but is otherwise not really
a button. Split it into an explicit tip up/down event instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
test.h:421:49: warning: ‘last_y’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
Cannot actually happen, if we don't get into the while loop where we
initialize it, we would assert.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Quite similar to wacom tablets but the evdev protocol differs - no serials for
example and only two tools. The device has a wheel, but it's not apparently
part of the stylus like on the wacom tablets. And it has a bunch of keys.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a tool is in proximity when we init, send a proximity event immediately.
This is only partially reliable due to the current kernel behavior:
* if the tool comes into proximity when there is no evdev client, the device
won't send any events and must be lifted out-of-proximity first. Patch is in
the works, see https://patchwork.kernel.org/patch/5924611/
* before 3.19, if the tool was in proximity (with an evdev client attached),
but goes out of proximity and back in with no client connected, we get an
immediate proximity out event from the kernel once we connect to the device
and no further events after that.
See kernel commit b905811a49bcd6e6726ce5bbb591f57aaddfd3be
Otherwise, things work as expected. The above should be fixed in the kernel
anyway.
Note that this changes the order of events during a udev seat init, before we
had all DEVICE_ADDED events in a row, now the proximity event may be
interspersed.
Reported-by: Jason Gerecke <killertofu@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The devices were never added to the libinput context we were checking, and the
while loop would quietly ignore not getting any events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The little wheel isn't a full wheel, it has a ~90 degree rotation angle with a
range of 1024 values. To avoid confusion with "wheel" elsewhere in the API
name it slider.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
Needs to be calculated from the x/y tilt values, the mouse has a fixed offset
of 175 degrees counterclockwise.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
A tablet hotplug event is rare and not a time-critical event, so we load the
database on tablet init and throw it away again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
The serial test was broken, it succeeded even if we never got an event. The
second test was fine, but complicated. Make it use some of the newer litest
features.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
mea culpa, I merged a patch that wasn't ready yet (despite me saying I
wouldn't merge it). Updated patch coming up next commit.
This reverts commit 6e7beeb347.
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 a motion event that's sent right after the original proximity event just
to give the values of each axis is somewhat redundant. Since we already include
the values of each axis with each type of event, we may as well use the
proximity event to give the client the starting values for each axis on the
tablet.
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>
There isn't much purpose in having proximity in and out as different events,
combining them into one single event is more consistent with the rest of the
API, and means less code for clients to have to work with.
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>
On the majority of Wacom tablets, the buttons are on the left side, opposite of
the side where the palm is meant to rest. Because of this, it's impossible to
use the tablet with your left hand (comfortably, anyway) unless you flip it
over, in which case the coordinates need to be inverted for it to match up with
the screen properly. This is where left handed mode comes in. When enabled, it
reverses all the coordinates so that the tablet may be rotated, and the palm
rest on the tablet moved over to the left side.
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>
Flow is so this cannot be unset, we'd abort if we never get an event. The
compiler doesn't know that though.
In file included from tablet.c:35:0:
tablet.c: In function ‘motion’:
litest.h:202:45: warning: ‘last_reported_y’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
ck_assert_int_lt((int)(a_ * 256), (int)(b_ * 256))
^
tablet.c:158:26: note: ‘last_reported_y’ was declared here
double last_reported_x, last_reported_y;
^
In file included from tablet.c:35:0:
litest.h:208:45: warning: ‘last_reported_x’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
ck_assert_int_gt((int)(a_ * 256), (int)(b_ * 256))
^
tablet.c:158:9: note: ‘last_reported_x’ was declared here
double last_reported_x, last_reported_y;
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Ignore anything before the TABLET_AXIS event but make sure we get at least one
axis event after the proximity event.
After that, in the second loop change to use tablet_motion, it's confusing to
use tablet_proximity_in here (though it technically works since we never go
out of prox).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The presence of a "+1" in the range calculation prevents the
normalization functions from returning a value of "1.0" when
absinfo->value has reached its maximum.
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These tests rely on libevdev doing the right thing, which it only does when it
uses the UI_GET_SYSNAME ioctl.
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>
