Make the choosing and identity of the primary GPU an internal detail to
the native renderer. MonitorManagerKms did not need it for anything.
The primary GPU logic remains unchanged.
This allows follow-up patches to change how the renderer chooses the
primary GPU. It will be easier for the renderer to use private
information for choosing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
This is a step towards moving the primary GPU logic into the native
renderer exclusively. In the future the renderer will have one more
criterion on choosing the primary GPU than MetaMonitorManagerKms should
know about: does a GPU offer hardware rendering.
The choosing of primary GPU is separated from the discovery of GPUs.
When GPUs are discovered and added to the list, the MetaGpuKmsFlag is
now populated correctly and used in choosing.
Choosing the primary GPU is done after all GPUs have been found and is
slightly different from before:
- Skipping devices that do not belong to our seat now works instead of
becoming the primary GPU.
- Fall back to any non-platform, non-boot_vga device if neither kind is
found.
The old preference of platform over boot_vga device is kept.
The hotplug path will continue creating a gpu_kms without flags, because
at that point the primary GPU has already been chosen and the flags are
irrelevant.
Co-authored by: Pekka Paalanen <pekka.paalanen@collabora.com>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
Add a flags field to MetaGpuKms. In following commits, the flags defined
here will be set and used for choosing the primary GPU.
Co-authored by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
Keycode lookup can fail for serveral reasons, e.g. if there is no combination of
modifiers and keycodes that can produce the target keysym with the current
keyboard layout.
In case the keycode lookup fails, remap temporarily the keysym to an unused
keycodes.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/109
I saw Meson fade from the sky
On the wind I heard a sigh
As snowflakes cover fallen Makefiles
I will say this last goodbye
Meson is now coming
So ends Autotools days
Future is now coming
And we must away
Over Python and without Bashisms
Through lands where never Meson touched
By silver streams that run down to the Sea
Under parsers, beneath old legacy
Over snow one winter’s morn
I turned at last to paths that lead home
And though where the road then takes me
I cannot tell
We came all this way
But now comes the day
To bid you farewell
Many places I have been
Many sorrows I have seen
But I don’t regret
Nor will I forget
All Makefiles that took that road with me
I bid you all a very fond farewell.
If a library is provided in the positional arguments, then meson
defaults to installing the .pc file in a 'pkgconfig' subdirectory
in the library's install location. We want the files in the regular
$libdir/pkgconfig rather than $libdir/mutter-$api/pkgconfig, so
specify the location explicitly in the parameters.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/382
This is a simple libcanberra abstraction object, so we are able
to play file/theme sounds without poking into GTK+/X11. Play
requests are delegated to a separate thread, so we don't block
UI on cards that are slow to wake up from power saving.
Dependencies are added automatically, and we no longer get warnings
like:
clutter/clutter/meson.build:628: DEPRECATION: Library mutter-clutter-4
was passed to the "libraries" keyword argument of a previous call to
generate() method instead of first positional argument. Adding
mutter-clutter-4 to "Requires" field, but this is a deprecated behaviour
that will change in a future version of Meson. Please report the issue
if this warning cannot be avoided in your case.
The texture tower can return no texture e.g. if the calculated level is
negative. This was handled before, but regressed with
e1370ee209. This fixes a potential crash
observed occasionally when starting Firefox nightly using the Wayland
backend in overview mode.
If a KMS device has the DRM_CAP_DUMB_PREFER_SHADOW and a software based
GL driver is used, always use a shadow fb. This will speed up read backs
in the llvmpipe OpenGL implementation, making blend operations faster.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/106
Now that everything is settled, from the initialization
process to the subclasses to moving code to the compositor,
MetaWindowActor can be a proper abstract class that cannot
be instantiated.
Thus, make MetaWindowActor an abstract class.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
This vfunc was added as a was to work around the convoluted
initialization process. Now that we figured it out and moved
the MetaWindowActor-specific initialization to constructed(),
we can override that.
Remove post_init() and use GObject.constructed() entirely.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
MetaWindowActor breaks layering isolation by accessing
and injecting itself into compositor->windows. This is
a bad practice, and effecticely makes returning the
new actor useless, since we doesn't even use the return
value.
Move window actor creation to under MetaCompositor and
stop violating (too badly) the resposabilities of each
component. This moves meta_window_actor_new() into
meta_compositor_add_window().
Also, move the remaining initialization code to the
GObject.constructed vfunc.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
Document the roles of MetaSurfaceActor and MetaWindowActor,
and when their subclasses are used.
(And this is actually the first real documentation under
src/compositor/README!)
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
MetaWindowActor handles sending _NET_WM_FRAME_* X atoms to
clients - even pure Wayland clients.
Now that we have Wayland- and X11-specific implementations of
MetaWindowActor, we can delegate this to MetaWindowActorX11,
and allow pure Wayland apps to not even connect to
MetaSurfaceActor:repaint-scheduled.
Do that by moving all the X11-specific code to the X11-specific
MetaWindowActorX11 class. Add vfuncs to MetaWindowActorClass
that are necessary for the move, namely:
* pre_paint() and post_paint()
* post_init()
* frame_complete()
* set_surface_actor()
* queue_frame_drawn()
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
Those are stub specialized classes for MetaWindowActor. This will
help ensuring that we do not execute X11-specific code paths on
pure Wayland clients.
The relationship between the window actor and the surface is the
following:
* Wayland: MetaWindowActorWayland + MetaSurfaceActorWayland
* X11: MetaWindowActorX11 + MetaSurfaceActorX11
* Xwayland: MetaWindowActorX11 + MetaSurfaceActorWayland
It is not possible to have MetaWindowActorWayland backed by a
MetaSurfaceActorX11 surface.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
We will introduce specialized MetaWindowActors for X11
and Wayland in the future, so it needs to be derivable.
Make it a derivable class, and introduce a private field.
The MetaWindowActorClass definition is in the private
header in order to prevent external consumers of Mutter
to create MetaWindowActor implementations of their own.
That is, MetaWindowActor is only internally derivable.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
EGLStream textures are imported as GL_TEXTURE_EXTERNAL_OES and reading
pixels directly from them is not supported. To make it possible to get
pixels, create an offscreen framebuffer and paint the actor to it, then
read pixels from the framebuffer instead of the texture directly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/362
When a texture is transformed in any way (e.g. Wayland buffer
transforms), we cannot just fetch the pixels from the texture directly
and be done with it, as that will result in getting the untransformed
pixels.
To properly get the pixels in their right form, first draw to an
offscreen framebuffer, using the same method as when painting on the
stage, then read from the framebuffer into a cairo image surface.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/362
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/408
