We want to avoid handling focus events for the private focus window,
otherwise the keyboard grab taken by for example buttons will cause a
spurious FOCUS_OUT/FOCUS_IN on the toplevel.
The code that did this seems to have been lost in the XI2 transition for
GTK3.
This patch reapplies db4a6040af which was
backed out in 18406b7b04 to give
developers a chance to get their X servers fixed. As we want to get this
bugfix in for 3.4, we need to commit it now.
https://bugzilla.gnome.org/show_bug.cgi?id=657578
XI2 provides us with an increment for each scroll valuator,
and by dividing the delta by the increment, we obtain normalized
values in some abstract 'scroll unit'.
For mouse wheels, the evdev driver reports an increment of -1,
so doing this division fixes the inverted scrolling with wheels
that we've seen recently.
XInput >= 2.1 allows for implementing smooth scrolling,
reporting the different scrolling axes as valuators.
Any change in those will be reported as GdkEventScroll
events with delta_x/y information.
the older kind of scroll events is still handled, and
emulated in devices able to provide smooth scrolling,
setting _gdk_event_set_pointer_emulated() in that case.
Translate XI_TouchBegin/Update/End to GDK_TOUCH_BEGIN/UPDATE/END
events.
At the same time,
set pointer-emulated flags on button events with XIPointerEmulated
and on touch events emulating the pointer.
We want to avoid handling focus events for the private focus window,
otherwise the keyboard grab taken by for example buttons will cause a
spurious FOCUS_OUT/FOCUS_IN on the toplevel.
The code that did this seems to have been lost in the XI2 transition for
GTK3.
https://bugzilla.gnome.org/show_bug.cgi?id=657578
Dealing with disabled devices may turn into hierarchy/device
changed events on device IDs with no backing GdkDevice yet,
so protect against that. The device attachment will be handled
correctly when the device is enabled later.
Fixes bug #658379 - Disabled devices still added to list on startup,
spotted by Bastien Nocera. Do not create GdkDevices for disabled
devices on device manager construction, leading to a confusing initial
state.
https://bugzilla.gnome.org/show_bug.cgi?id=653947
It could happen that a cookie event has been already allocated/freed
in an event filter, as it can't be allocated a second time, all GDK
can do is skipping the event. Spotted by Guillaume Desmottes.
This function can be used to find the GdkDevice wrapping
an XInput2 device ID. For core devices, the Virtual Core
Pointer/Keyboard IDs (2/3) may be used.
Fixes Bug 645993 - XIM has wierd behaviors. Some XIM modules
filter every key event, possibly replacing it with their own
one. These events usually have serial=0, so make
GdkDeviceManagerXI2 also listen on these.
The XI2 device manager was mistakenly setting the window user_time on
both ButtonPress and ButtonRelease, which meant that processes that
tried to launch another process based on the time of a ButtonPress
event would end up always focus-stealing-preventing the new app.
https://bugzilla.gnome.org/show_bug.cgi?id=647275
_gdk_device_get_axis_use() dates back to pre-sealing, when the
xi2 work began, this remaining can be gone with a public
gdk_device_get_axis_use() function already in place.
XSendEvent doesn't currently work with XI2 events, so add code to
translate core events when they have the send_event flag.
(We still don't actually select for core pointer/keyboard events, so
we will only receive send_event events that are sent with a 0
event_mask.)
https://bugzilla.gnome.org/show_bug.cgi?id=644847
Previously we weren't installing the device headers when compiling
without XINPUT support. But we would include them from gdkx.h, so
essentially the build was broken.
With this patch the types will exist but not do anything.
Moving the direct-access redefinitions of various macros
to gdkprivate-x11.h and use that header throughout in x11/.
Also remove a workaround for a long-fixed X server bug.
The xi2 device manager now handles slaves being detached and/or
attached to a master.
gdk_device_list_slaves() has been added so it is possible to
know how slaves relate with masters. The other backends (X11 and not)
don't neeed to to anything special here since their hierarchy is
fully flat.
When the slave device changes, the master takes the shape of the
new one, modifying its axes, this signal is more useful to catch
this situation than the n-axes property
This function may be used to know the hardware device that triggered
an event, it could resort to the master device in the few cases there's
not a direct hardware device to relate to the event (i.e.: crossing events
due to grabs)
* _gdk_device_set_associated_device() did not allow NULL device
* GdkDisplay should dispose device manager to avoid devices
trying to touch the display in finalize
* GdkDeviceManagerXI did not ref devices in id hash
* GdkDisplayX11 did not ref devices in ->input_devices
The keysyms create a lot of potential namespace conflicts for
C, and are especially problematic for introspection, where we take
constants into the namespace, so GDK_Display conflicts with GdkDisplay.
For C application compatiblity, add gdkkeysyms-compat.h which uses
the old names.
Just one user in GTK+ continues to use gdkkeysyms-compat.h, which is
the gtkimcontextsimple.c, since porting that requires porting more
custom Perl code.
This function makes a better replacement for
gdk_display_get_core_pointer(), wherever it might yet be needed, for
XI2 resorts to XIGetClientPointer(), for the others return the only
core pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=621685
