Commit Graph

23860 Commits

Author SHA1 Message Date
Jonas Ådahl
556ed7b937 shaped-texture: Move variable declaration on top
Related: https://gitlab.gnome.org/GNOME/mutter/issues/300
2018-10-04 15:06:10 +02:00
Jonas Ådahl
b5a0068091 shaped-texture: Use ints for sizes
They were int before entering MetaShapedTexture, used as ints in the
cairo regions and rectangles, so there is no reason they should be
stored as unsigned.

Related: https://gitlab.gnome.org/GNOME/mutter/issues/300
2018-10-04 15:06:10 +02:00
Pekka Paalanen
a3d826c54b renderer/native: honour dumb buffer stride
meta_renderer_native_gles3_read_pixels() was assuming that the target
buffer stride == width * 4. This is not generally true. When a DRM
driver allocates a dumb buffer, it is free to choose a stride so that
the buffer can actually work on the hardware.

Record the driver chosen stride in MetaDumbBuffer, and use it in the CPU
copy path. This should fix any possible stride issues in
meta_renderer_native_gles3_read_pixels().
2018-10-04 11:57:35 +03:00
Pekka Paalanen
72e236106f renderer/native: assert dumb buffer size on CPU copy
Track the allocated dumb buffer size in MetaDumbBuffer. Assert that the
size is as expected in copy_shared_framebuffer_cpu().

This is just to ensure that Cogl and the real size match. The size from
Cogl was used in the copy, so getting that wrong might have written
beyond the allocation.

This is a safety measure and has not been observed to happen yet.
2018-10-04 11:57:35 +03:00
Pekka Paalanen
3e1ca62782 renderer/native: check format for drmModeAddFB fallback
If drmModeAddFB2() does not work, the fallback to drmModeAddFB() can
only handle a single specific format. Make sure the requested format is
that one format, and fail the operation otherwise.

This should at least makes the failure mode obvious on such old systems
where the kernel does not support AddFB2, rather than producing wrong
colors.
2018-10-04 11:57:35 +03:00
Marek Cernocky
c71f6a18ad Updated Czech translation 2018-10-01 17:39:07 +02:00
Marek Cernocky
f7c1f418ba Updated Czech translation 2018-10-01 17:36:18 +02:00
Марко Костић
0210b95109 Update Serbian translation 2018-09-29 10:05:53 +00:00
Olivier Fourdan
68ec9ac017 wayland: No xdg-output events without a logical monitor
To avoid a known race condition in the wl_output protocol documented in
https://phabricator.freedesktop.org/T7722, mutter delays the `wl_output`
destruction but nullify the `logical_monitor` associated with the
`wl_output` and the binding routine `bind_output()` makes sure not to
send wl_output events if the `logical_monitor` is `NULL` (see commit
1923db97).

The binding routine for `xdg_output` however does not check for such a
condition, hence if the output configuration changes while a client is
binding to xdg-output (typically Xwayland at startup), mutter would
crash while trying to access the `logical_monitor` which was nullified
by the change in configuration.

Just like `bind_output()` does for wl_output, do not send xdg-output
events if there is no `logical_monitor` yet.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/194
2018-09-25 15:14:18 +02:00
Carlos Garnacho
8dcac664fa core: Preserve focus across decoration changes
Changes in window decoration result in the window being reparented
in and out its frame. This in turn causes unmap/map events, and
XI_FocusOut if the window happened to be focused.

In order to preserve the focused window across the decoration change,
add a flag so that the focus may be restored on MapNotify.

Closes: #273
2018-09-24 13:44:53 +00:00
Olivier Fourdan
2fb3db7659 compositor: Skip windows not visible to the compositor
The compositor will automatically unredirect the top most window which
is fully visible on screen. When unredirecting windows, it also shapes
the compositor overlay window (COW) so that other redirected windows
still shows correctly.

The function `get_top_visible_window_actor()` however will simply walks
down the window list, so if a window is placed on a layer above and
unredirected, then iconified by the client, it will still be picked up
by `get_top_visible_window_actor()` and he compositor will reckon it's
still unredirected while not in a visible state anymore, thus leaving a
black area on screen.

