Commits on Source (91)
-
Sebastian Keller authored
queue_result_feedback() takes ownership of the result listeners list via meta_kms_update_take_result_listeners(), but does not free it. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2922>
7fbef2cb -
Jonas Ådahl authored
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2926>
176418d0 -
Daniel van Vugt authored
It's not really an error and we recover seamlessly. If someone really wants to check if/why direct scanout is failing then they can still use `env MUTTER_DEBUG=render,kms`. Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2702 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2918>
46e1ede6 -
Daniel van Vugt authored
Which would trigger: ``` g_hash_table_destroy: assertion 'hash_table != NULL' failed ``` on non-KMS systems like with `nvidia-drm.modeset=0`. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2904>
1be2f635 -
Sebastian Wick authored
The unknown color space's only purpose is to signal that the current KMS state has a unknown color space set. It is not one of the color spaces that can be set. We already only try to set a color space if the default color space is supported so we should use the default color space as a fallback instead of the unknown color space. Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2693 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2915>
3988f5a4 -
Florian Müllner authored
Both GRAB_OP_KEYBOARD_MOVING and GRAB_OP_KEYBOARD_RESIZING_* are defined as GRAB_OP_WINDOW_BASE with FLAG_KEYBOARD set, but the latter have additional bits set to indicate the direction. That is, the GRAB_OP_KEYBOARD_MOVING bitmask cannot be used to differentiate between move- and resize operations. Instead, check that no direction bits are set. https://gitlab.gnome.org/GNOME/mutter/-/issues/2684 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2908>
f14dcb02 -
It is needed in gnome-shell in the screenshot UI to tell which window has a pointer over it. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2928>
4f47ba26 -
Emmanuele Bassi authored
GValues containing objects and strings can be set to NULL, which means the transformation functions from ClutterPath to string and vice versa must be NULL-safe. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2625 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2929>
bc9cad51 -
Jonas Ådahl authored
This avoids a crash when pointer constraints are enabled by Wayland clients. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2932>
83a6a011 -
Simon McVittie authored
On systems that have undergone the /usr merge, /bin/bash and /usr/bin/bash can be used interchangeably, but on systems where /bin and /usr/bin are separate (such as Debian 11 or older), bash was traditionally in /bin and there is no bash in /usr/bin. Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/2385 Signed-off-by: Simon McVittie <smcv@debian.org> Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2900>
d6af73ba -
Sebastian Keller authored
Both Clutter and Cogl use g_return(_val)_if_fail() to safeguard introspected API. Release builds were dropping these checks, which could result in a much more crashy experience, especially when considering extensions, but also due to bugs in the shell code itself. This won't affect any major distro, because they all use "plain" builds. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2930>
679d2fb4 -
Jonas Dreßler authored
scan_visible_region() scans through each value of a uint8_t array and checks whether that value is 255. Right now it always checks one value too much though, resulting in a buffer overflow. Fix that by checking the array bounds before actually accessing the array. Found by running gnome-shell with address sanitizer and starting GIMP. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2856>
7455c293 -
Boyuan Yang authoredb215a657
-
Daniel van Vugt authored
Since 73fb64cb we have preferred to handle failed updates via callback but the cursor-only update path was forgotten and so wasn't getting frame notifications. And so the frame clock would freeze. Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2691 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2933>
61801a71 -
Carlos Garnacho authored
Since we only track changes to window_drag->anchor_window_pos during move operations through on_grab_window_size_changed(), this rectangle is in essence the same than window_drag->initial_window_pos all the time. Just use that and move away from the anchor_window_pos rectangle. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2942>
179124dc -
Carlos Garnacho authored
The anchor position calculations are somewhat unnecessarily complex based on root coordinates of pointer and frame positions. This requires tracking both things, and we don't always get it quite right with the latter (e.g. window repositions, resizes or overshrinks, leaving the anchor position visually outside the window). In order to improve this, capture the window-relative coordinates when starting the window drag, and ensure the window is always repositioned in that position, relative to its current size. This avoids these glitches when unmaximizing a window (e.g. dragged from the bottom through super+button1 press), or moving windows between monitors with different scales. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2730 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2942>
7eb01304 -
Carlos Garnacho authored
This is now only set and never used. We can remove it. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2942>
f3f1db5e -
Jonas Ådahl authored
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2944>
8ca94f4d -
Trần Ngọc Quân authored0d385f54
-
Nathan Follens authored29c14ba0
-
Chris Mayo authored
../mutter-44.0/src/backends/meta-backend.c: In function ‘meta_backend_real_post_init’: ../mutter-44.0/src/backends/meta-backend.c:560:7: error: ‘MetaBackendPrivate’ {aka ‘struct _MetaBackendPrivate’} has no member named ‘remote_access_controller’ 560 | priv->remote_access_controller = | ^~ Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2655 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2935>
28a59963 -
Marco Trevisan authored
The window tracker is filtering XEvents manually as it only requires a subset of the ones that Gdk listens to in the root window, and this is nice, but we were restricting the set a bit too much because due to this we were not notified when an xsettings manager was available, and thus in case gsd-xsettings was launched after meta-window-tracker (a normal scenario under X11), no xsetting was actually applied to the decoration windows. As per this, the default settings were used for everything and never updated, until a restart of the window-tracker. In order to be able to monitor the XSettings changes at startup, we also need to select the StructureNotifyMask as gtk always do by default. See also: https://gitlab.gnome.org/GNOME/gtk/-/blob/4.11.1/gdk/x11/gdkscreen-x11.c#L947-950 Fixes: #2580 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2948>
20e2adc4 -
Carlos Garnacho authored
We convert an atom to string just to convert it to an atom. We can avoid the roundtrip. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2945>
2e827020 -
Carlos Garnacho authored
Lest it fails. Try to recover from that and keep reading the mimetypes present in the atom list. Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6555 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2945>
1e459c83 -
Florian Müllner authored
Returning FALSE does not indicate an error, but a valid backlight value of 0. Consumers expect a negative value to indicate no backlight support, so return -1 in case of error, just like we already do for invalid values. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2947>
aa1eaa81 -
Florian Müllner authored
Whether a value is in range depends on the backlight-min/max values, and I didn't spot anything that excludes 0 as a valid lower limit outright. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2947>
018786da -
Jonas Ådahl authored
The non-graphene-point variant is deprecated. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2949>
ab36baa9 -
Salman authored
This change allows clipped redraws for offscreen. The net effect of this change is to preserve the original redraw clip when possible (rather than overwriting it with the full view redraw) in the paint context. This eventually helps in retrieving the fine grained updated regions of the frame since last redraw and sending it to the pipewire client (as shown in a subsquent CL). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2775>
43cee4b6 -
Salman authored
This change makes it easier to add/remove stream params during test/dev. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2775>
62237429 -
Salman authored
This change will export the damaged regions (when available) out to the pipewire client. This change is currently specific to virtual streams only (where I was able to test the change) and maintains the current behavior for other screencast stream types. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2775>
776e3f32 -
Corentin Noël authored
Add the (optional) parameters when they are actually supported and at least add the minimal documentation on functions. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2951>
eeee6540 -
This is not yet used, but next commits will need to assign a frame to the paint context whenever painting onscreens. Assigning a frame to the paint context is a one-way operation, and treats multiple assignments strictly as a programming error. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
82b037e7 -
When rendering through the 'paint-view' handler, assign the frame to the paint context. Otherwise, when rendering outside of the frame clock schedule, don't. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
81c9c43d -
We'll need to access the timestamp of the frame later on, so pass it to stage watchers. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
b47d96b8 -
Add meta_screen_cast_stream_src_maybe_record_frame_with_timestamp() which operates on arbitrary timestamps; and make the current function meta_screen_cast_stream_src_maybe_record_frame() just call into the new variant, passing g_get_monotonic_time() as the timestamp. This will be useful later we start using the target timestamp of the frame for screencasting. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
16aa2943 -
When a stream source subclass asks for a DMA-BUF only frame record, it is legitimate to return FALSE in do_record_frame() - meaning that a frame was not recorded - but not return an error - meaning nothing actually failed. This avoids spamming the journal with warnings on a legitimate case. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
ded7b8df -
This GError is only used within the frame recording block, so move it there. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
7f28fa6c -
Instead of always, unconditionally scheduling an idle callback for frame recording, try to record a DMA-BUF only frame, and only if that's not possible, schedule the idle callback. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
bc2f1145 -
Pass the timestamp of the frame as the target timestamp of the record. This makes the rudimentary frame throttling mechanism inside MetaScreenCastStreamSrc work with the timing variability that dynamic dispatch times introduced. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
bc19f551 -
Carlos Garnacho authored
Do not make code live before variable declarations. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2954>
e30abee5 -
Carlos Garnacho authored
In practical effects the passed Window is always window->xwindow, so pass the MetaWindow and get the better X11 Window deep in the call stack. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2954>
a42bc34e -
Carlos Garnacho authored
With the frames client, we do no longer handle events for the frame window inside Mutter. This means we do not get events "for free" to handle focus on a just clicked frame window. This results in a background window not ending up focused if clicked on its frame. In order to fix this, make the passive button grab extend to the frame window if a window has one. This brings back focus-on-click behavior, while treating windows further as a unitary surface. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2727 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2954>
f744acef -
Jonas Ådahl authored
If the popup was dismissed (i.e. has no MetaWindow anymore), it'll also have no parent surface. With no parent surface, we'd try to fetch a transaction from NULL and crash, but if we don't try if we were dismissed, we won't reach here anyway. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2940>
697b99ee -
Jonas Ådahl authored
Destroying is insufficient as it doesn't end any popup pointer grab, if the dismissed popup was the last. This would later hit an assert as the popup grab is assumed to always have at least one popup in its chain. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2728 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2940>
50a37a7f -
Jonas Ådahl authored
We might end up trying to apply a pending state late if it was delayed by DMA buffers not being ready. Trying to discard the pending state from the transaction when dismissing is hard, because we might be applying a chain of transactions that would disqualify subsequent transactions if a former one dismisses the popup, so lets just drop what the apply would otherwise do, if we're not going to use it anyway. This fixes the following crash: 0) meta_wayland_surface_get_window (surface=0x0) 1) meta_wayland_xdg_popup_apply_state (surface_role=0xf5ee80, pending=0xf662a0) 2) meta_wayland_surface_role_apply_state (surface_role=0xf5ee80, pending=0xf662a0) 3) meta_wayland_surface_apply_state (surface=0xf5e640, state=0xf662a0) 4) meta_wayland_transaction_apply (transaction=0xf56170, first_candidate=0x7fffffffcee8) 5) meta_wayland_transaction_maybe_apply_one (transaction=0xf56170, first_candidate=0x7fffffffcee8) 6) meta_wayland_transaction_maybe_apply (transaction=0xf56170) 7) meta_wayland_transaction_dma_buf_dispatch (buffer=0xf448a0, user_data=0xf56200) 8) meta_wayland_dma_buf_source_dispatch (base=0xf5f140, callback=0x0, user_data=0x0) 9) g_main_dispatch (context=0x41baa0) Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2940>
47b6e765 -
Sebastian Keller authored
After this got changed from gdk_x11_get_xatom_name() to XGetAtomName(), this no longer returns a const char* and it now also needs to be freed. Fixes: 014cde64 ("wayland: Do not use GDK functions on XDnD implementation") Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2957>
5a4b67dd -
Sebastian Keller authored
The private format and type member variables were not being used by any of the callers, so they can simply be removed. This also fixes a leak of type which was introduced when switching from gdk_x11_get_xatom_name() to XGetAtomName(). Fixes: e66f4396 ("x11: Avoid GDK API in X11 selections") Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2957>
01ae1d32 -
Sebastian Keller authored
This was pointlessly being converted between atom and string and back, which with the switch from gdk_x11_get_xatom_name() to XGetAtomName() also introduced a leak for every XGetAtomName() call. Fixes: e66f4396 ("x11: Avoid GDK API in X11 selections") Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2957>
94bd5c73 -
Sebastian Keller authored
After this got changed from gdk_x11_get_xatom_name() to XGetAtomName(), this no longer returns a const char* and it now also needs to be freed. Fixes: e66f4396 ("x11: Avoid GDK API in X11 selections") Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2957>
6fbe4286 -
Carlos Garnacho authored
Ensure the frame window is created at the right fullscreen state before showing it and assigning it to the client window. A peculiarity of this property on frame windows is that it is typically single-handedly updated from the Mutter side, in synchronization with client window state. It can only differ during creation, since GTK still likes to apply its own state. Also, the only relevant property seems to be _NET_WM_STATE_FULLSCREEN, since the others are less relevant to the role of the frames client, and get applied to the MetaWindow as a whole, instead. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2712 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2961>
2a600ac9 -
msizanoen1 authored
This ensures that applications are notified when a drag gets cancelled because the user dropped or press ESC while in overview. This fixes an issue with Chromium on Wayland refusing to acknowledge wl_pointer::enter events after accidentally dropping a Chromium-originated object in GNOME Shell overview. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2953>
ce0d9ccb -
msizanoen1 authored
This ensures a consistent code path with other cases where the drag operation might be cancelled. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2953>
1b140e8c -
Sebastian Keller authored
create_and_send_dnd_offer() sets the compositor of the offer to the one from the MetaWaylandDataSource. This then later gets used in display_from_offer() when trying to get the context from the compositor. meta_wayland_data_source_xwayland_new() however was not setting the compositor, so this was causing crashes when dragging things from X11 windows on Wayland. Fixes: 2731f0cd ("wayland: Setup and use ownership chains") Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2723 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2956>
a8690009 -
Sebastian Keller authored
When selecting the default focus window, is_focusable() was not considering the new conditions for whether a window should be shown or hidden that were added to meta_window_should_be_showing() in 39942974. As a result the default focus window could end up a window already hidden or hidden once meta_window_flush_calc_showing() is called by meta_window_focus() when focusing the default window. This would cause meta_window_focus() to fail, which is an issue if it prevents us from unfocusing a window when it is getting unmanaged. Fixes: 39942974 ("x11: Integrate frames client into Mutter") Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2644 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2962>
6b57ab89 -
Sebastian Keller authored
The X server ignores the send_event and serial in incoming XEvents, so they were not initialized when calling XSendEvent in a few places. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2641 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2964>
dddaf19d -
Robert Mader authored
It will be used to schedule Wayland frame events independently from both update and presentation time, as the former may happen multiple times frame and the later not at all. For frame events we want a timing that is just late enough to ensure that a following commit by a Wayland client will not get included into the current frame any more. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2823>
ff246a2d -
Robert Mader authored
So that information is available in e.g. after_update handlers. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2823>
020d128d -
Robert Mader authored
It will be used in the next commit. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2823>
87b38436 -
Robert Mader authored
Under certain conditions a stage-view update does not trigger a kms update. In such cases we still want the next update to run within the same refresh cycle, as otherwise we'd waste the remaining time in the current one. At the same time we currently use the `after-update` signal for Wayland frame events, which again may result in more "empty" updates - creating an unthrottled feedback loop. This can trigger excessive load both in the compositor as well as in clients. Introduce a new GSource that is dispatched once per refresh cycle at maximum per stage view and use it to emit frame events. Do so by computing the time from when on we can be sure that an update resulting from a client commit would certainly get scheduled to the next refresh cycle. Note: this only works on the native backend. Given that chances are small that we hit the corresponding issue on e.g. the nested backend, stick to the previous behavior there for now. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2823>
a7a7933e -
Jonas Ådahl authored
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2968>
92521313 -
Jonas Ådahl authored
Otherwise we'll have a cursor sprite backed by a surface that no longer exist. This usually doesn't happen, but can happen in rare situations related to pointer capability changes Wayland client cursor changes and hotplugs. Fixes the following crash: #0 meta_wayland_buffer_get_resource() at ../src/wayland/meta-wayland-buffer.c:128 #1 realize_cursor_sprite_from_wl_buffer_for_gpu() at ../src/backends/native/meta-cursor-renderer-native.c:1649 #2 realize_cursor_sprite_for_gpu() at ../src/backends/native/meta-cursor-renderer-native.c:1869 #3 realize_cursor_sprite() at ../src/backends/native/meta-cursor-renderer-native.c:1887 #4 meta_cursor_renderer_native_update_cursor() at ../src/backends/native/meta-cursor-renderer-native.c:1100 #5 meta_cursor_renderer_update_cursor() at ../src/backends/meta-cursor-renderer.c:414 #6 meta_cursor_renderer_force_update() at ../src/backends/meta-cursor-renderer.c:449 #7 update_cursors() at ../src/backends/meta-backend.c:328 #8 meta_backend_monitors_changed() at ../src/backends/meta-backend.c:338 #9 meta_monitor_manager_notify_monitors_changed() at ../src/backends/meta-monitor-manager.c:3590 #10 meta_monitor_manager_rebuild() at ../src/backends/meta-monitor-manager.c:3678 #11 meta_monitor_manager_native_apply_monitors_config() at ../src/backends/native/meta-monitor-manager-native.c:343 #12 meta_monitor_manager_apply_monitors_config() at ../src/backends/meta-monitor-manager.c:706 #13 meta_monitor_manager_ensure_configured() at ../src/backends/meta-monitor-manager.c:779 #14 meta_monitor_manager_reconfigure() at ../src/backends/meta-monitor-manager.c:3738 #15 meta_monitor_manager_reload() at ../src/backends/meta-monitor-manager.c:3745 or the following on gnome-43: #0 meta_wayland_surface_get_buffer at ../src/wayland/meta-wayland-surface.c:441 #1 meta_cursor_sprite_wayland_get_buffer at ../src/wayland/meta-cursor-sprite-wayland.c:83 #2 realize_cursor_sprite_from_wl_buffer_for_gpu at ../src/backends/native/meta-cursor-renderer-native.c:1612 #3 realize_cursor_sprite_for_gpu at ../src/backends/native/meta-cursor-renderer-native.c:1836 #4 realize_cursor_sprite at ../src/backends/native/meta-cursor-renderer-native.c:1854 #5 meta_cursor_renderer_native_update_cursor at ../src/backends/native/meta-cursor-renderer-native.c:1087 #6 meta_cursor_renderer_update_cursor at ../src/backends/meta-cursor-renderer.c:413 #7 meta_cursor_renderer_force_update at ../src/backends/meta-cursor-renderer.c:448 #8 update_cursors at ../src/backends/meta-backend.c:344 #9 meta_backend_monitors_changed at ../src/backends/meta-backend.c:354 Related: https://bugzilla.redhat.com/show_bug.cgi?id=2185113 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2968>
867494d3 -
Michel Dänzer authored
This function gets called when a surface state transaction is applied. Applying a transaction can get delayed, so the Wayland resource may have already been destroyed when we get here. In that case we cannot send events, so there's nothing to do. v2: * Drop code comment, expand commit log instead. (Jonas Ådahl) Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2737 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2967>
db24557e -
Jonas Ådahl authored
This is needed by GNOME Shell to remove itself as a input method implementation during its shutdown sequence. We can't do it ourself later because at mutters own shutdowns equence, the GNOME Shell Javascript context has by that time already been teared down. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2934>
429cc9a6 -
Jonas Ådahl authored
The result of printf("%f", number) depends on the locale. To avoid unpredictable mode IDs, make sure they always are generated the same no matter the locale. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2902>
550a1dad -
Jonas Ådahl authored
This will be used to extract the resolution and refresh rate from strings like "1920x1080@60.0" or "1280x720". This aims to replace the use of the locale dependent sscanf() function. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2902>
2fd9834d -
Jonas Ådahl authored
This fixes issues when the locale uses characters other than `.` in floating point numbers. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2902>
86b5d9d8 -
Daniel van Vugt authored
And report them as warnings instead of crashing. https://launchpad.net/bugs/2014986 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2960>
dd6be7cf -
Robert Mader authored
Just like we do in `toplevel_apply_state()`. Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/2752 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2963>
b56ab367 -
Sebastian Keller authored
It is private and the last caller was removed in 92feea30. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2971>
04fa926e -
Robert Mader authored
If the used EGL backend supports it. In practice this should currently only affect the nested backend. Enabling modifiers can help with app development. An example is `weston-simple-dmabuf-v4l`, which requires the linear modifier to be available. Note that Weston behaves similar already. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2972>
754a1a1c -
Sebastian Wick authored
Just like the HDR Metadata property the Colorspace property values only indicate that the display driver supports signaling certain colorimetry. It does not indidcate that the sink actually supports processing the colorimetry. For this we have to look up the colorimetry support in the EDID. The default colorimetry is always supported. If we want bt.2020 we might get either the RGB or YCC variant even if we ask for the RGB variant but there is nothing we can do about it so let's just pretend it's a driver issue. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2919>
cca07612 -
Carlos Garnacho authored
Going for the default GL renderer is known to trigger rendering artifacts using the NVidia proprietary driver. Since we don't have too many expectatives about frames being flashy (not to the point of mandating GL), resort to the cairo renderer in the mean time. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2976>
57fdd7ef -
Carlos Garnacho authored
This ATM triggers missed .commit events for the window in question, to be addressed in Xwayland. Since the test does not seem to specifically rely on this window being CSD, make it a regular window instead. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2975>
5eb17a36 -
Carlos Garnacho authored
We are attempting to show windows that do not yet have a surface/buffer, this makes GNOME Shell avoid transitions for these windows. Since on Wayland X11 windows are also Wayland surfaces, this check is also valid for these, and is thus made more generic to also cater for these windows. Eventually, meta_window_update_visibility() is called when the surface gets its buffer, so the window can be neatly animated. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2611 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2975>
18be74ed -
Florian Müllner authored
Update NEWS.
28a6447f -
Jeremy Bicha authoredd67e60ee
-
Jeremy Bicha authored
Update to upstream version '44.1' with Debian dir ce61742c355fe05d968a1240ba13a9af64dd1a0c
db31bbad -
Jeremy Bicha authored2a99776f
-
Jeremy Bicha authored21fbbe25
-
Jeremy Bicha authoreda0dae884
-
Gunnar Hjalmarsson authoredf85acbe7
-
8807f0ce
-
Jeremy Bicha authored335ed56e
-
Jeremy Bicha authored
- Add d/p/display-Set-compositor-selection-earlier-on-XWayland.patch LP: #1987976 Gbp-Dch: Full
20f91e9a -
Jeremy Bicha authoredc32857ee
-
Jeremy Bicha authored
tagging package mutter version debian/44.1-1
82fb750f -
Jeremy Bicha authoredfde5e4ed
-
Jeremy Bicha authored
mutter Debian release 44.1-1ubuntu1
e689f6ca -
Jeremy Bicha authored482fed77
-
Jeremy Bicha authored8bccc1c6
-
Jeremy Bicha authorede28a62ff