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>
seat_button_count
seat_key_count ... uninitialized variable
t = zalloc
s = zalloc ... dereferencing potential NULL-pointer
d->ntouches_down... side-effect in assertion
Coverity run against the 0.10.0 tag, see
https://scan.coverity.com/projects/4298
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Christian Hartmann <cornogle@googlemail.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.
When the tablet goes out of proximity we provide the last-known axis status
(which was sent in a previous axis event anyway), make sure the changed_axis
bitfield is unset for all axes though.
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>
If the device disappears too quickly, the device is NULL, the sysname is NULL
and that causes a segfault in strcmp.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This constant isn't used in the public API, let's drop it. To make it easier
to use it internally and avoid accidental boolean comparisions with axes, bump
all real axes up to start at 1.
Internally that means we drop the AXIS_CNT since it'd be misleading and
instead use MAX or MAX + 1 everywhere.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.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>
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>
TABLET_PROXIMITY events cause many terminals to push every column to the right
by one additional tab, this just increases the space after the event type so
that everything lines up again.
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>
This is in reference to an issue I discovered during the GSoC where I found that
there is a grey area with the tablet tool and the tablet itself, where the
tablet will pick up the presence of a tool, but won't get any useful information
from it. When this happens, tablets have a habit of sending distance events with
incorrect values in them. As such, it's a good idea not to forward any axis
events from evdev until we know that the tool is within usable proximity.
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>
Bluetooth tablet devices' rules can't tag the event node directly, they can
only tag the first parent (the /sys/class/input/input1234 node). Check that
parent for tags too, lest we miss something important.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Store it as identifier in the device group, any two devices that have a
the same non-NULL identifier share the group.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The easiest way to get a device group is by looking at the phys path of the
input device (which looks like usb-0000:00:14.0-1/input1) and dropping the
/inputX bit. The rest is the same for devices that belong together (except on
the Cintiq 22HD Touch).
Ideally we could just take ATTRS{phys} but we can't select substrings to drop
into ENV so we need to do it ourselves. This patch adds a callout that takes a
syspath and prints the mangled path, to be used in LIBINPUT_DEVICE_GROUP.
The rule triggers on any device that has a non-zero phys attribute, this
groups devices like tablets together but also devices like mice with multiple
interfaces.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We should be able to set the tablet to left-handed mode immediately when it's
connected to the system. Since left-handed mode won't activate until the tool is
out of proximity however, we have to make sure that upon initially connecting
the tablet, we set the tool to be out of proximity (it may as well be anyway,
since we haven't processed any proximity in events from evdev just yet)
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>
If a device has multiple capabilities, has_button is imprecise. A device with
tablet and pointer capability for example may have BTN_LEFT on the pointer
interface but not on the tablet interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This patch adds simple script that compares libinput.sym file to the
functions that are marked by LIBINPUT_EXPORT. This script is added
to make check target.
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Added: udev-tag detection for the tablet.
libwacom assigns ID_INPUT_TABLET to all known devices but also
ID_INPUT_TOUCHPAD to all known devices with a touch interface. That's a bug
and should be fixed there but we can work around it by checking both and
making sure only one is set.
Conflicts:
src/evdev.c
test/misc.c
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>
Use ID_INPUT_FOO to assume a device is a FOO, don't decide ourselves based on
whatever bits are available. This moves the categorization out to udev's
input_id builtin by default and other bits that tag the device. libwacom tags
all known devices as ID_INPUT_TABLET and (for touch-enabled ones)
ID_INPUT_TOUCH - we can re-use that knowledge then.
Ignore anything that doesn't have ID_INPUT set, this provides for an easy way
of making devices "invisible" to libinput.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
udev already tags the devices by opening each of them and analyzing their
features. We are basically re-doing this in libinput.
The advantage of udev tags over the plain heuristic from libinput is that
users (or driver writers) can force some tags that are not detected by
common rules. For instance, the pad part of the Wacom tablets is difficult
to discriminate from a joystick or a pointer.
For now we tread INPUT_ID_KEY and INPUT_ID_KEYBOARD as equivalent. It may
become necessary to separate them later.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This can happen a lot easier on the new Lenovo series, so document that this
is intentional behavior.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Devices like Wacom tablets have multiple event nodes (touch, pad and stylus).
This requires some logical grouping, e.g. setting an Intuos 5 tablet
left-handed effectively turns it upside down. That then applies to both the
stylus and the touch device.
Merging the devices into one struct libinput_device is not feasable, it
complicates the API for little benefit. A caller would still need access to
all subdevices to get udev handles, etc. Some configuration options apply to
the whole device (left-handed) but some (may) only apply to a single subdevice
(calibration, natural scrolling).
Addressing this would make the libinput API unwieldly and hard to use.
Instead, add a device group concept. Each device is a member of a device
group - a singleton for most devices. Wacom tablets will have a single group
across multiple devices, allowing the caller to associate the devices together
if needed.
The API is intentionally very simple and requires the caller to keep track of
groups and which/how many devices are in it. The caller has more powerful
libraries available to do that than we have.
This patch does not address the actual merging of devices into the same
device group, it simply creates a new group for each new device.
[rebased on top of 0.10]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
