| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Some windows, like Chromium and Steam, are technically CSD in that they
don't want a system titlebar and draw their own, but we should still
provide them with a shadow.
|
|
|
|
|
|
|
| |
As design patterns have evolved, dialogs that use CSD do use titlebar
buttons, so it's time to re-enable them for SSD as well.
https://bugzilla.gnome.org/show_bug.cgi?id=641630
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both Window and XSyncCounter are XIDs which on 64 bit X clients are 8
bytes wide. But the values on the wire are 32 bit so, for these types,
we always copy 4 bytes into results->prop. As such copying them out
with a cast such as *(Window *) means that we are actually reading 8
bytes which depending on whether the higher addressed 4 bytes are zero
means that sometimes this works while others it gives us a bogus
value.
https://bugzilla.gnome.org/show_bug.cgi?id=756074
|
|
|
|
|
|
|
|
| |
We cannot use the XSETTINGS value for cursor theme size because
gnome-settings-daemon already multiplies it by the primary monitor's
scale.
https://bugzilla.gnome.org/show_bug.cgi?id=755099
|
|
|
|
|
|
|
|
|
|
| |
We don't have any way of knowing what the intended size of a XWayland
cursor is supposed to be, so lets do what we do with regular XWayland
surfaces and don't scale them. The result is that cursor sprites of
HiDPI aware X11 clients will show correctly, but non-aware clients may
have tiny cursor sprites.
https://bugzilla.gnome.org/show_bug.cgi?id=755099
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each keyboard focus change ends up calling the MetaWaylandDataDevice
counterpart, we don't need though to notify the current selection
again. In order to fix this, keep track of the current client, and
only emit the relevant signals when the focus switches to another
client.
The situations where wl_data_device.selection were emitted during
focus changes between surfaces of the same client was inocuous most
of the times, although it's prone to inducing confusing behavior
on context menu clipboard actions, as the closing menu triggers a
focus change, which triggers a whole new wl_data_offer being created
and given on wl_data_device.selection, at a time where there's already
ongoing requests on the previous data offer.
https://bugzilla.gnome.org/show_bug.cgi?id=754357
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the transfer is cancelled, the X11SelectionData will be cleared from
the MetaSelectionBridge, although x11_data_write_cb() was invariably
expecting it to be non-NULL.
If the write was cancelled, all the actions done in x11_data_write_cb()
are moot, so just return early. If there's other errors happening
(eg. "connection closed" if the target client happens to crash), we
should still attempt at clearing the data anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=754357
|
|
|
|
|
|
|
|
|
|
|
| |
When committing a toplevel surface we might no longer have a MetaWindow
associated with it. The reason may vary but some are: a popup was
dismissed, the client attached and committed a NULL buffer to a
wl_surface with the wl_shell_surface role, the client committed a
buffer to a wl_surface which previously had an toplevel window role
which extension object was destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=755490
|
|
|
|
|
|
|
|
|
| |
If the drag dest surface suddenly disappears, we may find ourselves
processing an XdndPosition message that was sent before the X11 drag
source had an opportunity to find out.
In that case mutter does know, so double check before processing the
messages.
|
|
|
|
|
|
|
|
| |
We try to translate the atom with its corresponding mimetype both back
and forth, which actually breaks if the X11 client chose to announce the
mimetype atom. To do the translation properly, keep track on whether the
source announced the UTF8_STRING atom, and reply back with this only if
that happened.
|
|
|
|
|
| |
We may get a NULL one here, and we're wrongly attempting to remove
the old weak ref from the new data source object.
|
|
|
|
|
| |
data_device_end_drag_grab() will destroy the MetaWaylandDragGrab struct,
so we definitely must not use it after destruction.
|
|
|
|
|
| |
This tripped a new g-i warning; see
https://bugzilla.gnome.org/show_bug.cgi?id=752047
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the wayland surface isn't available yet when we process the
WL_SURFACE_ID ClientMessage, we schedule a later function to try the
association again after we get a chance to process wayland requests.
This works fine except on cases where the MetaWindow already had a
previous surface attached (i.e. when the xwindow is reparented) since
we only break the existing association on the later function which
means that when processing the old surface's destruction we destroy
the MetaWindow and cancel the pending later function leaving us
without a MetaWindow and an invisible surface.
Fix this by detaching the old surface as soon as possible so that the
MetaWindow survives.
https://bugzilla.gnome.org/show_bug.cgi?id=743339
|
|
|
|
|
|
|
|
| |
This shouldn't fail but apparently sometimes it does and in that case
having a possibly wrong idea of the keymap is still better than
crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=754979
|
|
|
|
|
|
|
|
|
|
| |
The saved rect is used to restore a saved window size. We need to
update this when the window is moved to a monitor with different scale,
so that if we unmaximize a window which was moved to a different
monitor while maximized (for example when unplugged) will restore to
the correct size.
https://bugzilla.gnome.org/show_bug.cgi?id=755097
|
|
|
|
|
|
|
|
|
| |
When a window is moved across monitors with different scales, its
rectangle is scaled accordingly. We also need to scale the
unconstrained_rect rectangle, so that moving a window via
meta_window_move_resize() which uses the unconstrained_rect.
https://bugzilla.gnome.org/show_bug.cgi?id=755097
|
|
|
|
| |
Storage class always goes first.
|
| |
|
|
|
|
|
| |
An unsigned number is never smaller than 0, so we don't have to
check for it.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
It is not a callback on a parameter signal, and get no GParamSpec passed
to it. This fixes a crash when a surface is on a destroyed output.
https://bugzilla.gnome.org/show_bug.cgi?id=755096
|
|
|
|
| |
Update NEWS.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Signals are sent to a specific ID, so we can't use "self" here. After
this revert, VT switching works again.
This reverts commit 8e22bf5bc96a7d9ff1aba8ea8217a4c3ca06b4ce.
https://bugzilla.gnome.org/show_bug.cgi?id=753434
|
|
|
|
|
| |
We know the variable only contains one or another string literal,
but keep compilers happy as well.
|
|
|
|
| |
Update NEWS.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Calling queue_redraw() in _force_update() is not needed because
update_cursor() will do this when needed, i.e. when switching between
hardware cursor and texture cursor, or when drawing with texture cursor.
There is also no need to force _native_force_update() because
update_cursor() will cover this as well when needed. When not changing
cursor but only the gbm_bo, the "dirty" boolean on the gbm_bo will
trigger a redraw.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
|
|
|
|
|
|
|
| |
Support notifying clients about what outputs their cursor surfaces are
on so that they can attach appropriately scaled buffers to them.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
The wl_pointer assigns a role to a wl_surface, so it makes sense to put
the related logic there.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
|
|
|
|
|
|
|
| |
It fills little purpose on separating into a MetaCursorImage struct, so
lets squash in the three fields into the MetaCursorSprite object.
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
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=754621
|
|
|
|
|
|
|
|
| |
Instead of hard-coding /dev/dri/card0, find the device
that has boot_vga flag set or has been explicitly
assigned a seat id other than seat0
https://bugzilla.gnome.org/show_bug.cgi?id=753434
|
|
|
|
|
|
|
|
|
|
|
| |
Fill in missing error checks and use g_error, since any
error in this phase would lead to crash later anyway.
This way we'll at least know what went wrong.
Although it was not the patch's original intention, it fixes
https://bugzilla.gnome.org/show_bug.cgi?id=754520
https://bugzilla.gnome.org/show_bug.cgi?id=753434
|
|
|
|
|
|
|
| |
Use path "/org/freedesktop/login1/session/self" instead of
getting session id and building the path manually
https://bugzilla.gnome.org/show_bug.cgi?id=753434
|
|
|
|
|
|
| |
There's not weston-launch anymore
https://bugzilla.gnome.org/show_bug.cgi?id=753434
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=754545
|
|
|
|
|
|
| |
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.
|