We were drawing an arc but apparently in white which made it a tad hard
to see on a white background. Draw this with the same color as the
touchpoints so we can debug single-touch and tablet devices too.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1011>
Some tablets such as those in the XP-PEN PRO series use "dials" which
are actually scrollwheels and emit EV_REL events. These should not be
emulated as rings (which are absolute) so we must expose them as a new
tablet event.
Adds LIBINPUT_EVENT_TABLET_PAD_DIAL that work largely identical as our
high-resolution wheel events (i.e. the values are in multiples or
fractions of of 120). Currently supports two dials.
This is a lot of copy/paste from the ring axes because the interface is
virtually identical. The main difference is that dials give us a v120
value in the same manner as our scroll axes.
Notes:
- REL_DIAL is mutually exclusive with REL_WHEEL, we assume the kernel
doesn't (at this point) give us devices with both. If this changes for
devices with three dials (wheel + hwheel + dial) we need to add code
for that.
- REL_DIAL does not have a high-resolution axis and we assume that any
device with REL_WHEEL_HI_RES will also have REL_HWHEEL_HI_RES (if the
second wheel exists).
- With dials being REL_DIAL or REL_WHEEL there is no possibility of
detecting a finger release (the kernel does not route EV_RELs with a
value of zero). Unless this is implemented via a side-channel - and it
doesn't look like any hardware that supports dials does that - we
cannot forward any information here. So unlike absolute rings we
cannot provide a source information here.
Closes#600
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/967>
On Sway, and probably other Wayland compositors based on wlroots, the
window_lock_pointer() was called twice.
Avoid errors when window_lock_pointer() is invoked multiple times.
Fix https://gitlab.freedesktop.org/libinput/libinput/-/issues/808
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
We have two different dependencies on Wayland: GTK support and the
wayland-protocols we use directly. If we have GTK support but
wayland-protocols is not installed at meson configure time, our build
fails.
To avoid having multiple ifdefs in the code, let's define two new ones:
HAVE_GTK_WAYLAND and HAVE_GTK_X11, both set if GTK supports that
particular target (from pkgconfig) and we have the other support
libraries we need.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All cases we have in our code base have an otherwise unused variable to
loop through the array. Let's auto-declare this as part of the loop.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Starting with kernel v5.0 two new axes are available for high-resolution wheel
scrolling: REL_WHEEL_HI_RES and REL_HWHEEL_HI_RES. Both axes send data in
fractions of 120 where each multiple of 120 amounts to one logical scroll
event. Fractions of 120 indicate a wheel movement less than one detent.
This commit adds a new API for scroll events. Three new event types that encode
the axis source in the event type name and a new API to get a normalized-to-120
value that also used by Windows and the kernel (each multiple of 120 represents
a logical scroll click).
This addresses a main shortcoming with the existing API - it was unreliable to
calculate the click angle based on the axis value+discrete events and thus any
caller using the axis value alone would be left with some ambiguity. With the
v120 API it's now possible to (usually) calculate the click angle, but more
importantly it provides the simplest hw-independent way of scrolling by a
click or a fraction of a click.
A new event type is required, the only way to integrate the v120 value
otherwise was to start sending events with a discrete value of 0. This
would break existing xf86-input-libinput (divide by zero, fixed in 0.28.2) and
weston (general confusion). mutter, kwin are unaffected.
With the new API, the old POINTER_AXIS event are deprecated - callers should use
the new API where available and discard any POINTER_AXIS events.
Notable: REL_WHEEL/REL_HWHEEL are emulated by the kernel but there's no
guarantee that they'll come every accumulated 120 values, e.g. Logitech mice
often send events that don't add up to 120 per detent.
We use the kernel's wheel click emulation instead of doing our own.
libinput guarantees high-resolution events even on pre-5.0 kernels.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Move the code used to pace the different UI elements to its own
function.
Refactor, no functional changes.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Add hold gestures to the public API and the private functions to notify them.
Also add hold gestures to debug-events and debug-gui.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Add a second grey v-shaped (upside down triangle) pointer that moves around
with the unaccelerated deltas. This makes it easier to visualize how the
unaccelerated pointer moves around, the snake helps for some use-cases but not
all of them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The messages with priority DEBUG refer to the various internal state machines
updating, so it's useful to know when they did so. Let's count up every time
we trigger libinput_dispatch() so we know how the messages group together.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a closer approximation of all callers anyway, and it makes it easier
to debug which events are handled per libinput_dispatch() call.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This allows us to run the option parsing test without getting interrupted by a
million debug-gui windows popping up for half a second.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This shuts up scan-build complaining about memory leaks in libinput
debug-events (needs the right combination of --device option and eventually
triggering usage()) and saves us a bunch of unnecessary allocations.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Wacom Cintiq 24HD and later tablets send specific key events for
hardware/soft buttons. KEY_PROG1..KEY_PROG3 on earlier tablets,
KEY_CONTROLPANEL, KEY_ONSCREEN_DISPLAY, and KEY_BUTTONCONFIG on later tablets.
We ignore KEY_PROG1-3 because starting with kernel 5.4 older tablets will too
use the better-named #defines.
These differ from pad buttons as the key code in itself carries semantic
information, so we should pass them on as-is instead of mapping them to
meaningless 0-indexed buttons like we do on the other buttons.
So let's add a new event, LIBINPUT_EVENT_TABLET_PAD_KEY and the associated
functions to handle that case.
Pad keys have a fixed hw-defined semantic meaning and are thus not part of
a tablet mode group.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Both of these are normalized so let's draw a bar that shows the values
accordingly. This makes it a lot easier to check whether pressure values go to
the maximum, etc.
A little extra square is shown whenever the tip is logically down.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Positive side-effect - this exposed a bunch of missing #includes that got
pulled in by other headers before.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And when that happens, skip the tests because what's happening here is that
you're running tests as root, but your X server doesn't allow root to connect.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the public API only, not the internal bits, so nothing will work just
yet.
This interface addition is for the Dell Canvas Totem tool, so let's go with
the same name because options like "Rotary" are too ambiguous.
The totem is a knob that can be placed on the surface, it provides us with
location and rotation data. The touch major/minor fields are filled in by the
current totem, but they're always the same size.
The totem exports BTN_0 as well, so let's add that to the debug-events output.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Draw a second smaller scroll bar that moves with every discrete step. For that
to work, we have to accumulate the value from the normal scroll events until
we get the first discrete one, then move up.
The value per discrete event changes depending on the click wheel angle, so we
can't just use discrete on its own if we want the two scroll bars aligned.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On the Dell Canvas Totem, the tool will cancel existing touch points and to
visually debug that, we need the touchpoints to be drawn over the tool.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Buttons that aren't lmr are drawn in a separate button square now with the
name as it comes from the kernel. This only handles one button at a time, but
it'll do for debugging.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Listen to the pure evdev events from each device and print them. This makes it
slightly easier to associate certain jumps with the output, or otherwise see
that events are coming in even when libinput doesn't seem to process them
anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the most common use-case other than "all from udev", so let's just
parse a device path correctly without requiring --device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