Make sure we skip the windows not known to the compositor while picking
the top visible window actor to avoid this issue.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/306
2018-09-21 18:50:06 +02:00
Jonas Ådahl
7d82cdeea3 window/wayland: Freeze updates until shown
Not until the window is shown do we know what monitor it's on, thus the
size, so freeze updates (shape etc) until the window is shown.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/229
2018-09-19 15:39:54 +00:00
Jonas Ådahl
e2e7296612 window: Move out 'updates frozen' state into implementations
Implementation of said state was just related to X11, so move it into
window-x11.c. The Wayland path always fell back on the returning TRUE,
so just do that for now.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/229
2018-09-19 15:39:54 +00:00
Tony Novak
8685de9607 input-settings: detect trackball using udev ID_INPUT_TRACKBALL
Previously, trackballs were detected based on the presence of the
substring "trackball" in the device name. This had the downside of
missing devices, such as the Kensington Expert Mouse, which don't have
"trackball" in their names.

Rather than depending on the device name, use the ID_INPUT_TRACKBALL
property from udev to determine whether or not to treat a device as a
trackball.

This adds a new function, `is_trackball_device`, to MetaInputEvents, and
eliminates the `meta_input_device_is_trackball` function.

Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/258
2018-09-19 08:48:27 +00:00
Sam Spilsbury
a8a3c1017f actor: Also recompute paint volume if we recently dropped effects
Otherwise we'll be stuck with the same paint volume on the last
frame of the given effect, which could be wrong.
2018-09-18 19:39:12 +00:00
Sam Spilsbury
5d19aee23a actor: Always use get_paint_volume override for active effects
If an effect is active and it overrides the paint volume, we should
always recompute the paint volume when requested and not use the
cache, since the paint volume override can change from call to
call depending on what phase of painting we are in. For instance,
if we are part way through painting effects and request the
paint volume, the paint volume should only go up to the current
effect, but in a later call to compute repaint regions, the
paint volume needs to expand to accomadate the effect.

This still involves a lot of recomputation in the case of effects -
in a later clutter version it would be worth adding an API to
allow effects to explicitly recompute and return a new the paint
volume up to the current effect as opposed to recomputing
the cached one.
2018-09-18 19:39:12 +00:00
Sam Spilsbury
4270eef16e actor: Fix logic error in determining terminal effect for paint volume
Previously we were checking l->data != NULL || (l->data != NULL &&
l->data != priv->current_effect). This would continue the loop even
if l->data == priv->current_effect, since l->data != NULL, which was
not the intention of that loop.

We also don't need to check that l->data != NULL before checking if
it does not match the current_effect, since we already checked
that current_effect was non-NULL before entering the loop.
2018-09-18 19:39:12 +00:00
Olivier Fourdan
b443bd42ac window: unmanage dialog when clearing transient_for
On Wayland, xdg-foreign would leave a modal dialog managed even after
the imported surface is destroyed.

This is sub-optimal and this breaks the atomic relationship one would
expect between the parent and its modal dialog.

Make sure we unmanage the dialog if transient_for is unset even for
Wayland native windows.

Related: https://gitlab.gnome.org/GNOME/mutter/issues/174
Related: https://gitlab.gnome.org/GNOME/mutter/issues/221
2018-09-14 11:11:31 +02:00
Ting-Wei Lan
267503b5f3 build: Fix non-wayland builds 2018-09-11 16:19:19 +00:00
Florian Müllner
a3d9f987c8 input-settings-x11: Push error trap
Pops are lonely without push, so add one for a happy error trap.

https://gitlab.gnome.org/GNOME/mutter/issues/294
2018-09-07 19:42:37 +02:00
Carlos Garnacho
9cfd185316 clutter: Handle grabs from CLUTTER_TABLET_DEVICE devices
Those would result in warnings. Actually, these should be dealt
similarly to pointers, as they get their own standalone pointer
cursor in Wayland.

Related: https://gitlab.gnome.org/GNOME/gnome-shell/issues/540
2018-09-07 15:17:36 +02:00
Peter Hutterer
176117c5f7 device-manager-evdev: handle tablet axis motion before button and tip events
Some tablets have a noticable pointer jump on tip down/up, causing unintended
lines during drawing. Likewise, a button event may have an axis update that we
currently ignore. libinput provides tablet axis events only if no other state
changes, the client must instead get the current axis data from the tip/button
event. So let's do this, process the event axis data during tip/button as
well.

A libinput recording to reproduce is the 'dots.yml' in
https://gitlab.freedesktop.org/libinput/libinput/issues/128

