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>
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>
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>
When using libinput with xf86-input-libinput, the device speed is
represented as a float passed via X properties.
If a buggy client gives a broken value, the conversions that occur
can cause the value of speed to be NaN (not a number), aka infinity.
In C, any comparison with NaN always gives false, whatever the value.
So that test in libinput_device_config_accel_set_speed():
(speed < 1.0 || speed > 1.0)
will necessarily return FALSE, defeating the test of range.
However, since since any comparison with NaN is false, the
opposite assert() in accelerator_set_speed():
(speed >= 1.0 && speed <= 1.0)
will be false as well, thus triggering the abort() and the crash of
the entire X server along with it.
The solution is to use the same construct in both routines, so that
it fails gracefully in libinput_device_config_accel_set_speed().
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Coverity pointed these out, they're false positives but mark them with
comments to make it obvious to the reader.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When creating uinput devices, we get the devnode from the kernel directly
rather than through udev. When we add this to the path backend too quickly the
udev_device we get may not be fully initialized and properties may be missing.
This causes false test results.
Avoid this by making sure the handle we have is initialized. This should never
trigger on a real device anyway, even creating a device through litest is slow
enough to avoid this issue. Only affected are the tests in misc.c where we
create the uinput device directly.
Nonetheless, handle this for the generic case so we don't run into heisenbugs
later.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Makes the code use more commonly used paths, no real functional changes at
this point. This was using hand-crafted devices as it predates the
litest_add_for_device() helper.
For an upcoming patch to use the udev ID_INPUT_. tags the
event_conversion_key test requires this change: without it the device will be
tagged with ID_INPUT_KEY but not ID_INPUT_KEYBOARD. This could be fixed by
adding all normal keyboard keys to the uinput device but it's easier to just
re-use litest.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Note: touchpads have a different backend, we never get here in that case. This
only applies to true absolute pointer devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Don't rely on a magic version tag, instead let a device define a udev rule and
drop that into the udev runtime directory before the device is created.
There are a couple of caveats with this approach: first, since this changes
system-wide state it may cause issues on the device the test suite is run on.
This can be avoided if the udev rules have filter patterns that ensure only
test devices are affected.
Second, the check test suite aborts but it doesn't run the teardown() function
if a test fails. So far this wasn't a problem since uinput devices disappear
whenever we exit. The rules files will hang around though, so an unchecked
fixture was added to delete all litest-foo.rules files before and after a test
case starts. Unchecked fixtures are run regardless of the exit status of the
test but run in the same address space - i.e. no ck_assert() usage.
Also unchecked fixtures are only run once per test-case, not once per test
function. For us, that means they're only run once per device (we use the
devices as test case), i.e. if a test fails and the udev rule isn't tidied up,
the next test may be unpredictable. This shouldn't matter too much though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The laptops on this series have the physical trackpoint buttons back but
wired them up to the touchpad instead of the trackpoint device and they appear
as BTN_0, BTN_1 and BTN_2 for left, right, middle.
The udev hwdb marks these for us with the TOUCHPAD_HAS_TRACKPOINT_BUTTONS tag
[1]. Use that tag to identify them and re-route the events through the
trackstick device after mangling the event codes to represent the actual
buttons.
[1] http://cgit.freedesktop.org/systemd/systemd/tree/hwdb/70-touchpad.hwdb
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Notable: sends BTN_0/1/2 instead of the trackpoint
This device currently has the INPUT_PROP_TOPBUTTONPAD property set, kernel
patches [1] and [2] are pending to remove this. This test device already lacks
the property.
[1] https://patchwork.kernel.org/patch/5730371/
[2] https://patchwork.kernel.org/patch/5730451/
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
libinput complained with lots of "client bug" messages because the GUI tool
did not check which axis values were available.
Signed-off-by: Friedrich Schöller <code@schoeller.se>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Vertical axis values were used for the horizontal axis as well.
Introduced 1baf109b40
Signed-off-by: Friedrich Schöller <code@schoeller.se>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
After switching my main workstation over to using xf86-input-libinput, I
noticed that the multi-media keys like play/pause on my keyboard no longer
worked.
It turns out that the second hid interface on my keyboard which has the
multimedia-keys, also declares having: BTN_BASE6 and BTN_MODE which both
fell into the range we were using to test for something being a joystick.
The commit makes our joystick test mode strict, restoring functionality
of the multi-media keys on the keyboard in question.
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>
