The functions meta_window_x11_create_sync_request_alarm() and
meta_window_x11_destroy_sync_request_alarm() are not used outside
MetaWindowX11 now, and don't need to be exposed in window-x11.h
Remove them from window-x11.h and shuffle these functions to
before their first usage, to avoid having to add their prototypes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/372
Only the X11 backend cares about trapping X11 errors when
warping pointers, and there is no reason for it to be done
by MetaWindow.
Move the push()/pop() calls to MetaBackendX11, and simplify
warp_grab_pointer() by removing the boolean return value
that is not being used anywhere.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/372
meta_window_has_pointer() is already aware of X11 or Wayland
specific implementations, but it makes more sense to have it
implemented by the subclasses themselves.
Move the Wayland and X11 code paths to their respective subclasses
through a new vfunc MetaWindowClass.has_pointer().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/372
As of now, the base class MetaWindow is calling into X11
API when mapping and unmapping a window. Even on purely
Wayland clients.
Fix that by moving those calls to MetaWindow subclasses.
On MetaWindowX11, it calls into X11 APIs, and the Wayland
implementation is stub.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/372
The code to react to _NET_WM_SYNC_REQUEST and family (counter,
alarm, etc) currently lives in MetaWindow, even though most of
its management is done by MetaWindowX11.
In an ideal Wayland-as-default world, MetaWindow is completely
agnostic to the display server implementation, delegating to
MetaWindowX11 and MetaWindowWayland their respective display
server internals.
To help this goal, move the X11-specific code to deal with
_NET_WM_SYNC_REQUEST to MetaWindowX11.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/372
This means we need to make sure we don't accidentally free the provided
source GError (which automatically happens with `g_autoptr`), so use
`g_steal_pointer()`.
This fixes an issue where, when launched in a bubblewrap environment
(such as the one provided by Buildstream), mutter would give the
following warning message:
```
mutter-WARNING **: 8:31:35:069: Can't initialize KMS backend: (null)
```
... which isn't that useful when trying to debug the actual issue.
Iterate over all the monitor product words to check for a partial matching on
EDID, otherwise we would hang inside an infinite while loop.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/459
This adds the required bits to wayland surfaces and ties them up
to the compositor parts.
It is based on and very similar in nature to buffer transforms.
From the specification:
> The global interface exposing surface cropping and scaling
> capabilities is used to instantiate an interface extension for a
> wl_surface object. This extended interface will then allow cropping
> and scaling the surface contents, effectively disconnecting the
> direct relationship between the buffer and the surface size.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/323
This implements the viewporter protocol which offers a cropping and scaling
capabilities to wayland clients.
There are several use cases for this, for example video players and games,
both as a convenience function and as potential performance optimization when
paired with hardware overlays etc.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/323
Until meson 0.50, setting the install parameter in 'configure_file' is ignored
if 'install_dir' is set. Then until mutter doesn't depend on such meson version
cogl_installed_tests_libexecdir should be empty unless have_installed_tests is
false, or this file will be installed anyway.
See https://github.com/mesonbuild/meson/issues/4160
For various error and warning messages, mutter includes a description of
the window, and that description includes a snippet of the title of the
window. Those snippets find their way into system logs, which then means
they can potentially find their way into bug reports and similar. Remove
the window title information to eliminate this potential privacy issue.
Unfortunately, many parts of GNOME Shell and Mutter and Clutter
still use the implicit Cogl1 API. As such, it as a transition
between the old and new APIs, it is important to keep the
implicit draw framebuffer updated.
ClutterRootNode does not keep it updated though, and it might
lead to problems when rendering offscreen textures.
Fix that by pushing and popping the root node framebuffer on
pre- and post-draw, respectively.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
The ClutterRootNode paint node is theoretically the
top-most node of a paint nodes tree, except that we
are not in the point of having full rendering trees
in Clutter (all rendering performed by paint nodes
is still local and immediate).
When controlling the rendering tree, MetaShapedTexture
may need to paint into an offscreen framebuffer under
some circumstations.
Expose ClutterRootNode so that MetaShapedTexture can
use it to render to offscreen framebuffers.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
When painting to an offscreen framebuffer, MetaShapedTexture will
need to have full control of the painting routines of paint nodes.
As such, expose clutter_paint_node_paint() to allow forcing a
paint nodes paint from MetaShapedTexture.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
The multitexture API is not a shortcut for multiple calls
to the single texture API. It is meant to wrap calls to
cogl_framebuffer_draw_multitexture_rectangle(), which
uses the passed texture coordinates at different layers of
the pipeline.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
ClutterImage is a ClutterContent implementation that
has an internally managed CoglTexture. This texture
is recreated when new image data is set.
ClutterContent implementations may have control over
the allocation of the widgets they're attached to,
through CLUTTER_REQUEST_CONTENT_SIZE. On those cases,
if the new image data differs in size from the previous
data, it is important to notify those actors about the
size change. However, currently ClutterImage does not
notify them.
With the introduction of clutter_content_invalidate_size(),
it is possible to report the size changes to attached
actors.
Adapt ClutterImage to invalidate_size() when image data
has different sizes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
ClutterContent has the ability to dictate the layout of any
given actor, through the CLUTTER_REQUEST_CONTENT_SIZE request
mode.
However, there is no way for ClutterContent implementations
to notify their attached actors that the content size changed.
Add a new optional ClutterContent.invalidate_size() vfunc and
clutter_content_invalidate_size().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