Fixes #289
2018-09-07 19:54:06 +10:00
Yuras Shumovich
8083065579 Update Belarusian translation 2018-09-06 15:48:19 +00:00
Florian Müllner
34f5be726d Bump version to 3.30.0
Update NEWS.
2018-09-04 00:05:51 +02:00
gogo
b53707f8c4 Update Croatian translation 2018-09-02 16:40:57 +00:00
Ask Hjorth Larsen
d9294e4eb0 Updated Danish translation 2018-09-01 18:46:09 +02:00
Trần Ngọc Quân
94f8acc8fe Updated Vietnamese translation
Signed-off-by: Trần Ngọc Quân <vnwildman@gmail.com>
2018-09-01 08:30:06 +07:00
Rūdolfs Mazurs
4841c1b13e Update Latvian translation 2018-08-31 17:56:20 +00:00
Balázs Meskó
1e00cd290d Update Hungarian translation 2018-08-31 13:05:10 +00:00
Fran Dieguez
3daa2d2751 Update Galician translation 2018-08-29 22:24:03 +00:00
Florian Müllner
444af437a0 Bump version to 3.29.92
Update NEWS.
2018-08-29 18:42:02 +02:00
Marek Cernocky
eebcf98284 Updated Czech translation 2018-08-29 07:30:18 +02:00
Marek Cernocky
7d973ac538 Updated Czech translation 2018-08-29 07:29:26 +02:00
Rafael Fontenelle
0ada04089c Update Brazilian Portuguese translation 2018-08-28 23:00:01 +00:00
Carlos Garnacho
85284acb00 clutter/x11: Implement keycode lookup from keysyms on virtual key devices
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
2018-08-28 12:22:52 +02:00
Anders Jonsson
388d065699 Update Swedish translation 2018-08-27 22:56:25 +00:00
Jonas Ådahl
e191c21e04 window/wayland: Don't recursive indefinitely when updating monitor
When we update the main monitor, there is a rule that makes it so that
popup windows use the same main monitor as their parent. In the commit
f4d07caa38 the call that updates and
fetches the main monitor of the toplevel accidentally changed to update
from itself, causing a indefinite recursion eventually resulting in a
crash.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/279
2018-08-27 17:49:52 +02:00
Jonas Ådahl
5376c31a33 window: Keep windows with placement rule attached to parent
A window placed using a placement rule should keep that relative
position even if the parent window moves, as the position tied to the
parent window, not to the stage. Thus, if the parent window moves, the
child window should move with it.

In the implementation in this commit, the constraints engine is not
used when repositioning the children; the window is simply positioned
according to the effective placement rule that was derived from the
initial constraining, as the a xdg_popup at the moment cannot move
(relative its parent) after being mapped.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/274
2018-08-27 12:15:06 +00:00
Jonas Ådahl
ca5b27baf5 wayland/gtk-shell: Handle requests after toplevel was unmanaged
As with xdg-toplevel, a gtk-surface can be unmanaged by the compositor
without the client knowing about it, meaning the client may still send
updates and make requests. Handle this gracefully by ignoring them. The
client needs to reset all the state anyway, if it wants to remap the
same surface.

