If the kernel sends us a button press for a button that is thought to be down
we have lost track of the state of the button. Ignore the button press event,
in the hope that the next release makes things right again.
A release event may be masked if another process grabs the device for some
period of time, e.g. libinput debug-events --grab.
https://bugs.freedesktop.org/show_bug.cgi?id=101796
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 399c50dbeb)
Try to guess the default scroll buttons a bit better. Right now we default to
scroll button 0 (disabled) whenever a device doesn't have a middle button but
we might as well cast a wider net here as setting a scroll button only has a
direct effect when button scrolling is enabled.
Use the first extra button we find or fall back onto the right button if we
don't have any extra buttons.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This may be a feature for the future but for now be honest and don't claim
that button-based scrolling is available, it's not hooked up in the absolute
code path.
https://bugs.freedesktop.org/show_bug.cgi?id=99865
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Before, our states were idle, button down and scrolling. This adds a state
where the button is down and the timeout has expired (i.e. we're ready to send
scroll events) but we haven't actually sent any events anymore.
If the button is released in this state, we generate a normal click event.
https://bugs.freedesktop.org/show_bug.cgi?id=99666
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Device needs BTN_MIDDLE disabled, this way middle button emulation is present
by default.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The button-scroll by default behavior is only true on devices with a middle
button.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
And disable middle button emulation for this test, it would mess with the test
results.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This failed on devices without a middle button, we just didn't have a test
device to trigger this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We don't have the same libevdev context that libinput has so if libinput
disables/enables event codes we don't see that and may get unexpected
behavior in the test.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We don't initialize click methods on devices with physical buttons. This model
is a special case, it's not a clickpad but it only has one button (because one
button is all you ever need and whatnot).
https://bugs.freedesktop.org/show_bug.cgi?id=99283
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Usually we reply INVALID before we reply UNSUPPORTED but that's only for those
values where the value is a programming error. But in this case it's a bit
more complicated. INVALID is only for the cases where the button doesn't exist
on the device, if we don't have button scrolling at all then we have
UNSUPPORTED for all.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
They weren't originally prefixed but the various tests were, but now that we
only have one test runner binary anyway, the prefix helps sorting the files
easily within e.g. gcov results.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
