Commit Graph

2188 Commits

Author SHA1 Message Date
Matthias Clasen
c3503fcc84 x11: Be quiet on exit by default
The condition we check for to catch X servers going away
may not be accurate anymore, and the warning shows up in
logs, causing customers to be concerned. So, be quiet by
default, unless the user explicitly asked for a message.
2021-04-13 20:42:21 -04:00
Olivier Fourdan
39db784704 x11/dnd: Ignore XErrors from the COW
The DnD code for X11 adds the composite overlay window (aka COW) to the
cache.

Yet the X11 requests to get and release the COW may trigger XErrors that
we ought to ignore otherwise the client will abort.

Fixes: #3715
2021-03-22 15:35:13 +01:00
Sam Bazley
a91de44755 gdk: Fix parent relative background crash
When setting a window's background to ParentRelative on X11, the window
depths must match to avoid a BadMatch error. Query the X server for the
parent window rather that relying on the parent passed to
gtk_window_new() to prevent crashes with reparented windows.

Fixes: #3288
2020-10-27 18:29:21 +00:00
Rene Hopf
69334021a2 force redraw in glareawhen buffer_age is 0
Reading form the back buffer is not allowed on software renderers,
and this is reported by the buffer age, so reading from GL_BACK
should not be done when the age is 0

Closes #64
2020-05-10 21:21:08 +02:00
Matthias Clasen
9c832b388b Merge branch 'gdk-device-leak-fix-gtk3' into 'gtk-3-24'
GdkDevice leak fix

See merge request GNOME/gtk!1359
2020-01-30 09:10:50 +00:00
Alberts Muktupāvels
6609a9f061 x11: add support for _GTK_WORKAREAS_Dn
If window manager supports _GTK_WORKAREAS use per-monitor work areas.

https://mail.gnome.org/archives/wm-spec-list/2018-December/msg00000.html
https://gitlab.freedesktop.org/xdg/xdg-specs/merge_requests/22

https://gitlab.gnome.org/GNOME/gtk/merge_requests/478
2020-01-28 14:51:22 +02:00
Sebastian Keller
9ce66b9d05 gdk/x11: Properly unref removed device in XI2 device manager
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.

https://gitlab.gnome.org/GNOME/gtk/merge_requests/1359
2020-01-27 22:06:49 +01:00
Alberts Muktupāvels
489fb1783b gdkscreen-x11: update device scale also for root window
Window scale can change at runtime. If cairo_surface is already
created for root window gdk_pixbuf_get_from_window will return
wrong image.

_gdk_x11_screen_set_window_scale already updates window_scale for
root window, update also cairo_surface device scale.

https://gitlab.gnome.org/GNOME/gtk/merge_requests/1208
2020-01-03 18:50:14 +02:00
Robert Mader
a3cff0add1 x11: Honor hotspot during drag cancel animation
Otherwise the icon "jumps" to the cursor position with its top left when
the animation starts.
This is especially visible if the dragged item is big, like when dragging
mails in Thunderbird.
2019-12-09 01:22:11 +01:00
Matthias Clasen
3857077701 Merge branch 'build-remove-xiproto-xreply-check' into 'gtk-3-24'
autotools: remove NEED_XIPROTO_H_FOR_XREPLY check

See merge request GNOME/gtk!1058
2019-08-25 11:46:40 +00:00
Alexander Larsson
e417fa1b7a Fix profiling output when rendering with OpenGL
I was not getting any gtk+ profile markers output from the frame clock
when I was profiling an OpenGL app (gnome-hexgl). I debugged this and
it turns out that the profiling depends on getting the _NET_WM_FRAME_TIMINGS
event from the compositor, and once we switched to OpenGL rendering
this never appeared.

It turns out the reason it didn't is that the compositor only does
so if the client increases the counter tied to the window, and the
x11 gdk code has this optimization where if we do a draw pass
but nothing is actually drawn we don't update the counter.

Unfortunately the detection of whether something was draw or not
is based on some cairo surface hack that breaks when we render with
OpenGL instead. The fix is to just always update the counter if
we're drawing with OpenGL.
2019-08-23 23:18:32 +03:00
Christoph Reiter
a1c1c788c9 autotools: remove NEED_XIPROTO_H_FOR_XREPLY check
This was added with https://bugzilla.gnome.org/show_bug.cgi?id=148032
to make gtk compile against X11R5, see commit 3b9a31df0

That release is >20 years old now, so we can safely remove it.

