summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* 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>
* clutter/backend: Allow unsetting input methodJonas Ådahl2023-04-181-1/+7
| | | | | | | | | 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>
* 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-1711-0/+547
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* clutter/stage-view: Add destroy signalRobert Mader2023-04-171-0/+18
| | | | | | It will be used in the next commit. 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>
* clutter/frame: Add API to query minimal render time of a frameRobert Mader2023-04-174-2/+28
| | | | | | | | | | | | 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>
* 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>
* clutter/stage: Assign frames to paint contextGeorges Basile Stavracas Neto2023-04-071-2/+6
| | | | | | | | 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>
* clutter/paint-context: Allow assigning a ClutterFrameGeorges Basile Stavracas Neto2023-04-073-0/+37
| | | | | | | | | | 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>
* cursor-tracker: Enhance the documentation and increase annotation coverageCorentin Noël2023-04-072-10/+27
| | | | | | | 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>
* frames/content: Use gtk_widget_compute_point()Jonas Ådahl2023-04-051-7/+8
| | | | | | The non-graphene-point variant is deprecated. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2949>
* output-xrandr: Don't treat 0 as invalid backlight valueFlorian Müllner2023-04-041-1/+1
| | | | | | | | 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>
* output-xrandr: Consistently return -1 on errorFlorian Müllner2023-04-041-1/+1
| | | | | | | | | 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>
* x11: Wrap X call with error trapsCarlos Garnacho2023-04-041-0/+7
| | | | | | | | 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>
* x11: Pass Atom directlyCarlos Garnacho2023-04-043-7/+5
| | | | | | | 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>
* frames/window-tracker: Select StructureNotifyMask X11 eventsMarco Trevisan (Treviño)2023-04-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | 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>
* backend: Fix build with -Dremote_desktop=falseChris Mayo2023-04-031-6/+2
| | | | | | | | | | ../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>
View Lorry Controller Status