Function "handle_raise_or_lower (src/core/keybindings.c)" is called
when running 'raise-or-lower' on a window. This function iterates
through all the windows in the stack to determine if our window is
already on top or obscured. The problem is that the window stack
includes windows in another workspaces and also windows that are
minimized.
https://bugzilla.gnome.org/show_bug.cgi?id=705200
Different libEGL will do different things for eglGetDisplay since it has
to guess what kind of display it's been handed. Better to just use the
API that makes it explicit.
Signed-off-by: Adam Jackson <ajax@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772422
The initial state of the hardware cursor is not known, so always force
update it the first time we update the cursor. Do this by changing the
'force' flag of update_hw_cursor() to an 'invalidated' hw cursor state.
https://bugzilla.gnome.org/show_bug.cgi?id=771056
Clutter assumed seat0 which is most usually, but not always correct.
Add an evdev-backend specific function to allow passing the seat
that will be used for ClutterDeviceManager construction, which we
already obtain in MetaLauncher.
https://bugzilla.gnome.org/show_bug.cgi?id=778092
If the meta_window_actor_effect_completed() triggers inconsistent
accounting, there's also high chances that the thaw call will be
unexpected at this time too, which will lead to a g_error().
This makes mutter more lenient to effect_completed() calls of the
right type (i.e. those triggering freeze/thaw) being performed more
times than necessary in the upper parts. A warning will be issued,
but the process won't abort.
https://bugzilla.gnome.org/show_bug.cgi?id=777691
Since both the libinput event source and the key repeat timer have the
same priority, the order in which both handlers are called is
arbitrary if both sources are ready on the same poll return. This
means that sometimes we generate key repeats when there's already a
real key event queued on libinput that would cancel the repeat timer
if only it was processed before.
One solution would be lowering the repeat timer source priority a
notch lower than the libinput source but that would mean that a steady
stream of events from libinput (e.g. pointer device motion) would
prevent any key repeats to happen.
Instead, we can fix this problem by trying to dispatch libinput from
the key repeat timer and checking if the timer source has been
destroyed before generating more key repeats.
https://bugzilla.gnome.org/show_bug.cgi?id=774989
Commit 9214d5029c changed the notify*
API to use microseconds and we already have a microsecond time source
here so we can use the timestamp directly without losing resolution at
this layer.
https://bugzilla.gnome.org/show_bug.cgi?id=774989
Make sure that each logical monitor owns the expected actual monitors.
This currently needs special care when dealing with laptop lid the
configuration, as the MetaMonitorConfigManager path still deosn't
handle restoring the previous configuration, meaning the logical
monitor with the external monitor will continue being primary.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This is partly redundant given that the current monitor mode is checked
against the CRTC mode, but this also checks the disabled CRTCs. Later
the configured mode position and transform will be checked.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Check that the crtc mode has the correct intra-monitor position. In
effect, this tests that the CRTCs in a tiled monitor are configured with
the correct mode on the correct position.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The MetaOutput::is_primary state was not correctly managed in two cases:
* for tiled monitors, the primary state got overridden when setting
the preferred resolution
* for laptop lid, it was not set if the laptop panel happened to be
the first output
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The main output of the main (first) monitor of a primary logical
monitor should have the MetaOutput::is_primary field set; all other
outputs should have it not set.
All outputs associated with a logical monitor with presentation set
should have MetaOutput::is_presentation set. No other outputs should
have it set.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add a flag to the test setup creation function enabling the caller to
specify whether a stored config should be used. This is done by
changing the value of the hotplug_mode_update MetaOutput field,
normally used by VMs to do the same.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Both the monitor unit tests and monitor store unit tests will want to
check whether the config manager is used and set custom configuration
files.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
MetaMonitorConfigStore provides an XML storage mechanism for
MetaMonitorConfigManager. It stores configuration files defined in the
same level as the MetaMonitorsConfig format, i.e. refers to high level
"monitors" and "monitor modes" instead of connectors and CRTCs.
Only reading custom files are implemented and so far unused.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Don't let a dummy option context consume the arguments; just let the
GLib test suite do it. It'll handle the basic command line arguments
and allow doing things such as specifying what test to run.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This tests only the monitor configuration and basic functionality. It
does not test anything related to window management and Wayland client
interaction.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Handle headless setup gracefully by having no logical monitors. This
commit only makes the monitor management code deal with it; other areas
may still not be able to handle it.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Use the g_assert_cmp(int|uint|...) macros when comparing integers and
unsigned integers. This means that the mismatched numbers are printed
in the test report.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add a meta_monitors_config_new() helper. It's exposed outside of
meta-monitor-config-manager.c already, as it'll be used externally in a
later commit.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add a test case that checks that configuration works when the lid is
initialy closed then later opened. This test case is disabled when the
legacy configuration is used as it does not handle that situation.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Handle configuring when the laptop lid is closed. This is so far
handled by creating a linear configuration while ignoring the laptop
panel. Changing the current configuration will come later.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Move the UpClients notify::lid-is-closed signal handling into
MetaMonitorManager, and put the getter behind a vfunc. This means
Placing it behind a vfunc allows custom backends to implement it
differently; for example the test backend can mock the state.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Adds an API to get the position suggested by the backend. This
translates to position advertised by some VM:s, used to hint at a
position making the position more natural (i.e. placed similarly to how
it may be placed on the host desktop).
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The new monitor configuration system (MetaMonitorConfigManager) aims to
replace the current MetaMonitorConfig. The main difference between the
two is that MetaMonitorConfigManager works with higher level input
(MetaMonitor, MetaMonitorMode) instead of directly looking at the CRTC
and connector state. It still produces CRTC and connector configuration
later applied by the respective backends.
Other difference the new system aims to introduce is that the
configuration system doesn't manipulate the monitor manager state; that
responsibility is left for the monitor manager to handle (it only
manages configuration and creates CRTC/connector assignments, it
doesn't apply anything).
The new configuration system allows backends to not rely on deriving the
current configuration from the CRTC/connector state, as this may no longer be
possible (i.e. when using KMS and multiple framebuffers).
The MetaMonitorConfigManager system is so far disabled by default, as
it does not yet have all the features of the old system, but eventually
it will replace MetaMonitorConfig which will at that point be removed.
This will make it possible to remove old hacks introduced due to
limitations in the old system.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Operate on MetaMonitor's instead of MetaOutput's, as the latter may be
only a subset of an actual "monitor" when referring to the physical
computer equipment.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