The motivation for this is to remove any checks that we don't have in the
meson build.
2019-08-21 20:39:15 +02:00
Jonas Ådahl
9dd198e53f gdk/x11: Clamp window size both when creating and resizing
We clamp to 32767 when creating a new X11 GdkWindow due to larger sizes
not being supported, but still try to resize to larger when
gdk_window_resize() is called. Fix this by clamping in both places.

This fixes an issue in mutter where ridiculously sized Java windows
would not show up.
2019-08-06 11:13:55 +02:00
Priit Laes
50a32b4b99 gdk: x11: Fill GdkMonitor manufacturer with PNP id from EDID
Previously, the manufacturer property of the GdkMonitor was NULL,
and having at least PNP id at GdkMonitor.manufacturer makes it
possible to distinguish between different monitors programmatically.
2019-06-26 12:07:52 +03:00
Emmanuele Bassi
5b54f86aee Set the monitor's connector under X11
Like we do on Wayland.

In this case, we copy it from the same source as the output name,
because it's going to match.
2019-06-20 22:51:47 +01:00
Christian Hergert
ef67eb0b3c gdk: backport GdkProfiler
This is a backport of the GdkProfiler from master. It does not include
the pixel bandwidth numbers that come from gdkdrawcontext.c since there
does not seem to be an analog in 3.x.

Additionally, this implements the recent changes for SYsprof's D-Bus
profiler API which adds a Capabilities property and an options hash-table
to the D-Bus interface for forward portability.
2019-06-06 17:17:20 -07:00
Matthias Clasen
044383fe45 Add a gtk-overlay-scrolling setting
This is in preparation for letting user opt out of
overlay scrolling in the control-center.
2019-05-31 11:54:06 -04:00
Christian Hergert
a8a56e8a0e marshallers: ensure g_cclosure_marshal_VOID__VOIDv is used
If we set c_marshaller manually, then g_signal_newv() will not setup a
va_marshaller for us. However, if we provide c_marshaller as NULL, it will
setup both the c_marshaller (to g_cclosure_marshal_VOID__VOID) and
va_marshaller (to g_cclosure_marshal_VOID__VOIDv) for us.
2019-05-29 13:30:15 -07:00
Christoph Reiter
d52dad2042 autotools: dist all meson related build files 2019-04-11 16:45:36 +02:00
Nirbheek Chauhan
20c29fd8c0 meson: Fix introspection generation on Linux 2019-04-11 16:45:36 +02:00
Nirbheek Chauhan
a4fe15d9f0 meson: Sync build files with master and update to 3.24 2019-04-11 16:45:27 +02:00
Jan Alexander Steffens (heftig)
2d3936cbe6
Centralize DESKTOP_STARTUP/AUTOSTART_ID handling
Add private API to GDK to move these variables from the environment into
static scope. Also move the DESKTOP_STARTUP_ID validation here to reduce
code duplication.

Use constructors to read them as early as possible; however, do not
unset them until first requested. This avoids breaking gnome-shell and
gnome-settings-daemon, which want to use the DESKTOP_AUTOSTART_ID in
their own gnome-session clients.

Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1761
2019-04-02 09:14:35 +02:00
Matthias Clasen
3da6497d9f gdk: Stop using deprecated pango api 2019-01-31 14:07:28 -05:00
Samuel Thibault
e84016cd17 Revert "gdk: deactivate/activate surface on keyboard grabs"
This reverts commits f23bfc6b69. and
c926b28d96.

This reintroduces #85, but see discussion in
https://gitlab.gnome.org/GNOME/gtk/merge_requests/433 for the unforeseen
invasive consequences of these commits.
2019-01-04 17:07:18 +01:00
Matthias Clasen
5662f2e34f Fix XChangeProperty calls
They must be long...

Closes: #1556
2019-01-02 19:32:00 -05:00
Carlos Garnacho
33faf46516 Merge branch 'wip/wacom-tool-type-from-property-3.24' into 'gtk-3-24'
Wacom tool type fixes

See merge request GNOME/gtk!453
2018-12-18 20:09:40 +00:00
Peter Hutterer
7b33369bfb x11: make the tool lookup dependent on the hw id as well
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.
2018-12-18 10:48:03 +10:00
Peter Hutterer
c6dd92294d x11: don't add unknown tools to our list
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.
2018-12-18 10:48:02 +10:00
Peter Hutterer
f173d1bc5c x11: get the tool type from the wacom driver properties
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.
2018-12-18 10:47:26 +10:00
Daniel Boles
e3a1593a09 x11: Fix deprecation macro use
G_GNUC_END_IGNORE_DEPRECATIONS terminates the if statement and does not
consider the following block to be part of the if. So that block was
always taken irregardless of the pattern.

