This applies 'egl/x11: calloc dri2_surf so it's properly zeroed' to
mesa-19.0.7, as it fixes a crash introduced by 'egl/dri: flesh out and
use dri2_create_drawable()' included in 19.0.6.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/648
Instead of either figuring out themself, or looking at the commit that
added the file, just make life easier by providing the commands for
rebuilding and pushing as a comment in the Dockerfile itself.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/648
We used to have wayland-specific paths for this in src/wayland, now we
have ClutterKeymap that we can rely on in order to do state tracking,
and can do this all on src/backend domain.
This accomodates the feature in common code, so will work on both
Wayland and X11.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/590
The currently used package links are outdated. Instead of updating them
to the current release number, rely on copr repos having a higher priority
than system repos and simply specify the package name.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/644
When requesting to a take-focus window to acquire the input, the client may or
may not respond with a SetInputFocus (this doesn't happen for no-input gtk
windows in fact [to be fixed there too]), in such case we were unsetting the
focus while waiting the reply.
In case the client won't respond, we wait for a small delay (set to 250 ms) for
the take-focus window to grab the input focus before setting it to the default
window.
Added a test for this behavior and for the case in which a window takes the
focus meanwhile we're waiting to focus the default window.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/307
This allows to sleep for a given timeout in milliseconds.
Rename test_case_before_redraw to test_case_loop_quit since it's a generic
function and use it for the timeout too.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/307
This allows to verify which window should have the focus, which might not
be the same as the top of the stack.
It's possible to assert the case where there's no focused window using
"NONE" as parameter.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/307
Allow to set/unset WM_TAKE_FOCUS from client window.
This is added by default by gtk, but this might not happen in other toolkits,
so add an ability to (un)set this.
So fetch the protocols with XGetWMProtocols and unset the atom.
test-client now needs to depend on Xlib directly in meson build.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/307
When destroying a window that has a parent, we initially try to focus one of
its ancestors. However if no ancestor can be focused, then we should instead
focus the default focus window instead of trying to request focus for a window
that can't get focus anyways.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/308
On FreeBSD, gethostname is guarded by '__POSIX_VISIBLE >= 200112', which
requires either '_POSIX_C_SOURCE >= 200112' or '_XOPEN_SOURCE >= 600'.
Defining _XOPEN_SOURCE to 500 does not break the build because of
implicit declaration, but it defeats the purpose of defining the macro.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/638
We get a signed integer (-1 meaning "no workspace specified"), store it in
an unsigned integer, check for >= 0 (of course it is!) and set as the window
workspace (signed integer, -1 meaning "show on all workspaces"). What could
possibly go wrong?
https://gitlab.gnome.org/GNOME/mutter/merge_requests/639
This commit introduces, and makes use of, a transactional API used for
setting up KMS state, later to be applied, potentially atomically. From
an API point of view, so is always the case, but in the current
implementation, it still uses legacy drmMode* API to apply the state
non-atomically.
The API consists of various buliding blocks:
* MetaKmsUpdate - a set of configuration changes, the higher level
handle for handing over configuration to the impl backend. It's used to
set mode, assign framebuffers to planes, queue page flips and set
connector properties.
* MetaKmsPlaneAssignment - the assignment of a framebuffer to a plane.
Currently used to map a framebuffer to the primary plane of a CRTC. In
the legacy KMS implementation, the plane assignment is used to derive
the framebuffer used for mode setting and page flipping.
This also means various high level changes:
State, excluding configuring the cursor plane and creating/destroying
DRM framebuffer handles, are applied in the end of a clutter frame, in
one go. From an API point of view, this is done atomically, but as
mentioned, only the non-atomic implementation exists so far.
From MetaRendererNative's point of view, a page flip now initially
always succeeds; the handling of EBUSY errors are done asynchronously in
the MetaKmsImpl backend (still by retrying at refresh rate, but
postponing flip callbacks instead of manipulating the frame clock).
Handling of falling back to mode setting instead of page flipping is
notified after the fact by a more precise page flip feedback API.
EGLStream based page flipping relies on the impl backend not being
atomic, as the page flipping is done in the EGLStream backend (e.g.
nvidia driver). It uses a 'custom' page flip queueing method, keeping
the EGLStream logic inside meta-renderer-native.c.
Page flip handling is moved to meta-kms-impl-device.c from
meta-gpu-kms.c. It goes via an extra idle callback before reaching
meta-renderer-native.c to make sure callbacks are invoked outside of the
impl context.
While dummy power save page flipping is kept in meta-renderer-native.c, the
EBUSY handling is moved to meta-kms-impl-simple.c. Instead of freezing the
frame clock, actual page flip callbacks are postponed until all EBUSY retries
have either succeeded or failed due to some other error than EBUSY. This
effectively inhibits new frames to be drawn, meaning we won't stall waiting on
the file descriptor for pending page flips.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
The MetaKmsImpl implementation may need to add a GSource that should be
invoked in the right context; e.g. a idle callback, timeout etc. It
cannot just add it itself, since it's the responsibility of MetaKms to
determine what is the impl context and what is the main context, so add
API to MetaKms to ensure the callback is invoked correctly.
It's the responsibility of the caller to eventually remove and destroy
the GSource.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
As with CRTC state, variable connector state is now fetched via the
MetaKmsConnector. The existance of a connector state is equivalent of
the connector being connected. MetaOutputKms is changed to fetch
variable connector state via MetaKmsConnector intsead of KMS directly.
The drmModeConnector is still used for constructing the MetaOutputKms to
find properties used for applying configuration.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
Move reading state into a struct for MetaCrtcKms to use instead of
querying KMS itself. The state is fetched in the impl context, but
consists of only simple data types, so is made accessible publicly. As
of this, MetaCrtcKms construction does not involve any manual KMS
interaction outside of the MetaKms abstraction.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
Represents drmModeConnector; both connected and disconnected. Currently
only provides non-changing meta data. MetaOutputKms is changed to use
MetaKmsConnector to get basic metadata, but variable metadata, those
changing depending on what is connected (e.g. physical dimension, EDID,
etc), are still manually retrieved by MetaOutputKms.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
A plane is one of three possible: primary, overlay and cursor. Each
plane can have various properties, such as possible rotations, formats
etc. Each plane can also be used with a set of CRTCs.
A primary plane is the "backdrop" of a CRTC, i.e. the primary output for
the composited frame that covers the whole CRTC. In general, mutter
composites to a stage view frame onto a framebuffer that is then put on
the primary plane.
An overlay plane is a rectangular area that can be displayed on top of
the primary plane. Eventually it will be used to place non-fullscreen
surfaces, potentially avoiding stage redraws.
A cursor plane is a plane placed on top of all the other planes, usually
used to put the mouse cursor sprite.
Initially, we only fetch the rotation properties, and we so far
blacklist all rotations except ones that ends up with the same
dimensions as with no rotations. This is because non-180° rotations
doesn't work yet due to incorrect buffer modifiers. To make it possible
to use non-180° rotations, changes necessary include among other things
finding compatible modifiers using atomic modesetting. Until then,
simply blacklist the ones we know doesn't work.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
