Commit Graph

115 Commits

Author SHA1 Message Date
Carlos Garnacho
942d144d3b gdk: Pass hardware ID on gdk_device_tool_new()
And implement this on wayland, where this information is already obtained.

https://bugzilla.gnome.org/show_bug.cgi?id=770026
2016-08-23 21:01:44 +02:00
Matthias Clasen
660c8b8f9b x11: Mark trackpoints as GDK_SOURCE_TRACKPOINT
This uses the same heuristics that are currently used in
GtkScrolledWindow.

https://bugzilla.gnome.org/show_bug.cgi?id=767100
2016-06-01 09:31:18 -04:00
Matthias Clasen
0f476590fb Make gdk_event_get_pointer_emulated public
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.
2016-05-10 15:16:45 -04:00
Frediano Ziglio
cf14fea5a8 Save scancode inside GdkEventPrivate
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
2016-04-21 22:35:47 -04:00
Matthias Clasen
9044f78751 Move GdkDeviceTool into its own files 2016-04-09 15:48:34 -04:00
Carlos Garnacho
6febc22918 x11: Use XInternAtom directly on poking device hardware IDs
This way we don't cache the property if it wasn't previously there,
added by the driver itself. Bailing out is due there.
2016-04-06 15:43:29 +02:00
Stephen Chandler Paul
9e72d24b23 GdkDeviceTool: Add GdkAxisFlags info to tablet tools
Different tools may have different sets of axes, we should store that
info somewhere.
2016-04-06 15:43:29 +02:00
Stephen Chandler Paul
8b2fd3ed1b GdkDeviceTool: Add GdkDeviceToolType to identify the physical tool type
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>
2016-04-06 15:43:29 +02:00
Carlos Garnacho
9a81b65959 x11: Set GdkDeviceTool on motion/button events
The last known tool from the device is used here. If no tool is known,
the event will just have a NULL pointer there.
2016-04-06 15:43:29 +02:00
Carlos Garnacho
0287ec7e89 x11: Update GdkDevices on "Wacom Serial IDs" property changes
This takes care of the emission of GdkDevice::tool-changed, plus the
updating of the internal device accounting.
2016-04-06 15:43:29 +02:00
Takao Fujiwara
7822f59a86 Set VirtualBox USB Tablet to GDK_SOURCE_MOUSE
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
2016-03-08 11:11:51 -05:00
Matthias Clasen
5522ce9649 xi2: Add some more debug spew
Log the valuators we use or ignore.
2016-02-25 21:19:31 -05:00
Matthias Clasen
a4a7740b2f xi2: Set ::num-touches for touch devices
XI2 has this information, so pass it on.
2016-02-25 08:27:08 -05:00
Matthias Clasen
c75a833633 x11: More fake tablet blacklisting
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.
2016-02-24 22:22:11 -05:00
Carlos Garnacho
f8b8e4eaf8 x11: Set event->scroll.is_stop
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
2016-01-18 21:36:23 +01:00
Dominique Leuenberger
d7e5fd2e2f QEMU USB Tablet is not really a tablet - it's a trick
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
2016-01-12 23:03:14 -05:00
Carlos Garnacho
d236fd7aab x11: Use GdkSeatDefault to implement GdkSeat
https://bugzilla.gnome.org/show_bug.cgi?id=759309
2015-12-15 00:32:55 +01:00
Carlos Garnacho
6e8d5f70db x11: Use gdk_event_set_device() consistently
Move the variable definitions above the function, and use those
throughout all branches of the event handling switch.
2015-12-15 00:16:15 +01:00
Carlos Garnacho
c5b7cd97b6 x11: Add "pointer" to the is-not-a-touchscreen device name checks
Commit 1266d15c4 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
2015-11-17 16:22:06 +01:00
Carlos Garnacho
b32c7c3282 x11: Do not misdetect mice with abs axes as touchscreens
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
2015-11-14 23:45:46 -05:00
Carlos Garnacho
29dd395b7a x11: Detect single-touch touchscreens as GDK_SOURCE_TOUCHSCREEN
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
2015-11-03 07:07:12 -05:00
Carlos Garnacho
dbf85cc4db x11: Declare variable for the inner loop
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 fdb9a8e14, many thanks to
Carlos Soriano for helping spot the source of this bug.

https://bugzilla.gnome.org/show_bug.cgi?id=753431
2015-09-09 16:46:26 +02:00
Carlos Garnacho
72bfb40ccf Revert "x11: Query pointer devices' scroll valuators on toplevel enter events"
This reverts commit 77b8495bc4.

