The xdg_output interface has a `name` property that reflects the output
name coming from the compositor.
This is the closest thing we can get to a connector name.
Fixes: #1961
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.
The “xdg-output” protocol provides clients with the outputs size and
position in compositor coordinates, and does not provide the output
scale which is already provided by the core “wl_output” protocol.
So when receiving the wl_output scale event, we should update the scale
regardless of “xdg-output” support, otherwise the scale will remain to
its default value of 1 and the surface will be scaled up by the
compositor to match the actual output scale, which causes blurry fonts
and widgets.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1901
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
And update the surface accordingly (eg. scale on hidpi). The mechanism
that did that for wl_pointer has been made generic so it can be shared
with tablets too.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1675
_gdk_wayland_cursor_get_buffer was not initializing
its out variables in the 'not found' case. This
was showing up in protocol traces as garbage hotspots
being sent to the compositor.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1328
Previously, the GDK backend for Wayland would deduce the logical size
of the monitors from the wl_output size and scale.
With the addition of fractional scaling which advertises a larger scale
value and then scale down the client surface, the computed logical size
of the monitors in GDK would be wrong and confuse applications which
insist on using the monitor size and position (like Firefox).
The xdg-output protocol aims at describing outputs in a way which is more
in line with the concept of an output on desktop oriented systems by
presenting the outputs using their logical size and position appropriately
transformed.
Add support for the optional xdg-output protocol so that the size and
position of the monitors as reported by GDK is correct even when using
fractional scaling.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1828
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
The event received in `gdk_wayland_window_show_window_menu()` can
come from widgets with a GdkWindow. In those cases the coordinates
are relative to the widget, not the root window.
This results in a misplaced window menu.
Properly calculate the coordinates by iterating to the toplevel
window as suggested by Carlos Garnacho.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/684
The use of the startup ID is now twofold, we reply back with it to end any
corresponding startup notification, but we also use it on
gtk_surface1.request_focus to acknowledge that the activation might raise
the corresponding window.
We should preserve the startup ID for the second to work properly, so avoid
clearing it here. It is inconsequential if the underlying
gtk_shell1.set_startup_id request happens multiple times on no longer existing
startup IDs, so don't bother preventing that from happening.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1754
And notify the shell about it. This is done through the
gtk_shell1.notify_launch request added in gtk-shell v3. All the plumbing
on the way to the activated application is already in place to transfer
the startup ID, so the other side just has to reply with
gtk_surface1.request_focus.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/624
This uses the gtk_surface1.request_focus request added in gtk-shell v3,
the given startup ID may be used by the compositor in order to determine
when was the request started, and whether user input happened in between.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/624
This version has 2 new requests:
- gtk_shell1.notify_launch notifies the compositor that the requesting
client shall launch another application. The given ID is expected to
be unique.
- gtk_surface1.request_focus notifies the compositor that a surface
requests focus due to it being activated. The given ID is passed to
this process through undetermined means, if it corresponds with a
current startup ID and there was no user interaction in between the
surface will be focused, otherwise it will demand attention.
If the size was constrained by the xdg_positioner mechanisms, we handle
the resize by resizing the popup window. What we shouldn't do is
hide/show the popup window so avoid that.
The cache key is just the name of the cursor, so if a previously added
cursor had e.g. scale == 1, if we ask for a new cursor with scale == 2,
we might still fetch the scale == 1 cursor from the cache. Avoid this by
making sure the scale of the cached one is correct.
If it isn't, load the cursor as normal, and update the cache entry with
the new properly scaled cursor.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1183
Under Wayland, we are currently directly using GSettings
for desktop settings. But in a sandbox, we may not have
access to dconf, so this may fail. Use the new settings
portal instead.
Suggested by Garnacho. Hopefully fixes#1349.
Note: I'm riskily committing this via web UI not because I'm lazy
(though I am :) but because I'm seeing a weird host key when I try to
push or pull from GitLab.
Let's just use the fact that a window was mapped as a subsurface to
remap it above another transient parent instead of relying on the more
complicated 'should-map-as-subsurface' helper function.
The enum is duplicated in the spec for the manager and the decoration
object. We should be using the right ones. In practice they have the
same value, so this bug didn't cause any issues.
The wl_surface is destroyed and recreated when the window is
mapped/unmapped. As we have a new wl_surface we need to create a new
server_decoration object for that surface.
According to the spec compositors were to assume surfaces are CSD until
told otherwise. This means we need to send
org_kde_kwin_server_decoration_request_mode in both cases.
This fixes libreoffice under kwin, which would remove it's own headers
as per the manager's request but not inform kwin leaving it in the even
more broken state of having none.
Cursor surfaces didn't listen for output scale changes, meaning they
didn't adapt their scale when an output changed scale, which could
happen for example when changing the monitor scale via Settings.
This functionality is similar to Linux's memfd. It creates anonymous shared memory without touching the filesystem, which allows it to work in Capsicum capability mode (sandbox).
The 'gtk-fontconfig-timestamp' and 'gtk-modules' settings are
currently not available at all on Wayland. On X11, they are
implemented through xsettings maintained up-to-date by
gnome-settings-daemon.
This patch implements both GtkSettings for Wayland using a
new dbus interface also provided by gnome-settings-daemon.
Closes#886
gdk_wayland_*_grab()/ungrab() would emit crossing events which translate
as focus_in/focus_out events for keyboard.
However, the ungrab() functions compare the native toplevel as this is
what gets the Wayland pointer enter/leave events with the grab window,
so if the grab is issued on a child gdk window, those won't match and we
would emit more focus_out events than focus_in events.
This means that a widget such as spice-gtk which issues a keyboard grab
whenever the pointer enters the window and releases the grab when it
leaves the window would get uneven numbers of focus_in/focus_out events.
Also, gdk_wayland_seat_ungrab() would not emit crossing events for
keyboard devices, whereas gdk_wayland_device_ungrab() does, which adds
even more potential discrepancies between focus_in/focus_out events.
To solve this problem, introduce two new helper functions which check
the relevant native windows to emit crossing events when needed that get
called evenly from both gdk_wayland_seat_grab()/ungrab() and gdk_Wayland
_device_grab()/ungrab() APIs.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=780422
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/792
When an animated cursor was set and the previous cursor animation delay
happened to be the same, we wouldn't restart the animation timeout and
just return G_SOURCE_CONTINUE assuming the timer would continue. This
assumption is however only valid if the function was called from the
timeout, which is not the case.
Instead also arm the timer also if there is no previous timer active.
The header linux/input.h used by GDK is specific to Linux. It is
possible to get a few Linux headers on FreeBSD by installing v4l_compat,
but it is usually better to use the one shipped with FreeBSD.
We prefer dev/evdev/input.h to linux/input.h here, so it will always use
dev/evdev/input.h on FreeBSD regardless of v4l_compat.
https://svnweb.freebsd.org/changeset/ports/465644
The shortcuts inhibitors hash table is created when we create a
GdkWaylandWindow implementation for a GdkWindow, and it's destroyed once
we finalize the instance. The fake "root" window we create for the
Wayland display does not have a backing native window, so the shortcuts
inhibitors hash table is set to NULL; this causes a critical error
message when calling g_hash_table_destroy() on it. The finalization of
the root window happens when we close a display connection.
We should use g_clear_pointer(), instead, as it's NULL safe.
Without this change, the displayclose test fails, as all warnings are
considered fatal.
The stable xdg_shell port (5c8bb51a) introduced an error in
gdk_wayland_window_set_geometry_hints which would set the minimum size
to the maximum size, if provided.
This resulted in various wxWidgets apps (FileZilla, Audacity, Veracrypt)
crashing because they attempted to allocate a ginormous surface.
Fixes#157.
If a window is unmapped by the client while gdk is processing updates,
(for example Firefox un-mapping its window on Expose events), the
windowing backend resources might be lost (for example with Wayland)
which can cause a crash in end_paint().
Make sure we drop the cairo surfaces as well when hiding the surface,
that will avoid the crash in gdk_window_impl_wayland_end_paint() when
trying to attach the staging cairo surface to a released wl_surface,
these will be recreated when needed when the surface becomes visible
again and there is no need to keep such buffers around for a surface
which is not visible anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=793062
