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.
The significant change here is a memory leak fix in init_xrandr15.
The rest of the changes makes init_xrandr13 and init_xrandr15 more
parallel, and simplifies init_multihead.
We should conform to a minimal set of reasons for the gtk side to emit
a better GtkDragResult than GTK_DRAG_RESULT_ERROR. This fixes the notebook
tab DnD feature, where we rely on GTK_DRAG_RESULT_NO_TARGET.
In the wayland side, unfortunately we can't honor either NO_TARGET nor
USER_CANCELLED, we don't know of the latter, so we could return false
positives on the former.
https://bugzilla.gnome.org/show_bug.cgi?id=761954
The fallback behaviour of get_work_area () divides the
screen width and height by the window scaling factor, but
those values are already scaled down.
https://bugzilla.gnome.org/show_bug.cgi?id=761474
Set _GTK_THEME_VARIANT to empty string when default theme variant
is used. This will allow to understand whether _GTK_THEME_VARIANT
is not supported or default variant is requested.
https://bugzilla.gnome.org/show_bug.cgi?id=761476
Presently, Gtk will only send a startup notification completion message
for the first window that is shown. This is not good for the case of
GtkApplication, where we are expected to participate in
startup-notification for all windows.
We have avoided this problem by manually emitting the startup complete
message from after_emit in GtkApplication.
Unfortunately, this causes problems for windows that are shown with a
delay. It is also a dirty hack.
The reason for the original behaviour is simple: there is a static
boolean in gtkwindow.c which controls it. We remove this.
Instead, clear the startup notification ID stored in GDK when sending
the completion message. GtkApplication will re-set this the next time
an event comes in which needs startup-notification handling. In the
non-GtkApplication case, newly shown windows will still not send the
message, since the cookie will have been cleared.
Finally, we remove the hack from GtkApplication's after_emit.
This will probably cause some regressions in terms of lingering startup
notification messages. The correct solution here is to always use
gtk_window_present(), including when merely opening a new document (with
a new tab, for example).
https://bugzilla.gnome.org/show_bug.cgi?id=690791
This includes managing input events and source-side DND events,
as well as setting the appropriate cursor and emitting the signals
that are expected in this mode of operation.
We are getting the mime data destroy notify called when we
destroy the surface in finalize. Trying to set the XSync counters
at this time is a) pointless and b) yielding an X error because
the counters have already been destroyed.
To avoid this, unhook the damage tracking before destroying
the surface.
https://bugzilla.gnome.org/show_bug.cgi?id=760188
We are setting mime data with a destroy notify on the cairo
surface to get notified when cairo registers damage for the
surface (in that case, it clears the mime data, calling the
destroy notify). Unfortunately, the destroy notify is also
called when we remove the mime data ourselves, which was
not intentional.
Use a flag in the window impl struct to ignore the callback
when we are clearing the hook.
Instead of creating an intermediate pixbuf, just render
the window surface onto the new surface. Doing things this
way lets us avoid the cairo_surface_mark_dirty() call in
gdk_pixbuf_get_from_window(), which is not generally safe
to call on 'random' surfaces - it asserts that the surface
has no mime data attached, and the X11 backend uses mime
data for damage tracking purposes...
We destroy the widget that is wrapped around the drag window
when the object data on the drag context gets cleared. Destroying
the window before that happens leads to unpleasantries. E.g. we may
try to access the frame clock, which doesn't exist anymore, and
things go downhill from there. So, keep the window alive for
a little longer.
Always returning a left_ptr if we can't find anything better
broke firefox application-specific fallback for missing cursors.
Keep that working by only doing the fallback for the CSS cursor
names, not for things like hashes.
https://bugzilla.gnome.org/show_bug.cgi?id=760141
Showing the drag cancel animation can be done in the X11
drag context implementation now that we hold the drag
window there, and have the start coordinates.
Since we can't control if and when the application destroys
the drag widget, we take a snapshot of the window contents
and display that during the animation. This should be good
enough for all practical purposes.
Add a variant of gdk_drag_begin that takes the start position
in addition to the device. All backend implementation have been
updated to accept (and ignore) the new arguments.
Subsequent commits will make use of the data in some backends.
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
We currently just look for a master device with input source MOUSE.
After recent changes to the way input devices are classified, xwayland
on my system comes up with a virtual core pointer that has input
source TOUCHSCREEN. This was causing assertion failures. Be a little
more careful and accept a touchscreen as core pointer, if there is
no mouse.
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
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
Using a NULL GAppInfo with g_app_launch_context_get_display() will
generate a critical warning in gio.
Use the display name instead as we don't have any valid GAppInfo to pass
to g_app_launch_context_get_display().
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756439
If GLX has support for the GLX_ARB_create_context_profile extension,
then we use the GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB; if it does
not, we fall back to the old glXCreateNewContext() API.
We use the shared GdkGLContext to decide whether the GLX context should
use the legacy bit or not.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
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
