If the user maps eg. Alt+F2 to a pad button, the MetaInputSettings will
send the full Alt press, F2 press, F2 release, Alt release sequence.
However the keycode corresponding to Alt is found in level 1, so the
Shift modifier gets unintendedly latched in addition to the Alt key
press/release pair.
We could probably improve keycode lookup heuristics so level=0 (and
no modifier latching) is preferred, but we can do without it altogether
for modifier keys.
Right now we try to apply the current monitor config when a new
monitor is attached. The current config obviously doesn't include the
new monitor, so the new monitor isn't lit up.
The only reason we apply the current config at all is to handle the
startup case: We want to reuse the config set in Xorg when first
logging in.
This commit changes the code to look at the *initial config* instead
of the current config, and only if the new monitor topology matches
the start up topology.
Track the stereo status of windows using the new EXT_stereo_tree
GLX extension.
When stereo is enabled or disabled, a restart is triggered via
meta_restart() after a timeout, setting a _META_ENABLE_STEREO
property on the root window to indicate whether we should
turn on a stereo stage for clutter. The property avoids a loop,
since we need to enable stereo *before* initializing Clutter and GL,
but we need GL to figure out whether we have stereo windows.
Stereo windows are drawn to the stage using new functionality
in Cogl to setup a stereo context, select which buffer to draw
to, and draw either the left or right buffer of a stereo
texture_from_pixmap.
Unfortunately XKeysymToKeycode() falls short in that it coalesces keysyms
into keycodes pertaining to the first level (i.e. lowercase). Add a
ClutterKeymapX11 method (much alike its GdkKeymap counterpart) to look up
all matches for the given keysym.
Two other helper methods have been added so the virtual device can fetch
the current keyboard group, and latch modifiers for key emission. Combining
all this, the virtual device is now able to handle keycodes in further
levels.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/135
(cherry picked from commit 85284acb00)
OpenJDK wrongly assumes that shaping a window implies no shadows.
They got lucky until commit b975676c changed the fallback case,
but now their compliance tests are broken. Make them happy again
by special-casing shaped Java windows.
In case of no existing configuration, we use a default layout of
aligning attached displays horizontally. This sidesteps any layout
configuration that is done externally, for instance via xorg.conf,
which is not desirable. Instead, base the initial configuration on
the existing layout if it passes some sanity checks before falling
back to the default linear config.
The stack below us isn't as reliable as we'd like and in some cases
doesn't generate RRScreenChangeNotify events when e.g. resuming a
laptop on a dock, meaning that we'd miss newly attached outputs.
Xvnc turns its outputs off/on on every mode set which makes us believe
there was an hotplug when there actually wasn't. Work around this by
requiring new randr configuration timestamps to be ahead of the last
set timestamp by at least 100 ms for us to consider them an actual
hotplug.
Commit 8d3e05305 ("window: Force update monitor on hot plugs") added the
flag `META_WINDOW_UPDATE_MONITOR_FLAGS_FORCE` passed to
`update_monitor()` from `update_for_monitors_changed()`.
However, `update_for_monitors_changed()` may choose to call another code
path to `move_between_rects()` and `meta_window_move_resize_internal()`
eventually.
As `meta_window_move_resize_internal()` does not use the "force" flag,
we may still end up in case where the window->monitor is left unchanged.
To avoid that problem, add a new `MetaMoveResizeFlags` that
`update_for_monitors_changed()` can use to force the monitor update from
`meta_window_move_resize_internal()`.
Fixes: 8d3e05305 ("window: Force update monitor on hot plugs")
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/189
The kernel forces a VT switch during suspend on some hardware,
and not on others.
We run code from the VT switch handler that we need to also get
run on resume.
This commit makes sure we explicitly run the VT switch handler
during suspend and resume.
The proprietary nvidia driver garbles GPU memory on suspend.
In order to workaround that limitation, this commit copies all
textures to host memory on suspend and restores them on resume.
One complication comes from external textures (such as those
given to us by Xwayland for X clients). We can't just restore
those textures, since they aren't writable.
This commit addresses that complication by keeping a local texture
around for those external textures, and using it instead for parts
of the window that haven't been redrawn since resume.
As mentioned in a previous commit, the proprietary NVIDIA
driver garbles memory on suspend. That behavior, means that
the cursor gets corrupted on suspend.
This commit forces the cursor to redraw itself when the
logind session becomes active (on VT switch and resume).
As mentioned in a previous commit, the proprietary NVIDIA
driver garbles memory on suspend. That behavior, means that
clutter's glyph cache (which is stored in GPU memory) gets
corrupted on suspend.
This commit ensures the glyph cache is blown away when
the logind session becomes active (on VT switch and resume).
The proprietary NVIDIA driver garbles memory on suspend. In order
to work around that limitation, mutter needs to refresh all its
textures on resuem.
This commit lays the way toward doing that by emitting the
"gl-video-memory-purged" signal when the compositor becomes active
by logind (which happens on VT switch and on resume).
On nvidia, the textures backing Xwayland client window contents get
corrupted on suspend. Xwayland currently doesn't handle this situation
itself.
For now, in order to work around this issue, send an empty output
change event to Xwayland. This will cause it to force Expose events
to get sent to all clients and get them to redraw.
This commit adds "suspending" and "resuming" signals
to MetaBackend.
It's preliminary work needed for tracking when to purge
and recreate all textures (needed by nvidia).
Right now we listen to prepare-for-sleep using
raw gdbus calls.
This commit switches it over to use a generated
proxy, which will become useful in a future commit,
for adding suspending inhibitors.
The proprietary nvidia driver garbles texture memory on suspend.
Before we can address that, we need to be able to detect it.
This commit adds a new UNSTABLE_TEXTURES feature that gets set if
the proprietary nvidia driver is in use.
It scaled the logical monitor rect with scale to get the stream
dimensions, but that is only valid when having
'scale-monitor-framebuffers' enabled. Even when it was, it didn't work
properly, as clutter_stage_capture_into() doesn't work properly with
scaled monitor framebuffers yet.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/415
Previously, the clipping rectangle passed to
`meta_surface_actor_get_image()` was updated with the actual texture
size, but recent changes in `meta_shaped_texture_get_image()` now keep
the caller's clipping rectangle unchanged.
The implementation of `meta_window_actor_capture_into()` was relying on
the old behavior of updating the passed clipping rectangle, but now that
it's kept unchanged, the actual clipping rectangle used to copy the data
is wrong, which causes either a distorded image or worse, a crash of
mutter.
Use the resulting cairo image size to copy the data instead of the
clipping rectangle to avoid the issue and get the expected size.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/442
The 'cursor-mode', which currently is limited to RecordMonitor(), allows
the user to either do screen casts where the cursor is hidden, embedded
in the framebuffer, or sent as PipeWire stream metadata.
The latter allows the user to get cursor updates sent, including the
cursor sprite, without requiring a stage paint each frame. Currently
this is done by using the cursor sprite texture, and either reading
directly from, or drawing to an offscreen framebuffer which is read from
instead, in case the texture is scaled.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/357
There may be reasons to temporarly inhibit the HW cursor under certain
circumstances. Allow adding such inhibitations by adding API to the
cursor renderer to allow API users to add generic inhibitors with
whatever logic is deemed necessary.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/357
To get a consistent behaviour no matter whether HW cursors are in use or
not, make sure to copy the framebuffer content before the stage overlays
(cursor sprite textures) are painted.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/357
This will be used by the screen casting code to check whether it should
wait for a frame before reading cursor state, or send only the cursor
update, if no redraw is queued.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/357
This means eglSwapBuffers() wont dead lock if there is an old buffer pending
page flip. This could happen after e.g. mode changes or for other reasons.
EGLStream textures are imported as GL_TEXTURE_EXTERNAL_OES and reading
pixels directly from them is not supported. To make it possible to get
pixels, create an offscreen framebuffer and paint the actor to it, then
read pixels from the framebuffer instead of the texture directly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/362
While for normal textures, GL_TEXTURE_2D should be used, when it's an external
texture, binding it using GL_TEXTURE_2D results in an error.
Reading the specification for GL_TEXTURE_EXTERNAL_OES it is unclear whether
getting pixel data from a texture is possible, and tests show it doesn't result
in any data, but in case it would eventually start working, at least bind the
correct target for now.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/362
Don't just set the internal format to the dummy format "any", as that causes
code intended to be unreachable code to be reached. It's not possible to
actually know the internal format of an external texture, however, so it might
not actually correspond to the real format.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/362
