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
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
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
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
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.
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
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.
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
Some monitors return a bunch of bytes on their display descriptor
which aren't valid utf8 and thus we fail to serialize them later on
for the DisplayConfig DBus API.
Let's fall back to the stringified product code and serial number in
that case.
https://bugzilla.gnome.org/show_bug.cgi?id=752673
There's a chance the icon will be animated, so store the XcursorImages
instead of the individual XcursorImage, and handle that as a nimages=1
special case.
API to "tick" a cursor animation, and retrieve current frame timing
information has been added.
https://bugzilla.gnome.org/show_bug.cgi?id=752342
Tracking back from the monitor to the output every time we need to
figure out the scale of a window on a monitor is inconvenient, so
propagate the scale from the output to the monitor it is associated
with.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
Enable a user to test and debug multi output configurations on Wayland
without having the available hardware by enabling some basic
configuration of the dummy monitor manager.
Currently available configuration options are:
MUTTER_DEBUG_NUM_DUMMY_MONITORS - to set the number of monitors
MUTTER_DEBUG_DUMMY_MONITOR_SCALES - to configure the monitor scales
See src/backends/meta-monitor-manager-dummy.c for detailed description
of the available configuration parameters.
https://bugzilla.gnome.org/show_bug.cgi?id=747089
Before submitting a new scroll mode, click method or sendevents mode check if
the value is supported by the device. This avoids BadValue errors when setting
two-finger scrolling on single-finger touchpad devices since we can't easily
handle BadValue (see 9747277b)
https://bugzilla.gnome.org/show_bug.cgi?id=750816
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We should not be setting random output properties like this.
Use the function we just introduced to only set the underscan flag when
it's actually supported.
So that clients such as the control center can decide to hide an
underscanning checkbutton when the output does not support it.
Support in the KMS / native backend to come later...
It seems that fglrx sometimes gives us absolute junk when requesting the
outputs, and if we don't trap errors, we'll just crash when trying to
configure a junk output. Use xcb so errors simply get ignored.
For enter / leave events, which we use in the UI code, we need to make
sure that these coordinates are root-relative as well, otherwise the
cursor when entering frames might be incorrect.
If we're running as a nested compositor, we must not attempt to
passive grab on the root window, and we should be setting the
touch event mask on the stage window.
https://bugzilla.gnome.org/show_bug.cgi?id=751036
This way, we won't be hit with BadValue errors if we set it to a value
outside the X device's range. This can happen for touchpads without
two-finger scrolling, for instance.
Instead of selecting the first drm mode as the preferred mode, select the
first drm mode marked as preferred. If there are no modes marked as
preferred, revert to the old behaviour and select the first mode.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
https://bugzilla.gnome.org/show_bug.cgi?id=750363
Read the drm layout properties suggested_X, suggested_Y and
hotplug_mode_update and transfer them to the meta layer.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
https://bugzilla.gnome.org/show_bug.cgi?id=750363
The monitors info structure is created from the tiled outputs
and this is used as the central storage for info about a monitor
as opposed to the output state.
It appears at least the EDID mm w/h is for the whole monitor and
not per tile.
this just adds backend support for retrieving the tile
information from X11 (randr 1.5) and native backends.
It stores the tiling information into the output struct.
