-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
groovy: Compile with remote desktop support #13
Conversation
It looks like, at least in Gnome Control Center, it still isn't showing up because it also checks for the gsettings schemas added by Don't know if there's a reason Ubuntu is disabling this, or if they just haven't updated it since pipewire has been packaged. |
Okay, remote desktop works, it seems, with a package for If approved, a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does get the screen recorder and remote desktop working (together with pop-os/gnome-shell#47 and the new gnome-remote-desktop
package.)
Does the new |
Since this is approved, I've created a
It definitely shouldn't be a hard dependency, I would say, since Mutter/Gnome Shell seems to be designed to work fine without it. I imagine some people would rather not have remote desktop software installed (since it can be a security concern, though not really if it's disabled). Making it a recommend of pop-desktop may be reasonable. If we want this to work out-of-the-box. |
It looks like Vino was (and still is) a hard dependency of |
Right. Once everything is in the repositories I'll open a pop-desktop PR to remove Vino as a dependency and add gnome-remote-desktop as a recommend. |
The X server generates a property change notification whenever it processes a property change request, even if the value of the property is not changing. This triggers libgdk to probe all display outputs, which can be slow depending on which display driver and hardware are in use. #0 0x00007f8e4d5e91a0 in XRRUpdateConfiguration () at /usr/lib/libXrandr.so.2 #1 0x00007f8e505208da in _gdk_x11_screen_size_changed (screen=0x5566e4b7e080, event=0x7ffe0e44bd60) at ../gdk/x11/gdkscreen-x11.c:1199 #2 0x00007f8e505066d1 in gdk_x11_display_translate_event (translator=0x5566e4b5b110, display=0x5566e4b5b110, event=0x7f8dec001b20, xevent=0x7ffe0e44bd60) at ../gdk/x11/gdkdisplay-x11.c:1201 #3 0x00007f8e505135a0 in _gdk_x11_event_translator_translate (translator=0x5566e4b5b110, display=0x5566e4b5b110, xevent=0x7ffe0e44bd60) at ../gdk/x11/gdkeventtranslator.c:51 #4 0x00007f8e50512c97 in gdk_event_source_translate_event (event_source=0x5566e4b764a0, xevent=0x7ffe0e44bd60) at ../gdk/x11/gdkeventsource.c:243 #5 0x00007f8e50512f57 in _gdk_x11_display_queue_events (display=0x5566e4b5b110) at ../gdk/x11/gdkeventsource.c:341 #6 0x00007f8e50497644 in gdk_display_get_event (display=0x5566e4b5b110) at ../gdk/gdkdisplay.c:442 #7 0x00007f8e5051301f in gdk_event_source_dispatch (source=0x5566e4b764a0, callback=0x0, user_data=0x0) at ../gdk/x11/gdkeventsource.c:363 #8 0x00007f8e516ecf9c in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #9 0x00007f8e51740a49 in () at /usr/lib/libglib-2.0.so.0 #10 0x00007f8e516ec503 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0 #11 0x00007f8e508ef5fd in meta_run_main_loop () at ../src/core/main.c:928 #12 0x00007f8e508ef60e in meta_run () at ../src/core/main.c:943 #13 0x00005566e450842a in () #14 0x00007f8e50649b25 in __libc_start_main () at /usr/lib/libc.so.6 When GNOME is animating a display fade when the night light feature is toggled on or off, it sends a lot of change requests for the CTM property in the process, which triggers a lot of display probes from gdk. In the case of the night light feature, the CTM itself is not actually changing, so these requests are redundant. Fix this by caching the CTM value in the MetaOutputXrandr and skipping the server requests if it's not being changed. Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3978 Signed-off-by: Aaron Plattner <aplattner@nvidia.com> Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1816>
Client connections may linger after the test driver is teared down; handle this gracefully by unsetting the user data on the wl_resource, and make the resource destructor a no-op, instead of where it would otherwise remove itself from the resource list. This fixes this crash seen in CI: Received signal 11 (SIGSEGV) #0 g_list_remove() at ../glib/glist.c:596 #1 test_driver_destructor() at ../src/tests/meta-wayland-test-driver.c:219 #2 destroy_resource() at ../src/wayland-server.c:730 #3 for_each_helper() at ../src/wayland-util.c:416 #4 wl_map_for_each() at ../src/wayland-util.c:430 #5 wl_client_destroy() at ../src/wayland-server.c:889 #6 wl_display_destroy_clients() at ../src/wayland-server.c:1482 #7 meta_wayland_compositor_prepare_shutdown() at ../src/wayland/meta-wayland.c:441 #8 meta_context_dispose() at ../src/core/meta-context.c:667 #9 g_object_unref() at ../gobject/gobject.c:3863 #9 g_object_unref() at ../gobject/gobject.c:3780 #10 glib_autoptr_clear_GObject() at /usr/include/glib-2.0/gobject/gobject-autocleanups.h:29 #10 glib_autoptr_clear_MetaContext() at ../src/meta/meta-context.h:32 #10 glib_autoptr_cleanup_MetaContext() at ../src/meta/meta-context.h:32 #10 main() at ../src/tests/wayland-unit-tests.c:707 #11 __libc_start_call_main() in /usr/lib64/libc.so.6 #12 __libc_start_main() in /usr/lib64/libc.so.6 #13 _start() in /builds/GNOME/mutter/build/src/tests/mutter-wayland-unit Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2601> (cherry picked from commit c7954be56edec947f3b649ce88420214bf9d4961)
If two X11 windows were the last two, we'd remove them from the stack while unmanaging them. That'd hit an assert in meta_stack_tracker_restack_managed(), resulting in the following crash when Xwayland exited unexpectedly with two or more X11 windows being the only windows on the stack: #1 g_assertion_message() at ../glib/gtestutils.c:3256 #2 g_assertion_message_expr() at ../glib/gtestutils.c:3282 #3 meta_stack_tracker_restack_managed() at ../src/core/stack-tracker.c:1210 #4 on_stack_changed() at ../src/core/stack.c:142 #5 _g_closure_invoke_va() at ../gobject/gclosure.c:895 #6 g_signal_emit_valist() at ../gobject/gsignal.c:3456 #7 g_signal_emit() at ../gobject/gsignal.c:3606 #8 meta_stack_changed() at ../src/core/stack.c:265 #9 meta_stack_remove() at ../src/core/stack.c:324 #10 meta_window_unmanage() at ../src/core/window.c:1542 #11 meta_x11_display_unmanage_windows() at ../src/x11/meta-x11-display.c:111 #12 meta_x11_display_dispose() at ../src/x11/meta-x11-display.c:141 #13 g_object_run_dispose() at ../gobject/gobject.c:1448 #14 meta_display_shutdown_x11() at ../src/core/display.c:831 The added test specifically checks that this scenario is handled gracefully. Related: https://bugzilla.redhat.com/show_bug.cgi?id=2143637 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2704>
This seems to be required for both remote desktop and screencasting. With it,
org.gnome.Mutter.ScreenCast
andorg.gnome.Mutter.RemoteDesktop
show up over DBus, but I'm not seeing either feature working...