Fixes #1280
2018-12-13 17:22:22 +01:00
Benjamin Otte
6a47e9a8b9 x11: Be a lot more careful about setting ParentRelative
We don't want to set ParentRelative when:

- the parent window is NULL
  In that case we are unsure about the depth, so better err on the side
  of caution and avoid a BadMatch by accepting ugly output.
- the cairo pattern is in an error status
  This should never happen - unless you start up in OOM - but better
  be safe than sorry.

Might help with the spurious crashes in #1280.
2018-12-13 05:28:54 +01:00
Szunti
4c8fcd6a6f Add gdk_x11_display_get_parent_relative_pattern().
Fixes #1280, tray icons not drawing background. This is a magic pattern only
usable for gdk_window_set_background_pattern() that sets the underlying
X window's background to ParentRelative.
2018-12-12 02:56:35 +01:00
Christoph Reiter
31b810abca g-i: Add some nullable annotations
Based on grepping arg docs for NULL.
See https://gitlab.gnome.org/GNOME/pygobject/issues/261
2018-11-18 13:40:24 +01:00
Uli Schlachter
9ca38c4647 Fix race in GtkPlug window creation
According to the XEmbed specification, a window should be created
"elsewhere" and then reparented into the target parent window. Instead,
GTK+ creates the window directly in desired target parent window. This
allows some races to occur.

Another program that does not follow XEmbed is tabbed. XEmbed requires
an _XEMBED_INFO property on the to-be-embedded window, but tabbed does
not check for this property. Thus, as soon as GTK+ creates its window,
tabbed starts managing this window and now GTK+ setting up the window
races with tabbed starting to manage the window.

If tabbed is fast enough to map the window, GTK+ never sees a MapNotify
event, because it did not yet select StructureNotifyMask on its window.
This results in a black window inside of tabbed.

Note that this cannot really be fixed in tabbed, since XEmbed says that
the _XEMBED_INFO property must be already present when the window
appears. Thus, patching tabbed to wait for _XEMBED_INFO to appear is not
something that the spec requires/allows.

Instead, this commit changes GTK+ so that it directly sets the right
event mask when the window is created. This means that there is no more
race between tabbed mapping the window and GTK+ selecting
StructureNotifyMask.

Note that the proper fix would be to do as XEmbed requires: Create the
window elsewhere and then reparent it into the target window. However,
that would require a more invasive patch, so this commit only takes the
"easy approach" of fixing this one race. Hopefully, all the other races
that can occur during window setup are harmless, because the
embedder/socket will hopefully watch for PropertyNotify events as
needed.

Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/757
See-also: https://github.com/awesomeWM/awesome/issues/2385
Signed-off-by: Uli Schlachter <psychon@znc.in>
2018-10-14 14:01:25 +02:00
Benjamin Otte
0a37b564d4 x11: Add necessary NULL check
(Backported from master 3438dcdd4e)
2018-06-20 20:02:01 +02:00
Benjamin Otte
01d1bc3c75 x11: Always set None pixmap for no background
None means no background, so it's always the correct thing to use and
ParentRelative is always wrong.

Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1134
2018-06-19 16:43:56 +02:00
Samuel Thibault
f23bfc6b69 gdk: activate surface on keyboard grabs
In 01455399e8 ("gdk: do not deactivate surface on keyboard grabs"), we
made gdk avoid deactivating surfaces when another application takes a
keyboard grab, by using has_focus_window instead of has_focus. That however
broke activating surfaces when the gdk application acquired a grab itself,
in which case has_focus_window is false but has_focus is true.

We thus actually need to use both: surfaces should be activated either
because we have normal keyboard focus, or because we grabbed the keyboard.

This also renames HAS_FOCUS to APPEARS_FOCUSED to better reflect its
role.

Fixes #85

(cherry picked from commit 3287ac96e02ff236d74db10164c5b0c1e7b2b0bf)
2018-06-18 10:32:02 +02:00
Matthias Clasen
a73fa04e92 x11: Don't set NET_WM_PID when sandboxed
It is not useful, and some window managers misinterpret it and
add some "runs as root" indication to the window decoration.

