neldredge authored Sep 17, 2022 and Luca Bacci committed Sep 17, 2022

Add "stylus" to the list of substrings in a device name that cause it to be recognized
as a GDK_SOURCE_PEN device (previously "wacom", "pen" and "eraser").  Some devices
just use "stylus" in their name, and are otherwise recognized as
GDK_SOURCE_TOUCHSCREEN instead.

Fixes #4394.

When a device is added, there are two references to it by the device
manager, the initial one and the one used for the id_table. Removing a
device only removed the reference added by the id_table resulting in the
GdkDevice being leaked.

!1359

Tools on the same physical item have the same serial number, so the eraser
and the pen part of a single pen share that serial number. With the current
lookup code, we'll always return whichever tool comes first into proximity.

Change the code to use the hw id in addition to the serial number, this way we
can differ between two tools.

Generic tools (Bamboo, built-in tablets) always have the same serial number
assigned by the wacom driver. This includes the touch tool when the wacom
driver handles the touch evdev node (common where users require the wacom
gestures to work).

When the first device is the touch device, a tool is created with that serial.
All future tools now return the touch tool on lookup since they all share the
same serial number. Worse, this happens *across* devices, so the pen
event node gets assigned the touch tool because they all have the same serial.

Since we don't actually care about the touch as a tool, let's skip any unknown
tool. This captures pads as well.

Any wacom device currently sets the tool type to UNKNOWN. The wacom driver has
a property that exports the tool type as one of stylus, eraser, cursor, pad or
touch. Only three of those are useful here but that's better than having all
of them as unknown.

Benjamin Otte authored Dec 16, 2017 and Carlos Garnacho committed Jun 20, 2018

(Backported from master 3438dcdd)

This property contains 5 integers, of which the last 2 respectively
contain the tool serial number and tool ID. We were only extracting the
first so far, but GdkDeviceTool also has API getters for the latter,
which remained 0.

https://bugzilla.gnome.org/show_bug.cgi?id=786400

Jason Gerecke authored Jun 27, 2017 and Carlos Garnacho committed Jun 30, 2017

Wacom tablets often have a "pad" device which houses multiple buttons. At
present, these devices are incorrectly marked as GDK_SOURCE_PEN which can
cause problems for some software.

https://bugzilla.gnome.org/show_bug.cgi?id=782040

Timm Bäder authored Mar 19, 2017 and Daniel Boles committed Mar 20, 2017

The 2 values added in 3.22 were missing from the source_names array.

There was a return between a push/pop of an error trap, and
this managed to trigger the 'unpopped trap' warning in the
displayclose test now. Fix this.

And implement this on wayland, where this information is already obtained.

https://bugzilla.gnome.org/show_bug.cgi?id=770026

This uses the same heuristics that are currently used in
GtkScrolledWindow.

https://bugzilla.gnome.org/show_bug.cgi?id=767100

There is not strong reason to keep the getter private.
At the same time, strip _-prefixes from a few other GdkEvent
APIs. Update all callers.

Frediano Ziglio authored Apr 21, 2016 and Matthias Clasen committed Apr 21, 2016

Windows save in hardware_keycode an information which is not so low
level and some application require the hardware scancode.
As Windows provides this information save it in GdkEventPrivate
and provide a function to get this information.
For no Windows system the function return the hardware_keycode instead.

Signed-off-by: Frediano Ziglio <fziglio@redhat.com>

https://bugzilla.gnome.org/show_bug.cgi?id=765259

This way we don't cache the property if it wasn't previously there,
added by the driver itself. Bailing out is due there.

Lyude Paul authored Jun 22, 2015 and Carlos Garnacho committed Apr 06, 2016

Different tools may have different sets of axes, we should store that
info somewhere.

Lyude Paul authored Jan 13, 2015 and Carlos Garnacho committed Apr 06, 2016

Because there are multiple different types of styluses that can be used with
tablets, we have to have some sort of identifier for them attached to the
GdkDeviceTool, especially since knowing the actual tool type for a GdkDeviceTool
is necessary for matching up a GdkDeviceTool with it's appropriate
GdkInputSource in Wayland (eg. matching up a GdkDeviceTool eraser with the
GDK_SOURCE_ERASER GdkInputSource of a wayland tablet).

Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>

The last known tool from the device is used here. If no tool is known,
the event will just have a NULL pointer there.

