All pads will share the same focus than the keyboard, so this means that:
- The focus changes in-sync for keyboard and all pad devices, and
- Newly plugged pads will be immediately focused on that same surface
This object represents the collection of buttons, strips and rings
in a tablet pad. All the objects created (pad, strips and rings)
share a common focus surface and have the same lifetime.
This is now separated from the generic cursor one. This means that wl_surfaces
can't be shared across wl_pointer and wp_tablet_tool. This is a change in
tablet protocol v2.
This is a simple subclass of MetaWaylandSurfaceRoleCursor, mostly
so we can distinguish by GType, the methods in the parent class
still apply and are useful.
When launching a GNOME session from a text-mode VT, the logind session
type is unlikely to be set to either "wayland" or "x11". We search for a
supported session type first with logind and then with
$XDG_SESSION_TYPE. As a fallback, we also test $DISPLAY in case of a
"tty" logind session to support starting through xinit. Ideally, such
setups should set XDG_SESSION_TYPE=x11.
If no supported session type is found, we throw an error.
https://bugzilla.gnome.org/show_bug.cgi?id=759388
They are already effectively interchangeable so this should reduce
pointless casts.
Just like in GDK though, we need to keep the old definition for
instrospection to be able to include the struct's fields.
By creating a pending gbm/EGL surface pair, only setting it on
swap-buffers, we would draw onto a buffer on the old surface, then swap
the buffer from the new surface, causing the first frame after a
hot-plug always having no content.
This was in the past not very noticable since some non-deterministic but
frequent side effect in gnome-shell caused hot-plugging to always render
two new frames, but after "Introduce regional stage rendering", this
side effect did not occur as often, thus making it more visible.
This commit updates the current gbm/EGL surface pair before painting a
frame, so that when the frame is painted, the surface with the correct
size is used and the buffer from correct surface is swapped.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Being a listener to a signal, it is inconvenient to enforce order of
execution between different signal listeners. If there are things in
the backend that should be updated before various other signal
handlers, make sure so is done by emitting the signal after having
explicitly notified the backend.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
CoglFrameInfo is a frame info container associated with a single
onscreen framebuffer. The clutter stage will eventually support drawing
a stage frame with multiple onscreen framebuffers, thus needs its own
frame info container.
This patch introduces a new stage signal 'presented' and a accompaning
ClutterFrameInfo and adapts the stage windows and past onscreen frame
callbacks users to use the signal and new info container.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Call a CoglContext "cogl_context", CoglDisplay "cogl_display" and
CoglRenderer "cogl_renderer" so that they won't be confused with
ClutterContext, MetaDisplay and MetaRenderer etc.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Make the cogl vfunc functions have names that are globally
discoverable. Calling the same function in every backend the same name
causes code navigation tools to not function properly. Rename the
affected functions to closer correspond to the style mutter uses.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
We were compensating for a clone paint viewport offset even when we
were not in clone paniting mode. This would break painting if we offset
the viewport for some other reason for example as in the future stage
view painting.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Instead of assuming there is a single onscreen framebuffer, use the
helper functions for setting the frame callback and getting the frame
counter.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
In preperation for having allowing drawing onto multiple onscreen
framebuffers, move the onscreen framebuffer handling to the
corresponding winsys dependent backends.
Currently the onscreen framebuffer is still accessed, but, as can seen
by the usage of "legacy" in the accessor name, it should be considered
the legacy method. Eventually only the X11 Compositing Manager backend
will make use of the legacy single onscreen framebuffer API.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Split the stage window implementations into three separate objects: one
for X11 as a compositing manager, one for X11 running as a nested
Wayland compositor, and one for running with the native backend.
The new stage window implementations are only thin shells; this is in
preparation for making the stage windows behave more differently.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
The stage resizing was placed in the generic backend, which was only
run on certain configurations (when running nested or using the native
backend). This commits makes the resizing more explicit thus more
obvious.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
This commit completes the move of monitor logic to the monitor
mangager. The renderer now only deals with framebuffers, asking the
monitor manager to do the crtc flip tracking.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Let MetaMonitorManagerKms manage KMS modes. This lets us pass less
state to MetaRendererNative. Instead let MetaMonitorManager tell the
monitor manager when it should set the mode and with what framebuffer.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Absorb the CoglRendererKMS struct into MetaRendererNative. The gbm
device initialization is moved earlier so that the renderer fails to
initialize if the gbm device creation failed.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Move the KMS interaction from cogl into mutter, where most of the other
KMS interaction already takes place. This also removes dead code which
were only excercised when non-mutter callers used the cogl KMS backend.
The cogl KMS API was updated to pass via MetaRendererNative instead of
via the different cogl objects.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Instead of passing around the KMS file descriptor via clutter to cogl,
just make our own clutter backend create the cogl renderer and set the
KSM fd.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
MetaRenderer is meant to be the object responsible for rendering the
scene graph. It will contain the logic related to the cogl winsys
backend, the clutter backend, and the clutter stage window.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Make it possible to force mutter to start as a X11 compositing/window
manager. This is needed when intending to start mutter as an X11 window
manager while running inside a Wayland session, for example when
intending to debug it in Xephyr.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Use the correct pointer types for cogl objects. This avoids warnings
when including the cogl headers doesn't result in all the cogl types
being typedefs to void.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Introduce two new clutter backends: MetaClutterBackendX11 and
MetaClutterBackendNative. They are so far only wrap ClutterBackendX11
and ClutterBackendEglNative respectively, but the aim is to move things
from the original clutter backends when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Using clutter API to transform coordinates is only accurate right
after a clutter layout pass but this function is used e.g. to deliver
pointer motion events which can happen at any time. This isn't a
problem for wayland clients since they don't control their position,
but X clients do and we'd be sending outdated coordinates if a client
is moving a window in response to motion events.
https://bugzilla.gnome.org/show_bug.cgi?id=768039
This layer isn't really being used and in fact, it causes
meta_stack_get_default_focus_window() to return a fullscreen window
even if the naturally topmost window in the stack isn't a fullscreen
one.
Note that commit a3bf9b01aa changed how
we choose the default focus window from the MRU to the topmost in the
stack.
https://bugzilla.gnome.org/show_bug.cgi?id=768221
When restarting (X compositor only, obviously), we want to keep
the same window focused. There is code that tries to do this by
calling XGetInputFocus() but the previously focused window will
almost certainly not still be focused by the time we get to the
point where we call XGetInputFocus(), and in fact, probably was
no longer correct after the previous window manager exited, so
the net result is that we tend to focus no window on restart.
A better approach is to leave the _NET_ACTIVE_WINDOW property
set on the root window during exit, and if we find it set when
starting, use that to initialize focus.
https://bugzilla.gnome.org/show_bug.cgi?id=766243
Emit a signal so that interested parties can recreate their FBOs and
queue a full scene graph redraw to ensure we don't end up showing
graphical artifacts.
This relies on the GL driver supporting the
NV_robustness_video_memory_purge extension and cogl creating a
suitable GL context. For now we only make use of it with the X backend
since the only driver with which this is useful is NVIDIA.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
The call fetching the targets mistakenly used the timestamp meant
to back up the TIMESTAMP atom (hence, it's the timestamp at which
the selection is *owned* by the compositor, on behalf of a wayland
client).
This timestamp is actually only updated when the compositor gets
to own the selection, so it's a randomly late timestamp to retrieve
the TARGETS atom content, which certain clients might end up
ignoring.
https://bugzilla.gnome.org/show_bug.cgi?id=768007
Frames are painted on the frame window according to the GTK+ theme.
Depending on the target's visual, this means either drawing over
a black destination or a fully transparent one. So in cases where
the theme doesn't paint decorations with full opacity, decorations
for windows with an rgba visual look different from those with a
non-rgba visual. Using an rgba visual for all frames independent
from the client's visual can potentially break clients, so our
only option for a consistent appearance is to explicitly initialize
the frame background to black before painting the theme's decoration
on top.
https://bugzilla.gnome.org/show_bug.cgi?id=745060
The GTK+ theme may draw parts of the decorations outside the actual
frame. Since commit f9db65f47f we make sure that the frame is big
enough to account for any overdrawing, however as we still clip the
cairo context to the actual frame before drawing the decorations,
those parts aren't actually painted.
This issue is not very obvious for most frames, as they use a non-rgba
visual where the unpainted parts appear black, which gives the expected
result with many themes once the shape mask is applied (as the mask does
include any overdrawn parts). For frames using an rgba visual however,
unpainted parts are transparent, so any overdrawn decorations are clearly
missing.
Fix this by only clipping out the client area when drawing decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=745060
We ignore all damage while a surface is frozen and queue a full
update instead once it's thawed. While not super efficient, this
isn't overly bad for the intended case of catching up with any
updates that happened during a compositor effect. However when
extended frame sync is used, surfaces are also frozen while the
client is drawing a frame, in which case the current behavior is
pretty damaging (pun intended), as we end up redrawing the entire
window each frame. To address this, keep track of the actual damage
we ignore and apply it when the surface is thawed.
https://bugzilla.gnome.org/show_bug.cgi?id=767798
The result flag needs to be marked as moved even for pending moves,
otherwise the window's unconstrained_rect doesn't get updated in
meta_window_move_resize_internal() and the anchor grab is wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=764180
The X11 backend uses EWMH's _NET_WM_PID to get the PID of an offending
client and kill its PID to force the client to terminate.
The Wayland backend is using a Wayland protocol error, but if the client
is hung, that will not be sufficient to kill the client.
Retrieve the client PID under Wayland using the Wayland client API
wl_client_get_credentials() and kill() the client the same way the X11
backend does.
https://bugzilla.gnome.org/show_bug.cgi?id=767464
xdg-shell allows desktop environments to extend the list of states
within a given range.
Use this possibility to add a new state for tiled so that gtk+ can
benefit from this.
https://bugzilla.gnome.org/show_bug.cgi?id=766860
gjs throws exceptions on non UTF-8 strings which, in some cases, crash
gnome-shell. ICCCM string properties are defined to be Latin-1 encoded
so we can try to convert them to avoid it.
Note that _NET_WM_NAME is defined to be UTF-8 and we already validate
it in utf8_string_from_results() .
https://bugzilla.gnome.org/show_bug.cgi?id=752788
printf string precision counts bytes so we may end up creating invalid
UTF-8 strings here. Instead, use glib's unicode aware methods to clip
the title.
https://bugzilla.gnome.org/show_bug.cgi?id=765535
This makes us behave the same both on bind and when an output
changes. In particular, we were not sending scale and done events on
output changes. We were also unconditionally sending mode events on
output changes even though these should only be sent if there is an
actual mode change.
https://bugzilla.gnome.org/show_bug.cgi?id=766528
Stacking hidden X windows below the guard window is a necessity to
ensure input events aren't delivered to them. Wayland windows don't
need this because the decision to send them input events is done by us
looking at the clutter scene graph.
But, since we don't stack hidden wayland windows along with their X
siblings we lose their relative stack positions while hidden. As
there's no ill side effect to re-stacking hidden wayland windows below
the X guard window we can fix this by just doing it regardless of
window type.
https://bugzilla.gnome.org/show_bug.cgi?id=764844
If we try to send notify event (either from surface_state_changed()
or from meta_window_wayland_move_resize_internal()),
we will crash, because we don't have a sufrace anymore.
There's no reason why to resize the window that is being
unmanaged anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=751847
meta_parse_accelerator() considers 0 length accelerator strings as
valid, meaning that the keybinding should be disabled. Unfortunately,
it doesn't initialize the MetaKeyCombo so if the caller doesn't
initialize it either, we end up using random values and possibly
grabbing random keys.
https://bugzilla.gnome.org/show_bug.cgi?id=766270
All the upper layers are prepared for multiple onscreen cursors, but
this. All MetaCursorRenderers created would poke the same internal
MetaOverlay in the stage.
This will lead to multiple cursor renderers resorting to the "SW"
rendering paths (as it can be seen with tablet support) to reuse the
same overlay, thus leading to flickering when a different
MetaCursorRenderer takes over the overlay.
Fix this by allowing per-cursor-renderer overlays, their lifetime
is attached to the cursor renderer, so is expected to be tear down
if the relevant device (eg. tablet) disappears.
meta_wayland_tablet_manager_update()/handle_event() are called before
the MetaWaylandSeat counterparts. If the event comes from a device
managed by MetaWaylandTabletManager, the event will be exclusively handled
by it.
Each tool has its own MetaCursorRenderer instance, which is created/destroyed
upon proximity, and possibly updated through focus and set_cursor calls in
between.
This struct keeps the server side information for the wl_tablet_manager
global resource. It keeps the clients requesting this interface, and
does keep track of the plugged tablet devices, so
wl_tablet_manager.device_added is emitted on the expected clients.
