This commits refactors cursor handling code and plugs in logic so that
cursor sprites changes appearance as it moves across the screen.
Renderers are adapted to handle the necessary functionality.
The logic for changing the cursor sprite appearance is done outside of
MetaCursorSprite, and actually where depends on what type of cursor it
is. In mutter we now have two types of cursors that may have their
appearance changed:
- Themed cursors (aka root cursors)
- wl_surface cursors
Themed cursors are created by MetaScreen and when created, when
applicable(*), it will extend the cursor via connecting to a signal
which is emitted everytime the cursor is moved. The signal handler will
calculate the expected scale given the monitor it is on and reload the
theme in a correct size when needed.
wl_surface cursors are created when a wl_surface is assigned the
"cursor" role, i.e. when a client calls wl_pointer.set_cursor. A
cursor role object is created which is connected to the cursor object
by the position signal, and will set a correct texture scale given what
monitor the cursor is on and what scale the wl_surface's active buffer
is in. It will also push new buffers to the same to the cursor object
when new ones are committed to the surface.
This commit also makes texture loading lazy, since the renderer doesn't
calculate a rectangle when the cursor position changes.
The native backend is refactored to be triple-buffered; see the comment
in meta-cursor-renderer-native.c for further explanations.
* when we are running as a Wayland compositor
https://bugzilla.gnome.org/show_bug.cgi?id=744932
Use a specialized cursor renderer when running as a nested Wayand
compositor. This new renderer sets an empty X11 cursor and draws the
cursor as part of the stage using the generic cursor renderer drawing
path.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
Make a surface roles into objects with vfuncs for things where there
before was a big switch statement. The declaration and definition
boilerplate is hidden behind C macros.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
If a surface doesn't have a role, the compositor will not know how, if
or when it will be painted. By adding it to the compositor frame
callback list, the compositor will respond to the client that the
surface has been drawn already which might not be true.
Instead, queue the frame callback in a list that is then processed when
the surface gets a role assigned. The compositor may then, given the
role the surface got, queue the frame callback accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
Being a "XWayland window" should be considered equivalent to a role,
even though it is not part of any protocol anywhere. The commit doesn't
have any functional difference, but just makes it clear that an
wl_surface managed by XWayland have the same type of special casing as
surface roles as defined by the Wayland protocol.
As the semantics are more explicit given the role is defined, a comment
explaining why the semantics need to be how they are was added.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
If a queued event is being processed after the surface is
destroyed, trying to access the window associated with the surface
will lead to a segmentation fault.
This patch avoids the crash by first checking if the surface is not null.
https://bugzilla.gnome.org/show_bug.cgi?id=754715
This fixes build error caused by commit 614d6bd. We can simply remove
the usage of meta-wayland.c functions in non-wayland build because
META_BACKEND_X11_MODE_NESTED is only used in wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=753948
Use a better name, use GNOME conventions for error handling, open code the
client error reporting and send the error to the correct resource.
wl_subcompositor doesn't have a role error yet, so continue use some
other error. The only effect of this is error received in the client will
be a bit confusing, it will still be disconnected.
https://bugzilla.gnome.org/show_bug.cgi?id=754215
Older GCC only allows "for (int i" in explicit c99 mode - there's probably
no reason that we can't enable that, but avoiding the construct for
a fast fix.
If the user Alt-Tabs out of the window, we will be left thinking
the Alt key is still pressed since we don't see a release for it.
Solve this and other related issues for the nested X11 compositor
by selecting for KeymapStateMask which causes a KeymapNotify event
to be sent after each FocusIn, and when we get these events, update
the internal XKB state and send any necessary modifiers events to
clients.
https://bugzilla.gnome.org/show_bug.cgi?id=753948
Some backgrounds don't fully fill the screen. For those backgrounds
it's important to paint a color behind them to fill in the gaps.
This commit checks whether or not the background image textures take
up the entire monitor, and in the event they don't, draws a color
behind them (such as it would do if the background were
translucent).
https://bugzilla.gnome.org/show_bug.cgi?id=754476
meta_background_get_texture only draws the bottom image texture
if
1) the blend factor leaves the top image translucent
or
2) the top image is translucent from alpha
The latter case doesn't actually matter since we're using REPLACE
on the top image texture.
This commit drops the unnecessary check for the second case and
applies demorgans law to the conditional for clarity.
https://bugzilla.gnome.org/show_bug.cgi?id=754476
There were lots of code handling the native renderer specific cases;
move these parts to the renderer. Note that this causes the X11 case to
always generate the texture which is a waste of memory, but his
regression will be fixed in a following commit.
The lazy loading of the texture was removed because it was eventually
always loaded anyway indirectly by the renderer to calculate the
current rect.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
There is nothing special about the private API which only consists of
getters for renderer specific backing buffer. Lets them to the regular
.h file and treat them as part of the normal API.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
When a client binds an incompatible version, we should terminate it.
This check should only be there for the unstable version, as once it is
declared stable and renamed, future versions will be backward compatible.
https://bugzilla.gnome.org/show_bug.cgi?id=753855
Before, it used to be in the screen, but now,
meta_cursor_reference_from_theme can never fail. Move it to where we
load the images from the cursor name.
meta_wayland_pointer_get_client_pointer() may be called when the
MetaWaylandPointer as been already shut down, so the hash table will be
NULL at that moment.
Since mutter has two X connections and does damage handling on the
frontend while fence triggering is done on the backend, we have a race
between XDamageSubtract() and XSyncFenceTrigger() causing missed
redraws in the GL_EXT_X11_sync_object path.
If the fence trigger gets processed first by the server, any client
drawing that happens between that and the damage subtract being
processed and is completely contained in the last damage event box
that mutter got, won't be included in the current frame nor will it
cause a new damage event.
A simple fix for this would be XSync()ing on the frontend connection
after doing all the damage subtracts but that would add a round trip
on every frame again which defeats the asynchronous design of X
fences.
Instead, if we move fence handling to the frontend we automatically
get the right ordering between damage subtracts and fence triggers.
https://bugzilla.gnome.org/show_bug.cgi?id=728464
The global wl_pointer_gestures object is now created, effectively
bridging pinch/swipe gestures with clients, so they're now
accessible to clients implementing the protocol.
Instead of moving around all the bound pointer resources for a client
when changing focus, keep all the resources bound by a client in a per
client struct, and track the focus by having a pointer to the current
active pointer client struct instance.
This will simplify having wl_pointer extensinos sharing the pointer
focus of the wl_pointer by only having to add them to the pointer
client.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
While we shouldn't normally receive crossing events for any windows
except the stage when running nested, we do in case we hold a pointer
grab - just ignore those events instead of taking down the user's
session.
The spec says:
"A server should avoid signalling the frame callbacks if the surface is not
visible in any way, e.g. the surface is off-screen, or completely obscured
by other opaque surfaces."
We actually do have the information to do that but we are always calling
the frame callbacks in after_stage_paint. So fix that to only call when
when the surface gets drawn on screen.
https://bugzilla.gnome.org/show_bug.cgi?id=739163
The compositor maintains a ring of shared fences with the X server in order to
properly synchronize rendering between the X server and the compositor's GPU
channel. When all of the fences have been used, the compositor needs to reset
one so that it can be reused. It does this by first waiting on the CPU for the
fence to become triggered, and then sending a request to the X server to reset
the fence.
If the compositor's GPU channel is busy processing other work (e.g. the desktop
switcher animation), then the X server may process the reset request before the
GPU has consumed the fence. This causes the GPU channel to hang.
Fix the problem by having the compositor's GPU channel trigger its own fence
after waiting for the X server's fence. Wait for that fence on the CPU before
sending the reset request to the X server. This ensures that the GPU has
consumed the X11 fence before the server resets it.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=728464
If GL advertises this extension we'll use it to synchronize X with GL
rendering instead of relying on the XSync() behavior with open source
drivers.
Some driver bugs were uncovered while working on this so if we have
had to reboot the ring a few times, something is probably wrong and
we're likely to just make things worse by continuing to try. Let's
err on the side of caution, disable ourselves and fallback to the
XSync() path in the compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=728464