This takes care of the emission of GdkDevice::tool-changed, plus the
updating of the internal device accounting.

Takao Fujiwara authored Mar 08, 2016 and Matthias Clasen committed Mar 08, 2016

The virtual host assigns the name of the mouse device to
"VirtualBox USB Tablet" in VirtualBox and we'd use that device as mouse.
If not, GtkTooltip is not enabled.

https://bugzilla.gnome.org/show_bug.cgi?id=763017

Log the valuators we use or ignore.

XI2 has this information, so pass it on.

Sigh.

Now that we've neutered the QEMU USB tablet, I'm finding that
spice is doing just the same nonsense. It has a fake "spice vdagent
tablet". Blacklist that as well.

We still figure this out from 0/0 scroll events. This method is
not intended to last forever, but it's something we can cling to
so far.

https://bugzilla.gnome.org/show_bug.cgi?id=756729

Dominique Leuenberger authored Jan 12, 2016 and Matthias Clasen committed Jan 12, 2016

Unfortunately, Qemu gives us this confusing device to work with,
and the best we can do is filter it out based on its name.

https://bugzilla.gnome.org/show_bug.cgi?id=760445

https://bugzilla.gnome.org/show_bug.cgi?id=759309

Move the variable definitions above the function, and use those
throughout all branches of the event handling switch.

Commit 1266d15c also broke Xwayland, as it does the same trick
than VMWare pointers. Let's extend the heuristic to check for "pointer"
in the device name, what can possibly go wrong...

https://bugzilla.gnome.org/show_bug.cgi?id=757358

Carlos Garnacho authored Nov 13, 2015 and Matthias Clasen committed Nov 14, 2015

VMWare seems to create mouse devices with abs axes which confuses
our detection of single-touch touchscreens. Those have though a
name we can match on ("VirtualPS/2 VMware VMMouse"), it should
be pretty safe to assume that no real touchscreens have "mouse"
in their name...

https://bugzilla.gnome.org/show_bug.cgi?id=757358

Carlos Garnacho authored Oct 30, 2015 and Matthias Clasen committed Nov 03, 2015

Those won't have ABS_MT_* axes, so won't be reported has having
XITouchClassInfo. Fallback on these to checking whether abs x/y axes are
available. After the Wacom checks, any remaining device with absolute axes
should be touchscreens, and GDK_SOURCE_MOUSE does indeed just make sense on
devices with relative axes.

https://bugzilla.gnome.org/show_bug.cgi?id=757358

Otherwise the outer loop control variable is messed up, and we end
up with uninitialized axes if there were any more valuators after
the XIKeyClass one.

This bug was sneakily introduced by fdb9a8e1, many thanks to
Carlos Soriano for helping spot the source of this bug.

https://bugzilla.gnome.org/show_bug.cgi?id=753431

This reverts commit 77b8495b.

The commit broke more scenarios than fixed, better to go back to square one.

We used to "invalidate" scroll valuators, so the next scroll event could
be used as the base for the next scroll deltas. This has the inconvenience
that it invariably consumes the first event received after enter and,
due to interactions with WM overeager passive button grabs, there's a
possibility we don't scroll at all if we receive interleaved "smooth
scroll" XI_Motion events and XI_Enter events (Normally triggered by regular
scroll wheels in mice).

In order to fix this, and at the expense of some sync-call overhead on
XI_Enter events (one XIQueryDevice call per slave device), query the
current scroll valuator state for all the slaves of the entered pointer,
so we do know beforehand the right base values. If new devices are plugged
while the pointer is on top of the client, the initialized scroll values
will match the valuators'.

https://bugzilla.gnome.org/show_bug.cgi?id=750994
https://bugzilla.gnome.org/show_bug.cgi?id=750870

Fix warnings due to -Wdeclaration-after-statement and -Wshadow.

And use these for the missing axes if the valuator mask is incomplete.
This used to work fine on tablets because the Wacom driver ensures all
valuators are sent, which is not true if using the evdev driver.

https://bugzilla.gnome.org/show_bug.cgi?id=703610

These aren't reported as XIDependentTouch devices, so make it poke a
property that's specific to touchpads managed by the libinput driver.

These are retrieved from XInput device properties.

https://bugzilla.gnome.org/show_bug.cgi?id=740758