See https://github.com/mate-desktop/marco/issues/301
2018-05-29 20:31:32 -04:00
Benjamin Otte
2ce63a86ba x11: Set a transparent background on windows by default
This avoids black flicker on compositing WMs when a window is first shown.
2018-05-04 13:46:46 +02:00
Samuel Thibault
c926b28d96 gdk: do not deactivate surface on keyboard grabs
When pressing e.g. a window manager shortcut, which acquires keyboard grab,
Xorg would send FocusOut NotifyGrab then FocusIn NotifyUngrab.  Currently
gdk would then deactivate the current surface, which makes accessibility
screen readers think that we have switched to a non-accessible application
and came back again, and thus reannounce the application frame etc. which we
don't want when e.g. just raising volume.

And actually, receiving FocusOut NotifyGrab does not mean losing the
X focus, it only means an application aqcuired a grab, i.e. it is
temporarily stealing keyboard events. On Wayland, this isn't even
notified actually.

This commit makes gdk only deactivate surfaces when there was an actual
focus switch to another window, as determined by has_focus_window (instead
of just has_focus), which happens either normally through FocusOut with
NotifyNormal, or during grabs through FocusOut with NotifyWhileGrabbed.

Fixes #85

(cherry picked from commit 01455399e8)
2018-04-30 11:17:34 +02:00
Emmanuele Bassi
07124b5e99 x11: Query whether we have GLX support
Epoxy 1.4 has new ad hoc API that we can use to check whether GLX is
available on the current system.

If we didn't use this API, we'd have to manually dlopen libGL (or its
equivalent on different OSes) and check if it had GLX symbols; since
Epoxy already does all of this internally, we can simply ask it instead.

https://bugzilla.gnome.org/show_bug.cgi?id=775279
(cherry picked from commit 02eb344950)
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2018-04-23 09:13:41 +01:00
Sébastien Villemot
59136773b8 gdk_x11_display_get_monitor: fix monitor number test logic
When asked for a nonexistent (positive) monitor number,
gdk_x11_display_get_monitor would (at best) return an uninitialized pointer,
instead of returning NULL.

https://gitlab.gnome.org/GNOME/gtk/merge_requests/107
2018-04-09 18:27:44 +01:00
Pavel Roskin
cc967849f7 x11: Avoid a division by zero
This is similar to f44baf51d9 but for RandR 1.3 servers like
x11rdp and Windows Exceed which don't return a refresh rate. Avoid a
crash when that happens.

https://bugzilla.gnome.org/show_bug.cgi?id=775546
2018-03-08 16:00:40 +01:00
Benjamin Otte
4b1c02560f x11: Don't call XInput API for core events
Fixes emacs crashing with XMing.

https://bugzilla.redhat.com/show_bug.cgi?id=1483942
2018-02-12 21:11:58 +01:00
Emmanuele Bassi
d219bd4d5a x11: Balance an error trap
We are pushing an error trap, and never popping it from the stack.
2018-02-11 23:28:50 +00:00
Matthias Clasen
7de01b31ef Remove a dead macro
GCs have been dead for a long time.
2018-01-07 16:38:42 +00:00
Matthias Clasen
e834a2b089 x11: Avoid crash in fallback move emulation
Quietly do nothing when there is already an ongoing operation.
This matches the behavior of the ewmh code, and is much nicer
than a crash.

https://bugzilla.gnome.org/show_bug.cgi?id=789054
2017-12-15 16:17:27 -05:00
Matthias Clasen
74720117c9 Revert "gdkscreen-x11: Enable RandR on VirtualBox"
This reverts commit f2ba6ca473.

This change was causing problems with several X servers,
see https://bugzilla.gnome.org/show_bug.cgi?id=780101
2017-10-28 10:29:12 -04:00
Simon McVittie
465ef50554 Set GDK_WINDOW_STATE_TILED if any edge is tiled
This state flag is used in several places in GTK+, for example to
ignore RESIZE_INC hints if tiled. Setting it is also necessary for
backwards compatibility with applications that changed their behaviour
when tiled, such as GNOME Terminal and its MATE fork.

Signed-off-by: Simon McVittie <smcv@debian.org>

https://bugzilla.gnome.org/show_bug.cgi?id=789357
2017-10-27 10:58:35 -02:00
Georges Basile Stavracas Neto
73155e3988 display-x11: Unset tiled state if _GTK_EDGE_CONSTRAINTS is supported
Commit c415bef5de introduced support for the new _GTK_EDGE_CONSTRAINTS
atom. If the compositor supports that atom, however, we were always
setting the tiled state, even if no actual tiling information is
available, where the correct action is to completely remove any traces
of the tiled state.

Fix that by correctly removing the tiled state when compositor supports
_GTK_EDGE_CONSTRAINTS Xatom.

https://bugzilla.gnome.org/show_bug.cgi?id=788516
2017-10-04 15:33:15 -03:00