summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* tests/test-client: Ensure that screen has always a compositorgnome-44Marco Trevisan (Treviño)2023-05-151-0/+2
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2970>
* tests: Add check for compositor state on XWayland startupMarco Trevisan (Treviño)2023-05-153-1/+129
| | | | | | | Check that the first X11 window started has a compositor defined. See: https://gitlab.gnome.org/GNOME/mutter/-/issues/2472#note_1582262 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2970>
* tests/meson: Make tests depending on test-client to actually depend on itMarco Trevisan (Treviño)2023-05-151-0/+6
| | | | | | It allows meson to rebuild the client-related sources when a single test is running using the client, also ensuring that test-run dependencies are correctly setup
* x11/x11-display: Set compositor selection earlier on XWaylandMarco Trevisan (Treviño)2023-05-154-6/+28
| | | | | | | | | | | | | | | When the X11 display is actually XWayland there's no point to delay the compositor selection, given that mutter itself is the compositor and doing this may cause the first X11 client that starts not to receive the right information (and in some cases misbehave). Since some toolkits are not handling the compositor selection changes properly at later times, let's make their life easier by just initializing the selection as early as the other X11 properties, given that in this case there's nothing to replace. Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2472 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2970>
* wayland/surface: NULL check surface resource in handle_output_bound()Jonas Ådahl2023-05-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | Otherwise binding new wl_output's might try to send enter to the destroyed resource. Fixes the following crash: #0 wl_resource_get_client at ../src/wayland-server.c:801 #1 handle_output_bound at ../src/wayland/meta-wayland-surface.c:1287 #3 signal_emit_unlocked_R.isra.0 at ../gobject/gsignal.c:3812 #6 ffi_call_unix64 at ../src/x86/unix64.S:104 #7 ffi_call_int at ../src/x86/ffi64.c:673 #8 ffi_call at ../src/x86/ffi64.c:710 #9 wl_closure_invoke at ../src/connection.c:1025 #10 wl_client_connection_data at ../src/wayland-server.c:438 #11 wl_event_loop_dispatch at ../src/event-loop.c:1027 #12 wayland_event_source_dispatch at ../src/wayland/meta-wayland.c:125 #15 g_main_context_iterate.isra.0 at ../glib/gmain.c:4276 #17 meta_context_run_main_loop at ../src/core/meta-context.c:482 Related: https://bugzilla.redhat.com/show_bug.cgi?id=2196527 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2992> (cherry picked from commit 1a4f03bd79a2ba502dbd6a932ec20a73921d6709)
* compositor-view: Chain up finalize()Jonas Ådahl2023-05-091-0/+2
| | | | | | | | The chaining up to the GObject finalize() method was missing, fix that. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2991> (cherry picked from commit 802c1baec742f467ab2da9a9c6f648dc4d921d69)
* screen-cast/src: Never dequeue pw_buffer's we refuse to record toJonas Ådahl2023-05-043-18/+32
| | | | | | | | | | | | | | | | | | | The DMA buffer paths vs MemFd paths differ slightly in when content is recorded. This was in some places done by trying to record but bail if the dequeued buffer had the wrong type. This is problematic for two reasons: we'd update the timestamp even if we refused to record, making the follow-up attempt fail, and we'd dequeue and queue buffers that didn't get any content, meaning the receiving end would see empty buffers potentially with only cursor updates. Fix this by keeping track if a stream is DMA buffer able or not, and don't attempt to record at all in the places we would previously require DMA buffers. This avoids both issues: we don't dequeue/queue pw_buffers that we refuse to record to, and we won't update the recorded timestamp when we didn't intend to record to begin with. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2783 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2987>
* frames: Disable XDND support on the frame windowSebastian Keller2023-05-031-0/+8
| | | | | | | | | | | | | | All X11 surfaces created by gtk4 claim to support XDND via the XdndAware property. This was leading some clients, e.g. Qt, to consider the frame window as drop target instead of the client window. Avoid this issue by removing the XdndAware property again after gtk has created the surface. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2715 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2978> (cherry picked from commit d643eb5c6fe50e7f1afffda0e8747a87f668a799)
* core: Fix map transitions for X11 windows on WaylandCarlos Garnacho2023-04-251-2/+2
| | | | | | | | | | | | | | | | | 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>
* tests: Avoid CSD window in testCarlos Garnacho2023-04-251-1/+1
| | | | | | | | 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>
* frames: Use cairo renderer on GTK framesCarlos Garnacho2023-04-241-0/+2
| | | | | | | | | 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>
* output: Check the EDID for the supported sink ColorimetrySebastian Wick2023-04-213-10/+45
| | | | | | | | | | | | | | | 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>
* wayland/dma-buf: Enable modifiers by default on non-native backendRobert Mader2023-04-201-1/+14
| | | | | | | | | | | | | 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>
* core: Remove meta_frame_get_flags()Sebastian Keller2023-04-202-66/+0
| | | | | | It is private and the last caller was removed in 92feea30. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2971>
* xdg-shell: Always handle frame callbacks in popup_apply_state()Robert Mader2023-04-201-1/+4
| | | | | | | | 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>
* backends/x11: Trap errors from XIChangePropertyDaniel van Vugt2023-04-181-0/+12
| | | | | | | | And report them as warnings instead of crashing. https://launchpad.net/bugs/2014986 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2960>
* Replace using sscanf() to parse mode strings with new helperJonas Ådahl2023-04-182-10/+5
| | | | | | | 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>
* monitor: Add helper to parse simple mode stringsJonas Ådahl2023-04-183-0/+135
| | | | | | | | 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>
* monitor: Don't use locale dependent mode ID stringJonas Ådahl2023-04-181-2/+5
| | | | | | | | 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>
* wayland/xdg-shell: Bail from popup_configure if resource was destroyedMichel Dänzer2023-04-181-0/+3
| | | | | | | | | | | | | 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>
* wayland/cursor-surface: Update cursor on disposeJonas Ådahl2023-04-1710-0/+546
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cursor-tracker: Don't leak window cursor on exitJonas Ådahl2023-04-171-0/+1
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2968>
* wayland: Emit frame events in GSource after "empty" updatesRobert Mader2023-04-171-38/+208
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* frame/native: Remember whether the frame carried a kms updateRobert Mader2023-04-172-0/+12
| | | | | | So that information is available in e.g. after_update handlers. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2823>
* x11: Always initialize all fields of XEvents sent via XSendEventSebastian Keller2023-04-174-5/+5
| | | | | | | | 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>
* workspace: Only consider windows that should be showing as focusableSebastian Keller2023-04-163-7/+17
| | | | | | | | | | | | | | | 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: 399429742 ("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>
* wayland: Set compositor when creating MetaWaylandDataSourceXWaylandSebastian Keller2023-04-152-9/+77
| | | | | | | | | | | | | 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: 2731f0cda ("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>
* wayland/data-device: Clear data source when cancelling drag with ESCmsizanoen12023-04-151-1/+3
| | | | | | | 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>
* dnd: Clear Wayland drag source when cancelled from stage grab contextmsizanoen12023-04-151-0/+2
| | | | | | | | | | | 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>
* frames: Forward _NET_WM_STATE during frame initializationCarlos Garnacho2023-04-141-5/+48
| | | | | | | | | | | | | | | | | 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>
* x11: Fix remaining leaks from switch to XGetAtomName()Sebastian Keller2023-04-142-2/+5
| | | | | | | | 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: e66f4396e ("x11: Avoid GDK API in X11 selections") Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2957>
* x11: Use Atoms when constructing a new MetaX11SelectionOutputStreamSebastian Keller2023-04-143-21/+24
| | | | | | | | | 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: e66f4396e ("x11: Avoid GDK API in X11 selections") Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2957>
* x11: Remove unused member variables from MetaX11SelectionInputStreamSebastian Keller2023-04-143-24/+5
| | | | | | | | | | 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: e66f4396e ("x11: Avoid GDK API in X11 selections") Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2957>
* wayland: Don't leak XDnD mime type stringsSebastian Keller2023-04-141-2/+4
| | | | | | | | 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: 014cde646 ("wayland: Do not use GDK functions on XDnD implementation") Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2957>
* xdg-shell: Early out of apply if dismissedJonas Ådahl2023-04-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* wayland/xdg-shell: Dismiss instead of destroy invalid popupJonas Ådahl2023-04-131-1/+1
| | | | | | | | | 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>
* wayland/xdg-shell: Ignore reposition if popup was dismissedJonas Ådahl2023-04-131-0/+3
| | | | | | | | | 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>
* core: Create passive button grab on topmost WindowCarlos Garnacho2023-04-121-1/+4
| | | | | | | | | | | | | | | | 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>
* core: Pass MetaWindow on passive button grab machineryCarlos Garnacho2023-04-124-22/+27
| | | | | | | | 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>
* core: Minor refactorCarlos Garnacho2023-04-121-6/+8
| | | | | | Do not make code live before variable declarations. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2954>
* screen-cast/monitor-src: Record frames with presentation timeGeorges Basile Stavracas Neto2023-04-071-4/+17
| | | | | | | | | 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>
* screen-cast/monitor-src: Record DMA-BUF frames immediatelyGeorges Basile Stavracas Neto2023-04-071-4/+14
| | | | | | | | 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>
* screen-cast/src: Shuffle a variable aroundGeorges Basile Stavracas Neto2023-04-071-1/+2
| | | | | | | 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>
* screen-cast/src: Clean up DMA-BUF only error pathsGeorges Basile Stavracas Neto2023-04-071-1/+5
| | | | | | | | | | | 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>
* screen-cast/src: Add frame recording variant with timestampGeorges Basile Stavracas Neto2023-04-072-18/+48
| | | | | | | | | | | | 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>
* backends/stage: Pass ClutterFrame to MetaStageWatchFuncGeorges Basile Stavracas Neto2023-04-076-5/+15
| | | | | | | 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>
* cursor-tracker: Enhance the documentation and increase annotation coverageCorentin Noël2023-04-071-10/+16
| | | | | | | 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>
* screen-cast-stream-src: Export damaged video regionsSalman2023-04-066-17/+126
| | | | | | | | | 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>
* screen-cast-stream-src: Minor adjustmentSalman2023-04-061-4/+5
| | | | | | This change makes it easier to add/remove stream params during test/dev. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2775>
* stage-impl: Do clipped redraws when drawing offscreenSalman2023-04-061-21/+51
| | | | | | | | | | | | | 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>
View Lorry Controller Status