The commit broke more scenarios than fixed, better to go back to square one.
2015-07-15 21:19:25 +02:00
Carlos Garnacho
77b8495bc4 x11: Query pointer devices' scroll valuators on toplevel enter events
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
2015-07-01 19:40:09 +02:00
Matthias Clasen
fdb9a8e142 x11: Fix compiler warnings
Fix warnings due to -Wdeclaration-after-statement and -Wshadow.
2015-06-02 09:08:14 -04:00
Carlos Garnacho
4cae9bdd05 x11: Store last axes from device
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
2015-03-02 18:57:04 +01:00
Carlos Garnacho
6f07d5e761 x11: Detect libinput touchpads
These aren't reported as XIDependentTouch devices, so make it poke a
property that's specific to touchpads managed by the libinput driver.
2015-02-02 13:55:38 +01:00
Carlos Garnacho
121fddc4d2 x11: Fetch vendor/product identifiers for input devices
These are retrieved from XInput device properties.

https://bugzilla.gnome.org/show_bug.cgi?id=740758
2015-01-19 15:09:19 +01:00
Jasper St. Pierre
8fb2bdb2fb gdkdevicemanager-xi2: Add debug output for key events 2014-06-29 19:10:42 -04:00
Jasper St. Pierre
de5cba4fc9 gdkdevicemanager-xi2: Fix debug outputs for button events
We had the arguments in the wrong order here.
2014-06-29 19:10:41 -04:00
Carlos Garnacho
3dbabbd2e5 x11: Handle all XI2 crossing mode values in switch
This fixes potential assertions if a GTK+ app gets to receive
a XINotifyPassiveGrab/Ungrab pointer crossing event, currently
triggerable by XIGrabEnter passive grabs.

http://bugzilla.gnome.org/show_bug.cgi?id=719762
2013-12-04 21:22:23 -05:00
Carlos Garnacho
a53a931755 x11: Unset GdkX11DeviceXI2 scroll valuators on device change
Scroll valuators were being just appended again and again, leading
to 1) a growing memory issue anytime a device changed 2) the first
scroll valuators to stay permanent on the application lifetime, as
the first stored valuators would always match.

https://bugzilla.gnome.org/show_bug.cgi?id=705203
2013-11-22 12:49:32 +01:00
Carlos Garnacho
fee754e0d2 gdk: Ignore crossings generated by passive grabs when resetting scroll axes
Passive grabs may take pointer focus out of the application, even though
the pointer didn't leave the window, but those events still trigger resetting
of the scroll axes. This is most visible with compiz, and possibly other
reparenting WMs, where passive grabs happen on the WM-managed window that
is a parent of the application toplevel.

As it is not possible to have scrolling happening on the timespan a passive
grab takes action, it is entirely safe for GTK+ to assume none happened if
it gets a crossing event of that nature.

https://bugzilla.gnome.org/show_bug.cgi?id=699574#c33
2013-11-18 22:12:18 +01:00
Carlos Garnacho
962415aeb7 x11: Add extra debug spew on XI2 crossing and button events
This information will be useful in case someone stumbles on a situation
similar to https://bugzilla.gnome.org/show_bug.cgi?id=699574, so we can
figure out where do the crossing events come from or go to easily.
2013-11-17 00:42:18 +01:00
Carlos Garnacho
4168c3cab9 gdk: be more selective resetting scroll events
It's been reported in several applications that scrolling feels jerky
since commit cc7b3985b3.

Investigation reported that the combination of passive 4-7 button grabs
on the toplevel and the presence of native subwindows might trigger
too often crossing events from the child window to the toplevel and
back as scroll "buttons" trigger the passive grab. Those crossing events
would reset the scroll valuators rendering scrolling from jerky on
touchpads (where there's intermediate smooth events between the emulated
button ones) to ineffective on regular mouse wheels (where the crossing
event would reset the valuators right before the single smooth scroll
event we get is delivered)

So, only reset scroll valuators when the pointer enters the toplevel
(we only care about this when the pointer is on the window after it's
been possibly scrolling somewhere else), and it doesn't come from an
inferior.

The situations where this happened varied though, the native subwindow
could be one created explicitly by the application, or created indirectly
through gdk_window_ensure_native(). The latter was mainly the case for
evolution (through gtk_selection_set_owner()) and any GtkScrolledWindow
under the oxygen-gtk3 theme (through gdk_window_set_composited())

