Raising and lowering windows in tandem without a proper grouping
mechanism ended up being more annoying than functional.
This reverts commit e76a0f564c.
If input happens to be grabbed somewhere along the shell, and ungrabbed
while a touch operation is ongoing, the wayland bits will happily start
sending wl_touch.update events from an undeterminate point, without
clients having ever received wl_touch.down for that id.
Consider those touches grabbed for the entirety of their lifetime, if
wl_touch.down wasn't received by the client, no other events will.
https://bugzilla.gnome.org/show_bug.cgi?id=776220
When capture_view* functions are called with the paint flag set
to TRUE, we need to setup the framebuffer, however this was
happening after setting up the viewport, while the viewport
needs the framebuffer to be valid when calling cogl_set_viewport.
https://bugzilla.gnome.org/show_bug.cgi?id=791809
The reason why multiple keycodes could be mapped to a single keysym was
to support having both KEY_FAVORITES and KEY_BOOKMARK map to
XF86Favorites. However, iterating through all layout levels adding all
key codes has severe consequences on layouts with levels that map
things like numbers and arrow. The result is that keybindings that
should only have been added for keycodes from the first level, are
replaced by some unexpected keycode where the same keysym was found on
another level.
An example of this is the up-arrow key and l symbol. Normally you'd find
both the up-arrow symbol and the l symbol on the first level and be done
with it. However, on the German Neo-2 layout, layout level 4 maps the
KEY_E to the l symbol, while layout level 4 maps KEY_E to up-arrow.
Which ever gets to take priority is arbitrary, but for this particular
case KEY_E incorrectly mapped to up-arrow instead of the l symbol,
causing the keyboard shortcut Super+l, which would normally lock the
screen, to trigger the workspace-up (Super+up-arrow) key binding.
https://bugzilla.gnome.org/show_bug.cgi?id=789300
When drmHandleEvent() returns an error and errno is set to EAGAIN,
instead of ending up in a busy loop, poll() the fd until there is
anything to read.
This is a simple backport of commit 406359bba1.
https://bugzilla.gnome.org/show_bug.cgi?id=791024
When the top window actor is destroyed, we need to make sure that
all its references are removed or it could be picked again in next
windows sync, causing crashes.
Since the window might or might not be destroyed when removed (depending
weather animations are in progress over it or not), it's just safer
to wait it to be destroyed before cleaning up any of its reference.
https://bugzilla.gnome.org/show_bug.cgi?id=791006
We only counted configured monitors and whether the config was
applicable (could be assigned), howeverwe didn't include disabled
monitors when comparing. This could caused incorrect configurations to
be applied when trying to use the previous configuration.
One scenario where this happened was one a system with one laptop
screen and one external monitor that was hot plugged some point after
start up. When the laptop lid was closed, the 'previous configuration'
being the configuration where only the laptop panel was enabled, passed
'is-complete' check as the number of configured monitors were correct,
and the configuration was applicable.
Avoid this issue by simply comparing the configuration key of the
previous configuration and the configuration key of the current state.
This correctly identifies a laptop panel with the lid closed as
inaccessible, thus doesn't incorrectly revert to the previous
configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=788915
When deriving the list of disabled monitors when creating new monitors
configs, don't include the laptop panel if the lid is currently closed,
as we consider the laptop panel nonexistent when the laptop lid is
closed when it comes to configuration.
The laptop panel connector(s) will either way be appropriately disabled
anyway, as the field listing disabled monitors in the configuration do
not affect actual CRTC/connector assignments.
https://bugzilla.gnome.org/show_bug.cgi?id=788915
We must emit ::dnd-leave to pair the ::dnd-enter that shall be
emitted whenever the plugin grab begins, otherwise we leave
listeners unable to clean up if the plugin begins and ends a
grab while there is an ongoing DnD operation.
https://bugzilla.gnome.org/show_bug.cgi?id=784545
Change the default key combo to re-enable normal keyboard shortcuts
processing while a shortcut inhibitor is in effect to Super+Escape as
primary system modifier key should be Super.
This should reduce the risk of potential conflict with other shortcuts.
https://bugzilla.gnome.org/show_bug.cgi?id=789386
We tried to get the geometry scale, which may depend on the main
logical monitor assigned to the window. To avoid dereferencing a NULL
logical monitor when headless, instead assume the geometry scale is 1.
https://bugzilla.gnome.org/show_bug.cgi?id=788764
Proprietary drivers such as ARM Mali export EGL_KHR_platform_gbm instead
of EGL_MESA_platform_gbm. As such, GBM platform check should be done for
both MESA and non-MESA drivers.
https://bugzilla.gnome.org/show_bug.cgi?id=780668
Bluetooth mouse usually goes in sleep state after a timeout, when that
happen the mouse is disconnected and on_device_removed function is
called. Before the patch if a touch device is available the
on_device_removed function hide the cursor. The issue is that the cursor
does not reappear once the bluetooth mouse is reconnected because
MetaBackend::current_device_id is not invalidated when on_device_removed
was called.
The patch set MetaBackend::current_device_id to 0 if the current device
is removed. This will make update_last_device to be triggered as soon as
another input device is used or the bluetooth mouse reconnect, as
consequence that the cursor reappear. The id 0 is never given to devices
and can safely used as undefine id.
https://bugzilla.gnome.org/show_bug.cgi?id=761067
This is not a leak per se, but it seems too easy to make valgrind
SIGSEGV due to MetaBackground disconnecting signals from an already
destroyed MetaScreen when trying to SIGTERM gnome-shell. Keeping a
reference fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=789984
The layout group determines what actual keyboard layout in the keymap
to use when translating modifier state and key codes to key syms.
When changing a keymap to another, the layout groups has no relation to
the layout groups in the old keymap, thus there is no reason to
transfer it to the new state.
This fixes an issue where the xkb state in meta-wayland-keyboard.c got
desynchronized with the xkb state in clutter-device-manager-evdev.c.
https://bugzilla.gnome.org/show_bug.cgi?id=789300
There seems to be a kernel race when one disconnects an external
monitor connected to a DisplayPort via a USB-C adapter. The race
results in a connector being reported as connected, but without any
modes supported.
This had the side effect that we tried to set a preferred mode to
the first listed mode, but as no modes were available, we instead tried
to dereference the first element of a NULL array, causing a
segmentation fault.
Mitigate this by skipping adding output if no supported modes are
advertised and the output doesn't support scaling, while moving the
fallback path for calculating a preferred output mode to after possibly
adding the common modes, to avoid the unvolentary NULL dereference.
https://bugzilla.gnome.org/show_bug.cgi?id=789501
Logical monitors keep pointers around to monitor objects, which themself
keep pointers aronud to outputs, which keeps pointer to modes and CRTCs.
To avoid causing crashes when using the logical monitor API (which
might use monitor APIs etc) between a hot plug and the time the logical
monitors are regenerated (which is done synchronously in the native
backend but asynchronously in the X11 backend), postpone the freeing of
the state that logical monitor references, until the logical monitor
state is regenerated.
On the native backend, this should have no significant effect, as the
logical state is always regenerated immediately after the hardware
state is updated, but on X11, this should fix race conditions when
events being processed between the hot plug and the hot plug result
tries to access the yet to be up to date state.
https://bugzilla.gnome.org/show_bug.cgi?id=786929
The handlers depend on a role being assigned. Destroying the window
causes it to become unmapped, which would sometimes trigger one of the
handlers, resulting in an is-assigned assert hitting in one of the
handlers. Avoid this by disconnecting the handlers earlier, so that
there is no risk that any them being triggered before the role is
assigned.
https://bugzilla.gnome.org/show_bug.cgi?id=789552
In the unlikely case that a surface is moved by the compositor while
holding a pointer confinement, we also need to update the pointer
position when the surface actor gets moved.
https://bugzilla.gnome.org/show_bug.cgi?id=782344
Both notify::position on the surface actor and position-changed on
MetaWindow are listened to, in order to trigger wl_output updates for
wl_surfaces whenever the surfaces move across them.
Both signals are necessary in order to cater for toplevel and subsurface
relocations (Because it's the parent window actor what changes position
in this last case).
Also, shuffle signal disconnection, so each signal goes away with
the object reference held by MetaWaylandSurface.
https://bugzilla.gnome.org/show_bug.cgi?id=782344
The org.gnome.desktop.peripherals.trackball.scroll-wheel-emulation-button
setting contains buttons X11-style. Work out the BTN evcode that applies
to it when applying the setting on the libinput device.
https://bugzilla.gnome.org/show_bug.cgi?id=787804
It looks that there are some extensions that run a Mainloop on startup,
causing to dispatch a clutter paint before the compositor is even available.
In such scenario a MetaWindow could try to start a simple effect
using a compositor plugin which is not there yet.
Then in order to catch these bugs we can now assert that the expected
conditions are valid, so that gnome-shell will provide a dumpstack to
debug the real offending JS code.
https://bugzilla.gnome.org/show_bug.cgi?id=789223