https://gitlab.gnome.org/GNOME/mutter/issues/240
2018-08-27 11:43:53 +00:00
Jonas Ådahl
64df627688 wayland/legacy-xdg-shell: Handle requests after toplevel was unmanaged
As with xdg-toplevel proper, a legacy xdg-toplevel can be unmanaged by
the compositor without the client knowing about it, meaning the client
may still send updates and make requests. Handle this gracefully by
ignoring them. The client needs to reassign the surface the legacy
xdg-toplevel role again, if it wants to remap the same surface, meaning
all state would be reset anyway.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/240
2018-08-27 11:43:53 +00:00
Jonas Ådahl
a740f50cd7 wayland/legacy-xdg-shell: Cache frame callbacks if toplevel is unmanaged
A toplevel window can be unmanaged without the client knowing it (e.g. a
modal dialog being unmapped together with its parent. When this has
happened, take frame callbacks queued on a commit and cache them on the
generic surface queue. If the toplevel is to be remapped because the
surface was reassigned the toplevel role, the cached frame callbacks
will be queued on the surface actor and dispatched accordingly.

https://gitlab.gnome.org/GNOME/mutter/issues/240
2018-08-27 11:43:53 +00:00
Jonas Ådahl
5fd0f62a62 wayland/xdg-shell: Handle requests after toplevel was unmanaged
A window can be unmanaged without asking the client to do it, for
example as a side effect of a parent window being unmanaged, if the
child window was a attached dialog.

This means that the client might still make requests post updates to it
after that it was unmapped. Handle this gracefully by NULL-checking the
surface's MetaWindow pointer. We're not loosing any state due to this,
as if the client wants to map the same surface again, it needs to either
reassign it the toplevel role, or reset the xdg-toplevel, both resulting
in all state being lost anyway.

https://gitlab.gnome.org/GNOME/mutter/issues/240
2018-08-27 11:43:53 +00:00
Jonas Ådahl
80d420ff43 wayland/xdg-shell: Cache frame callbacks if toplevel is unmanaged
A toplevel window can be unmanaged without the client knowing it (e.g. a
modal dialog being unmapped together with its parent. When this has
happened, take frame callbacks queued on a commit and cache them on the
generic surface queue. If the toplevel is to be remapped, either because
the surface was reassigned the toplevel role, or if it was reset and
remapped, the cached frame callbacks will be queued on the surface actor
and dispatched accordingly.

https://gitlab.gnome.org/GNOME/mutter/issues/240
2018-08-27 11:43:53 +00:00
Jonas Ådahl
407d62943c wayland/xdg-shell: Cache pending frame callbacks on popup reset
A popup can be reset, and when that happens, window and actor are
destroyed, and won't be created again unless it is reassigned the
popup role.

If a client queued frame callbacks when resetting a popup, the frame
callbacks would be left in the pending state, as they were not queued on
the actor, meaning we'd hit an assert about the frame callbacks not
being handled. Fix this by caching them on the MetaWaylandSurface, so
that they either are cleaned up on destruction, or queued on the actor
would the surface be re-assigned the popup role.

https://gitlab.gnome.org/GNOME/mutter/issues/240
2018-08-27 11:43:53 +00:00
Jonas Ådahl
0ace58d05f wayland/surface: Add API to cache frame callbacks
Sometimes it may be useful for roles to put callbacks in the generic
surface frame callback queue. The surface frame callback queue will
either eventually be processed on the next surface role assignment that
places the frame callbacks in a role specific queue, processed at some
other point in time by a role, or cleaned up on surface destruction.

https://gitlab.gnome.org/GNOME/mutter/issues/240
2018-08-27 11:43:53 +00:00
Jonas Ådahl
d791710197 wayland/xdg-shell: Queue frame callbacks on new actor after resetting
When a xdg-toplevel is reset, the window and actor are recreated, and
all state is cleared. When this happened, we earlied out from the
xdg-toplevel commit handler, which would mean that if the client had
queued frame callbacks when resetting, they'd be left in the pending
commit state, later hitting an assert as they were not handled.

Fix this by queuing the frame callbacks no the new actor, so that they
are emitted whenever the actor is eventually painted.

https://gitlab.gnome.org/GNOME/mutter/issues/240
2018-08-27 11:43:53 +00:00
Carlos Garnacho
b30c907ef9 wayland: Use geometry_scale on opaque regions
This was done for input regions in commit 718a89eb2f (Thanks Jonas
for the archaeology!) but opaque regions follow the same scaling.
This brings less evident issues as opaque regions are just used for
culling optimizations.
2018-08-27 08:38:13 +00:00
Carlos Garnacho
784a774d9c wayland: Fix input/opaque regions calculation on hidpi
Commit 6a92c6f83 unintendedly broke input/opaque region calculations
on hidpi. Most visible side effect is that clicking is only allowed
in the upper-left quarter of windows.

The surface coordinates are returned in logical unscaled buffer
size. We're however interested in actor coordinates (thus real
pixels) here.

As it is a bit of a detour how the scale to be applied is calculated,
refactor a meta_wayland_actor_surface_get_geometry_scale() function
that we can use it here, and use it consistently for surface size and
the given regions.
2018-08-27 08:38:12 +00:00
Jonas Ådahl
8d3e053059 window: Force update monitor on hot plugs
Commit a3da4b8d5b changed updating of
window monitors to always use take affect when it was done from a
non-user operation. This could cause feed back loops when a non-user
driven operation would trigger the changing of a monitor, which itself
would trigger changing of the monitor again due to a window scale
change.

The reason for the change, was that when the window monitor changed due
to a hot plug, if it didn't actually change, eventually the window
monitor pointer would be pointing to freed memory.

Instead of force updating the monitor on all non-user operations, just
do it on hot plugs. This allows for the feedback loop preventing logic
to still do what its supposed to do, without risking dangling pointers
on hot plugs.

Related: https://gitlab.gnome.org/GNOME/mutter/issues/189
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/192
2018-08-27 08:33:00 +00:00
Jonas Ådahl
f4d07caa38 window: Pass flag to meta_window_update_monitor() instead of bool
The bool determines whether the call was directly from a user operation
or not. To add more state into the call without having to add more
boolenas, change the boolean to a flag (so far with 'none' and 'user-op'
as possible values). No functional changes were made.

https://gitlab.gnome.org/GNOME/mutter/issues/192
2018-08-27 08:33:00 +00:00