https://bugzilla.gnome.org/show_bug.cgi?id=699574
2013-11-17 00:42:18 +01:00
Alexander Larsson
525e5cff04 x11: Initial cut at supporting window scaling for X11
If you set GDK_SCALE=2 in the environment then all windows will be
scaled by 2. Its not an ideal solution as it doesn't handle
multi-monitors at different scales, and only affects gtk apps.
But it is a good starting points and will help a lot on HiDPI
laptops.
2013-07-03 14:34:14 +02:00
Matthias Clasen
459e10196d GdkDeviceManagerXI2: chain up in constructed
Dispose does chain up, and the parent class' dispose expects
that the object has been fully constructed.
2013-06-29 19:21:28 -04:00
Mario Sanchez Prada
201410de60 Missing NULL-check in XI2's implementation for get_window()
Add missing check in gdk_x11_device_manager_xi2_get_window(), returning
NULL if no valid XI2Event* has been found. Calling code seems to be
prepared to handle NULLs coming from this function, so it should be
safe enough (e.g. check gdk_event_source_get_filter_window()).

https://bugzilla.gnome.org/show_bug.cgi?id=700465
2013-05-19 21:21:41 -04:00
David King
b0121ed0a1 xi2: Improve pointer emulation debug reporting
Reporting "true" or "false" is nicer than the value of the flag.

https://bugzilla.gnome.org/show_bug.cgi?id=697795
2013-04-11 15:56:13 +01:00
Carlos Garnacho
cc7b3985b3 xi2: Reset scroll valuators on synthesized crossing events
On crossing events resulting from moving windows (eg. workspace switch),
deviceid equals sourceid, so make those reset scroll valuators on all
slave devices to avoid misleading jumps in scroll events

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=690275
2013-04-10 20:18:09 +02:00
Ross Lagerwall
942c63d82b x11: Remove unused macro
https://bugzilla.gnome.org/show_bug.cgi?id=694395
2013-03-04 21:09:06 -05:00
Owen W. Taylor
06c4598fc5 GdkX11DeviceManagerXI2: handle focus events not on a known window
If we get a focus event for a X window we don't recognize, just
ignore it and avoid a g-critical when
_gdk_device_manager_core_handle_focus() is called with a NULL window.
2013-02-14 17:19:51 -05:00
Jasper St. Pierre
9dc4c5ce73 xi2: Abort early if we don't have a proper GDK window
This can happen in mutter or other applications that use GDK filters
but don't actually create GDK windows for everything they get events
for.

https://bugzilla.gnome.org/show_bug.cgi?id=689401
2012-12-13 10:51:38 -05:00
Owen W. Taylor
0aa989ae76 GtkPlug: fix handling of key events for different layouts
GtkPlug directly handles X KeyPress/Release events, instead of using
translation in GDK (which expects XI2 events for XI2). When this
was done, the handling of the group was stubbed out and never replaced.

Export gdk_keymap_x11_group_for_state() and gdk_keymap_x11_is_modifier()
so we can fill out the fields correctly.

https://bugzilla.gnome.org/show_bug.cgi?id=675167
2012-04-30 16:35:10 -04:00
Sam Thursfield
2e873e3fdc Fix build with XInput < 2.2
Fixes regression introduced in fa8e6f7857
2012-04-24 12:55:39 +01:00
Cosimo Cecchi
8bb3a2001f xi2: ignore extraneous events for smooth scroll
Since the event will be ignored anyway after it's translated (slave
devices are disabled), don't let it run in the smooth scroll code path,
as it will burn our caches for the actual event we're interested in.

https://bugzilla.gnome.org/show_bug.cgi?id=673644
2012-04-22 13:06:39 -04:00
Cosimo Cecchi
37149668c0 xi2: fix thinko in variable type
https://bugzilla.gnome.org/show_bug.cgi?id=673644
2012-04-22 13:01:08 -04:00
Matthias Clasen
5a41b74c5c XI2: More logging for smooth scrolling
In addition to the delta, log device information.
This was triggered by
https://bugzilla.gnome.org/show_bug.cgi?id=673644
2012-04-22 13:00:47 -04:00
Matthias Clasen
432f0151eb xi2: Remove touchscreen heuristics
It doesn't make sense to consider a device a touchscreen if it
doesn't have any touch classes. Even if it has 'touch' in its
name.
https://bugzilla.gnome.org/show_bug.cgi?id=673440
2012-04-06 20:00:35 -04:00
Matthias Clasen
9d1688680c xi2: Don't reset scroll valuators too often
According to XInput gurus, a motion event without valuators
does not invalidate the stored value, so we should keep it.

https://bugzilla.gnome.org/show_bug.cgi?id=671659
2012-03-08 22:35:43 -05:00