Add a new object, MetaMonitorConfig, that takes care of converting
between the logical configurations stored in monitors.xml and
the HW resources exposed by MonitorManager.
This commit includes loading and saving of configurations, but
still missing is the actual CRTC assignments and a default
configuration when none is found in the file.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Read the current transform from XRandR, and expose the transforms
that are really supported on the bus.
The dummy backend now advertises all transforms, since it doesn't
actually apply them.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Instead of a full white background, make one with a random color.
This way the different "monitors" are visible and it's easier
to debug the DBus API.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Add a number of dummy outputs and modes to the dummy backend,
and implement the writing bits.
The only visible effect is that you can change the screen size,
which resizes the output window.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Now MonitorManager does its own handling of XRandR events, which
means we no longer handle ConfigureNotify on the root window.
MetaScreen reacts to MonitorManager::monitor-changed and updates
its internal state, including the new size.
This paves the way for doing display configuration using only
the dummy backend, which would allow testing wl_output interfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Implement ApplyConfiguration in terms of XRandR calls.
Error checking is done before actually committing the configuration.
If mutter is using one of the other monitor config backends, an
error is reported and nothing happens.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Turns out that even if two outputs say that they can be controlled
by a given CRTC, you can't configure them in the same CRTC unless
they are marked as "possible clones" one of the other.
This can further restrict the configuration options, so we need
to expose this limitation in the DBus API.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
This new interface will be used by the control center and possibly
the settings daemon to configure the screens. It is designed to
resemble a simplified XRandR, while still exposing all the quirks
of the hardware, so that the panel can limit the user choices
appropriately.
To do so, MetaMonitorMode needs to track CRTCs, outputs and modes,
so the low level objects have been decoupled from the high-level
MetaMonitorInfo, which is used by core and API and offers a simplified
view of HW, that hides away the details of what is cloned and how.
This is still not efficient as it should be, because on every
HW change we drop all data structures and rebuild them from scratch
(which is not expensive because there aren't many of them, but
at least in the XRandR path it involves a few sync X calls)
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Consolidate all places that deal with output configuration in
MetaScreen, which gets it either from XRandR or from a dummy static configuration.
We still need to read the Xinerama config, even when running xwayland,
because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but
now we do it only when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
We need to use g_signal_connect_object(), rather than g_signal_connect(),
because the window actor can be destroyed before the window emits
the final notify::appears-focused inside unmanage, if the plugin
decides that it doesn't want to animate the destruction (which
happens with dialogs and the default plugin)
https://bugzilla.gnome.org/show_bug.cgi?id=706207
GNOME Shell's actors aren't touch capable, so we need to make sure that
they get the fallback pointer emulated events for now. This fixes the top
bar and other elements not working on a touchscreen without a grab.
https://bugzilla.gnome.org/show_bug.cgi?id=697192
Some cards have 2k texture limits, which can be smaller than
commonly sized backgrounds.
One way to get around this problem is to use Cogl's "sliced texture"
feature, that transparently uses several hardware textures under the hood.
This commit changes background textures loaded from file to potentially
use slicing. Based on a patch by Jasper St. Pierre
<jstpierre@mecheye.net>.
https://bugzilla.gnome.org/show_bug.cgi?id=702283
Some cards have 2k texture limits, which can be smaller than
commonly sized backgrounds.
This commit downscales the background in this situation, so that
it won't fail to load.
https://bugzilla.gnome.org/show_bug.cgi?id=702283
Originally attached dialogs did not have a titlebar, which the code
still assumes though it hasn't been true for a while; nowadays, the
actual look of attached dialogs is controlled by the theme.
As GTK+ recently gained the ability to set custom titlebars, we need
to support attached dialogs with either full borders (WM decorations)
or border-only (GTK+ titlebar).
Just remove the left-over assumption to make it work as expected.
https://bugzilla.gnome.org/show_bug.cgi?id=702764
We need to update window->monitor on override_redirect windows as well, other
wise they may end up with an invalid struct which triggers and assert when
meta_window_is_monitor_sized is called.
https://bugzilla.gnome.org/show_bug.cgi?id=702564
Avoid a round trip to the xserver we already have the current position
anyway. Querying from the server on every move can cause the compositor to
stall during movement.
Add new api (meta_screen_get_current_monitor_for_pos and
meta_screen_get_current_monitor_info_for_pos) that allow querying the monitor
without a roundtrip by reusing the passed in cursor position.
gnome-shell needs to know whether the stage window is focused so
it can synchronize between stage window focus and Clutter key actor
focus. Track all X windows, even those without MetaWindows, when
tracking the focus window, and add a compositor-level API to determine
when the stage is focused.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
When we set the input focus, we first set the predicted window,
and then try to process focus events. But as XI_FocusOut on the
existing window comes before XI_FocusIn on the new window, we'll
see the focus out on the old window and think the focus is going
to nothing, which makes mutter think the prediction failed.
This didn't really matter as nothing paid attention to the focus
window changing, but with gnome-shell's focus rework, we'll try
and drop keyboard focus in events like these.
Fix this by making sure that we ignore focus window changes of our
own cause when updating the focus window field, by ignoring all
focus events that have a serial the same as the focus request or
lower. Note that if mutter doens't make any requests after the
focus request, this could be racy, as another client could steal
the focus, but mutter would ignore it as the serial was the same.
Bump the serial by making a dummy ChangeProperty request to a
mutter-controlled window in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=701017
We substract one from the unredirect counter when enable_unredirect_for_screen
gets called. It is an unsigned integer so substracting one from zero (which means enable) would overflow and thus keep it peramently enabled.
This should never happen because it means there is an unmatched
enable / disable pair somewhere. So in addition to fixing it add a
warning when this case gets triggered.
https://bugzilla.gnome.org/show_bug.cgi?id=701224
