Unlike ALPS and Synaptics semi-mt touchpads, the Elantech touchpads appear to
be precise enough to allow a smaller motion threshold before we decide on the
type of gesture (pinch vs scroll).
https://bugs.freedesktop.org/show_bug.cgi?id=91475
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
That's where we set the pointer cap too.
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
In order to provide higher precision event time stamps, change the
internal time measuring from milliseconds to microseconds.
Microseconds are chosen because it is the most fine grained time stamp
we can get from evdev.
The API is extended with high precision getters whenever the given
information is available.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
In most places we use 64 bit unsigned integers; lets be consistent and
use it everywhere.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
These touchpads have a terrible resolution when two fingers are down, causing
scrolling to jump around a lot. That then turns into bug reports that we can't
do much about, the data is simply garbage.
https://bugs.freedesktop.org/show_bug.cgi?id=91135
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Hallelujah-expressed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
On some devices we need to set more than one flag, i.e. make it into actual
flags.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Hallelujah-expressed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regression introduced in 8302860.
Reading the DPI before evdev_configure_device makes it lose on the trackpoint
flag, causing libinput to ignore the POINTINGSTICK_CONST_ACCEL property.
8302860 moved it up so we can init accel based on the DPI, this patch simply
moves istart t before the acceleration is initialized.
https://bugs.freedesktop.org/show_bug.cgi?id=91369
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For Elantech touchpads, we know that the resolution is 31u/mm (800dpi) for
v1-v3 firmware. Set this as a hint until we get either the kernel or systemd
to set this for us.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Touchpads, notably Elantech, ALPS and bcm5974 don't provide x/y resolution
until recent generations.
Add a new property, LIBINPUT_ATTR_SIZE_HINT, that provides size information to
libinput. Note that this property *does not* override true resolution values,
it is only used when the resolution is missing. It is used merely as an
approximate size hint.
If the resolution for a specific device is known it should be added to the
udev hwdb so it can be set globally. See the bcm5974 entries here:
http://cgit.freedesktop.org/systemd/systemd/tree/hwdb/60-evdev.hwdb.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The only two callers passed in the fake resolution anyway, so we don't need
extra parameters here.
We don't allow devices with only x or y resolution set, either both or none.
And we can use libevdev_set_abs_resolution() rather than handling absinfo
structs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
For touchscreens we always send raw touch events to the compositor, and the
compositor or application toolkits do gesture recognition. This makes sense
because on a touchscreen which window / widget the touches are over is
important context to know to interpret gestures.
On touchpads however we never send raw events since a touchpad is an absolute
device which primary function is to send pointer motion delta-s, so we always
need to do processing (and a lot of it) on the raw events.
Moreover there is nothing underneath the finger which influences how to
interpret gestures, and there is a lot of touchpad and libinput configuration
specific context necessary for gesture recognition. E.g. is this a clickpad,
and if so are softbuttons or clickfinger used? What is the size of the
softbuttons? Is this a true multi-touch touchpad or a semi multi-touch touchpad
which only gives us a bounding box enclosing the fingers? Etc.
So for touchpads it is better to do gesture processing in libinput, this commit
adds an initial implementation of a Gesture event API which only supports swipe
gestures, other gestures will be added later following the same model wrt,
having clear start and stop events and the number of fingers involved being
fixed once a gesture sequence starts.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
Motion normalization does not work well for devices below the default 1000dpi
rate. A 400dpi mouse's minimum movement generates a 2.5 normalized motion,
causing it to skip pixels at low speeds even when unaccelerated.
Likewise, we don't want 1000dpi mice to be normalized to a 400dpi mouse, it
feels sluggish even at higher acceleration speeds.
Instead, add a custom acceleration method for lower-dpi mice. At low-speeds,
one device unit results in a one-pixel movement. Depending on the DPI factor,
the acceleration kicks in earlier and goes to higher acceleration so faster
movements with a low-dpi mouse feel approximately the same as the same
movement on a higher-dpi mouse.
https://bugzilla.redhat.com/show_bug.cgi?id=1231304
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Currently unused, but store the ratio of DPI:default DPI for later use.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This simply doesn't work for low-dpi mice. Normalizing a 400dpi mouse to a
1000dpi mouse forces a minimum movement of 2.5 units and the resulting pixel
jumps. It is impossible for the caller to detect whether the jump was caused
by a single motion or multiple motion events.
This is technically an API break, but not really.
The accelerated data was already relatively meaningless, even if normalized as
the data did not correspond predictably to any input motion (unless you know
the implementation acceleration function in the caller). So we can drop the
mention from there without expecting any ill effects in the caller.
The unaccelerated data was useless for low-dpi mice and could only be used to
measure the physical distance of the mouse movement - something not used in
any caller we're aware of (if needed, we can add that functionality as a
separate call). Dropping motion normalization for unaccelerated deltas also
restores true dpi capabilities to users of that API, mostly games that want to
make use of high-dpi mice.
This is a simplified patch, the normalization is still in place for most of
libinput, it merely carries the original coordinates in the event itself.
In the case of touchpads, the coordinates are unnormalized into the x-axis
coordinate space as per the documentation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We use width/height often enough that storing it once is better than
calculating it on each event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Alps devices don't know if there is a physical middle button on the touchpad,
so they always report one.
Since a large number of touchpads only have two buttons, enable middle button
emulation by default. Those that really don't want it can play with
configuration options, everyone else has it working by default.
The hwdb entry uses "*Alps ..*" as name to also trigger the "litest Alps..."
devices.
https://bugzilla.redhat.com/show_bug.cgi?id=1227992
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
To quote Bryce Harrington from [1]:
"MIT has released software under several slightly different licenses,
including the old 'X11 License' or 'MIT License'. Some code under this
license was in fact included in X.org's Xserver in the past. However,
X.org now prefers the MIT Expat License as the standard (which,
confusingly, is also referred to as the 'MIT License'). See
http://cgit.freedesktop.org/xorg/xserver/tree/COPYING
When Wayland started, it was Kristian Høgsberg's intent to license it
compatibly with X.org. "I wanted Wayland to be usable (license-wise)
whereever X was usable." But, the text of the older X11 License was
taken for Wayland, rather than X11's current standard. This patch
corrects this by swapping in the intended text."
libinput is a fork of weston and thus inherited the original license intent
and the license boilerplate itself.
See this thread on wayland-devel here for a discussion:
http://lists.freedesktop.org/archives/wayland-devel/2015-May/022301.html
[1] http://lists.freedesktop.org/archives/wayland-devel/2015-June/022552.html
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
If we need to temporary override a device with ID_INPUT_POINTINGSTICK,
evdev sets the tag EVDEV_TAG_TRACKPOINT to the device. Rely on the tag
to behave properly for scroll emulation.
The dpi information should be retrieved after the device has been
configured or the tag EVDEV_TAG_TRACKPOINT was not set.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tagging a device should occur only once during configure. We do not
have devices that can be changed after they are configured, so there is no
point in having the tagging part in a deferred struct.
Plus, the note saying that we tag with only one of EVDEV_TAG was wrong.
Now that we are chosing when we call each evdev_tag_*, we can also get
rid of the device->seat_caps tests.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current code only defaulted to the middle button for those devices that
used button scrolling by default, requiring the user to enable button
scrolling _and_ set the button before it is active. This causes some
confusion.
There is no real benefit to leaving the button at 0 when the scroll
method isn't enabled anyway. So always default to the middle button (if
available).
https://bugzilla.redhat.com/show_bug.cgi?id=1227182
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
When we get the release event within the timeout, we send a press + release
event for the middle button. Rather than using the release event's timestamp
for both, remember and use the button press timestamp.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Added in systemd 220, but note that for udev backwards compatibility, the
ID_INPUT_POINTINGSTICK tag is set in addition to the ID_INPUT_MOUSE tag.
And use that property to tag a device as trackpoint too, this allows temporary
workarounds for kernel bugs where the input prop isn't set yet.
https://bugzilla.redhat.com/show_bug.cgi?id=1225563
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The keyboard test is a simple one, if we have the first row of alphabetic
keys, we assume it's a full keyboard.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Unlikely, but there's the odd chance of the first touch coming in with the
same X or Y coordinate the kernel already has internally. This would generate
a x/0 or 0/y event in libinput.
Sync the slot state on init, at least for Protocol B devices. For Protocol A
devices and mtdev, don't bother.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The touchpad carries enough state around that calling release_all_keys() isn't
enough to properly suspend it. e.g. a button down after tapping won't be
released by trying to release the physical button for it.
We need to clear the state properly, but that's interface-specific so add a
new hook for it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Just a move to make the next diff easier
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If a physical button is down but releasing said button doesn't actually
release it, we loop endlessly. Detect that and log a bug instead.
Reproducible: trigger a tap-n-drag on a touchpad device, then remove it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The System76 Galago Ultra Pro is a rebranded Clevo W740SU with changed
firmware strings. To my knowledge, the Clevo W740SU and all its rebrands
possess smooth touchpads.
In the original bug report[1], a Galago Ultra Pro was returned to the
original DMI strings by flashing another firmware. This resulted in the
model identified as MODEL_SYSTEM76_CLEVO.
Since the actual manufacturer of the W740SU is Clevo and the CLEVO hwdb
entry already properly identifies other W740SU rebrands like the Schenker
S413, the model should be renamed to match.
[1]: https://bugs.freedesktop.org/show_bug.cgi?id=90170#c3https://bugs.freedesktop.org/show_bug.cgi?id=90353
Signed-off-by: Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Bonobo, Clevo, Galago and Kudu have clickpads and no markings ->
enable clickfinger by default.
Lemur and Gazelle have physical buttons, no need for extra configuration.
https://bugs.freedesktop.org/show_bug.cgi?id=90170
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This matches the vendor default.
Board IDs pulled from modinfo chromeos_laptop, touchpad names from a bit of
googling around.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We'd rather keep these out of the hands of children.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we have a middle button but no wheels, enable on-button scrolling for the
middle button by default. This applies e.g. to the Logitech trackball added as
new test device here.
This makes the separate check for POINTINGSTICK obsolete but I'd rather leave
this in to be more explicit about it.
https://bugs.freedesktop.org/show_bug.cgi?id=90208
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Some devices provide abs x/y and rel x/y. We can't know which event the device
will send. The Microsoft Surface Type Cover sends relative events, which
then crashes libinput when we don't have an accel filter set up.
So instead of checking that the device doesn't have ABS_X/Y, check for the
device to have REL_X/Y instead.
https://bugzilla.redhat.com/show_bug.cgi?id=1206869
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-By: Derek Foreman <derekf@osg.samsung.com>
Not sure if any exists, if they do let's see if a user files a bug report
first so we know what to do with those (they're most likely buttonsets).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-By: Derek Foreman <derekf@osg.samsung.com>
