GitLab

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.

GNOME/mutter!307

This will only wait for events to be dispatched and processed by the server
without waiting for client processing.

Reuse the code for the wait command too.

GNOME/mutter!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.

GNOME/mutter!307

Ensure that we have a focused window when closing transient windows with
no-focus or no-take-focus atoms

GNOME/mutter!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.

GNOME/mutter!307

When a window with no frame, that doesn't accept focus and that has no
take-focus atom set is destroyed, we ended up in not changing the current_focus
window, causing a crash.

Added test cases that verify this situation.

Related to GNOME/mutter#308
GNOME/mutter!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.

GNOME/mutter!307

Under the hood, calls gtk_window_set_accept_focus in the client

GNOME/mutter!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 GNOME/mutter#308

There is no gethostname call in this file.

GNOME/mutter!638

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.

GNOME/mutter!638

Since the xauth file is never going to be changed after it is generated,
it is safe to use g_get_host_name here.

GNOME/mutter!626
GNOME/mutter!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?

GNOME/mutter!639

GNOME/mutter!636

CoglError was added at a certain point to remove the hard dependency on
GLib, but since this can't be avoided inside mutter, let's remove this
whole abstraction.

GNOME/mutter!631

This makes sure that we won't accidentally change KMS transaction
updates after they have been posted.

GNOME/mutter!525

Using the g_debug() macro. Set G_DEBUG_MESSAGES to "mutter" to activate
log.

GNOME/mutter#548
GNOME/mutter!525

Document the high level components of the KMS abstraction.

GNOME/mutter#548
GNOME/mutter!525

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.

#548
!525

While not currently used by any users, it'll be useful in future
commits.

GNOME/mutter#548
GNOME/mutter!525

They are not strictly related to any of the KMS objects, and should be
reusable without adding a dependency on the non-meta-kms-* files in
meta-kms-*.

#548
!525

To let the MetaKmsImpl implementation register file descriptor GSource
where the invoke function is ensured to be executed in the impl context.

GNOME/mutter#548
GNOME/mutter!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.

GNOME/mutter#548
GNOME/mutter!525

While the current impl context is in the same thread as the main
context, the separation still exists, and to post callbacks from the
impl context, it must pass MetaKms to make sure the callback is invoked
in the right context.

GNOME/mutter#548
GNOME/mutter!525

GNOME/mutter#548
GNOME/mutter!525

Instead of manually retrieving supported transforms and formats from the
primary plane of the CRTC, use the MetaKmsPlane abstraction to find the
primary plane of the CRTC and check compatibility using the
MetaKmsPlane API. This removes the last user of direct KMS API usage
except for applying configuration.

GNOME/mutter#548
GNOME/mutter!525

Instead of iterating over the available drmModeConnector objects to
construct a GPU wide mode list, use the state managed by
MetaKmsConnector. This also removes the last user of drmModeRes from
MetaGpuKms.

GNOME/mutter#548
GNOME/mutter!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.

GNOME/mutter#548
GNOME/mutter!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.

GNOME/mutter#548
GNOME/mutter!525

GNOME/mutter#548
GNOME/mutter!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.

GNOME/mutter#548
GNOME/mutter!525

It's a uint32_t, not a long.

GNOME/mutter#548
GNOME/mutter!525

It was only used within one function, where it was always created, but
still was kept around indefinitely for no reason. Lets get rid of it
from the MetaOutputKms struct.

GNOME/mutter#548
GNOME/mutter!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.

GNOME/mutter#548
GNOME/mutter!525

Add MetaKmsCrtc to represent a CRTC on the associated device. Change
MetaCrtcKms to use the ones discovered by the KMS abstraction. It still
reads the resources handed over by MetaGpuKms, but eventually it will
use only MetaKmsCrtc.

MetaKmsCrtc is a type of object that is usable both from an impl task
and from outside. All the API exposed via the non-private header is
expected to be accessible from outside of the meta-kms namespace.

GNOME/mutter#548
GNOME/mutter!525

The intention with KMS abstraction is to hide away accessing the drm
functions behind an API that allows us to have different kind of KMS
implementations, including legacy non-atomic and atomic. The intention
is also that the code interacting with the drm device should be able to
be run in a different thread than the main thread. This means that we
need to make sure that all drm*() API usage must only occur from within
tasks that eventually can be run in the dedicated thread.

The idea here is that MetaKms provides a outward facing API other places
of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is
an internal implementation that only gets interacted with via "tasks"
posted via the MetaKms object. These tasks will in the future
potentially be run on the dedicated KMS thread. Initially, we don't
create any new threads.

Likewise, MetaKmsDevice is a outward facing representation of a KMS
device, while MetaKmsImplDevice is the corresponding implementation,
which only runs from within the MetaKmsImpl tasks.

This commit only moves opening and closing the device to this new API,
while leaking the fd outside of the impl enclosure, effectively making
the isolation for drm*() calls pointless. This, however, is necessary to
allow gradual porting of drm interaction, and eventually the file
descriptor in MetaGpuKms will be removed. For now, it's harmless, since
everything still run in the main thread.

#548
!525

It was unused.

GNOME/mutter#548
GNOME/mutter!525

Lets work towards making MetaMonitorManager about managing monitors, and
not about managing GPUs. This changes other units to keep a pointer to
the backend instead of a monitor manager, in case their ownership
changed, or their main usage of the monitor manager was to look up GPUs.

GNOME/mutter#548
GNOME/mutter!525

Instead of dealing with udev details here, use the newly added 'hotplug'
event emitted from MetaUdev.

GNOME/mutter#548
GNOME/mutter!525