- Apr 21, 2015
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Fixes distcheck Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Just setting one of them on a device doesn't guarantee that libinput takes that as device type. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
Coverity complaint: mixed_enums: Mixing enum types enum libinput_config_middle_emulation_state and enum libinput_config_status Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
https://bugs.freedesktop.org/show_bug.cgi?id=90070 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
The goal of this test is to make sure that the deltas are less than 5, which is the scroll trigger for movement-based edge scrolling. The litest suite takes percentages of the device, so use a scale factor to change how far we move on the tablet. The wacom tablet is 141mm, the movement must be smaller to provide small-enough deltas. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
The single finger requirement dates back to when we couldn't configure the scroll method. Now we can, so let's run the tests on as many suitable devices as possible. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
Just to make sure it is enabled (it should be anyway). Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
This is sort-of legitimate, so simply disable the axes and continue. Any real axis we require to have a real range. https://bugs.freedesktop.org/show_bug.cgi?id=90090 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
- Apr 17, 2015
-
-
Peter Hutterer authored
Once we have a doubletap, enter a loop in the state machine where we can tap multiple times and either get a multi-click or a multi-click drag-and-drop. The sequence down/up down/up down/up produces a triple-click. The sequence down/up down/up down/up down produces a triple-click with a button down for dragging. Yes, that glorious octuple-tap-and-drag, it is now possible. World domination has been achieved, thank you for playing. We don't know when we finish tapping now, so add a timeout to send the last click event once the finger has been released for the last time. This guarantees that the timestamp of the last button down is later than the last release. This avoids the bug fixed in synaptics commit xf86-input-synaptics-1.8.0-21-g37d34f0 (some application don't handle doubletap correctly without the timestamps). This works for double-tap immediately, for multi-tap we need to remember the timestamp of the first press event and use it for the release event so that there's a forced gap between the release and the second press. https://bugs.freedesktop.org/show_bug.cgi?id=89511 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
Makes it easier from a caller to check for common things without all the other boilerplate code. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
If the touchpad has left/right physical buttons but no middle button, force middle button emulation - without a config option, it's always on. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
Devices that have left and right buttons but no middle button get middle button emulation (without config). Devices that have a middle button too get a config option but default to off. Most mice have LMR set as buttons, regardless whether they have a middle button. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
This is just the required framework, it's not hooked up to anything just yet. Hooking it up comes as separate commit to better detail why/when a device supports emulation. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
Adds the following quartett of functions to enable/disable middle mouse button emulation on a device: libinput_device_config_middle_emulation_is_available() libinput_device_config_middle_emulation_set_enabled() libinput_device_config_middle_emulation_get_enabled() libinput_device_config_middle_emulation_get_default_enabled() This patch only adds the config framework, it is not hooked up to anything yet. Note: like other features this is merely the config option, some devices will provide middle button emulation without exposing it as configuration. i.e. the return value of libinput_device_config_middle_emulation_is_available() only tells you whether you can _configure_ middle button emulation. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
No functional changes at this point, this merely splits up any physical buttons (i.e. that represent buttons that exist on that device) vs. other buttons that are emulated in some way or another. This is in preparation for the addition of middle button emulation. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
Missing from 26062e84 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Apr 16, 2015
-
-
Peter Hutterer authored
https://bugzilla.redhat.com/show_bug.cgi?id=1209753 lists a touchpad 76mm wide that suffers from palm touches Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
Touches in the exclusion zone are ignored for palm detection and don't move the cursor. Tapping however triggers before we know whether something is a palm or not, so we get erroneous button clickst. If a tap happens in the top half of the touchpad, within the palm exclusion zones, ignore it for tap purposes. To avoid further complicating the state machine simply pretend there was a movement > threshold on that finger. This advances the tap state machine properly that no button events are sent for this finger. https://bugs.freedesktop.org/show_bug.cgi?id=89625 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
- Apr 15, 2015
-
-
Peter Hutterer authored
Internal touchpads with trackpoints are either BUS_I8042 or BUS_I2C, but not BUS_USB. Lenovo sells external keyboards with a trackpoint built-in, make sure we don't pair that trackpoint with the internal touchpad. And likewise, the internal trackpoint should not be paired with e.g. a wacom touch device. Lenovo had one external device that has a trackpoint and a touchpad on an external keyboard. That device won't be covered with this patch, if we have a user we can re-consider. https://bugs.freedesktop.org/show_bug.cgi?id=89935 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
xinput or an equivalent isn't available under wayland, but the majority of use-cases of "why doesn't my device work" or "why does feature X not work" should be covered by simply listing the local devices and their config options. Example output: Device: SynPS/2 Synaptics TouchPad Kernel: /dev/input/event4 Group: 9 Seat: seat0, default Size: 97.33x62.40mm Capabilities: pointer Tap-to-click: disabled Left-handed: disabled Nat.scrolling: disabled Calibration: n/a Scroll methods: *two-finger Click methods: *button-areas clickfinger Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
Makes it quicker to know where it's coming from. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
All other config options already follow this behavior. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Apr 13, 2015
-
-
Peter Hutterer authored
This currently requires a specific udev rule to tag the device, once the matching bits are upstream we can drop this. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
Log a bug instead. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
Follow-up to e2f61b8f. Scroll events are sent through the pointer interface, so we must set the capability. Otherwise a caller may not have the required bits set up and is a bit surprised by events coming out of an interface the device doesn't actually have (xf86-input-libinput crashes when this happens). Reported-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
- Apr 11, 2015
-
-
Peter Hutterer authored
Prints the various pointer accel behaviors into a format understood by gnuplot, which then provides prettiness. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
- Apr 10, 2015
-
-
The main purpose of this patch is to allow the user to actually slow down pointer movement using libinput_device_config_accel_set_speed, this is achieved by changing the max-accel setting from "2.0 - speed" to "2.0 - speed * 1.5", resulting in a max-accel of 0.5 when the user configures speed at -1.0, the other accel profile parameters are adjusted by the same factor to keep the curve the same. This means that the user can get the exact same behavior as before by multiplying the old setting by 0.6667 (2/3), this also means that this change not only allows the user to select a slower speed, but to keep things balanced the same as before, also a higher speed. 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>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
This changes the current behavior of tapping enabled-by-default in the GUI helper. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Apr 09, 2015
-
-
Peter Hutterer authored
Less ambiguous since real_touches can be interpreted to "current number of real touches as opposed to fake touches". Which it isn't, this variable holds the number of slots. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-