Skip to content
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

Merged
merged 1 commit into from
Nov 3, 2020

Conversation

ids1024
Copy link
Member

@ids1024 ids1024 commented Nov 2, 2020

This seems to be required for both remote desktop and screencasting. With it, org.gnome.Mutter.ScreenCast and org.gnome.Mutter.RemoteDesktop show up over DBus, but I'm not seeing either feature working...

@ids1024
Copy link
Member Author

ids1024 commented Nov 2, 2020

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 gnome-remote-desktop. That package isn't currently in the Ubuntu groovy archives (probably because mutter isn't being built with the support).

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.

@ids1024 ids1024 marked this pull request as ready for review November 2, 2020 21:57
@ids1024
Copy link
Member Author

ids1024 commented Nov 2, 2020

Okay, remote desktop works, it seems, with a package for gnome-remote-desktop: https://github.com/pop-os/gnome-remote-desktop

If approved, a master_groovy branch should be added to gnome-remote-desktop.

Copy link
Member

@jacobgkau jacobgkau left a 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.)

@jacobgkau
Copy link
Member

Does the new gnome-remote-desktop package need to be a dependency (or recommends) on anything? If not any of the GNOME packages, then possibly pop-desktop?

@jackpot51 jackpot51 merged commit cd569c1 into master_groovy Nov 3, 2020
@jackpot51 jackpot51 deleted the remote-desktop_groovy branch November 3, 2020 16:11
@ids1024
Copy link
Member Author

ids1024 commented Nov 3, 2020

Since this is approved, I've created a master_groovy branch for gnome-remote-desktop.

Does the new gnome-remote-desktop package need to be a dependency (or recommends) on anything?

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.

@jacobgkau
Copy link
Member

jacobgkau commented Nov 3, 2020

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 pop-desktop. I'd be fine with gnome-remote-desktop being a recommends, it's nice to have out-of-the-box but some people do like to uninstall everything possible. We may also want to remove vino from depends if it's no longer used for anything (it looks like its repository on GNOME's GitLab server has been archived.)

@ids1024
Copy link
Member Author

ids1024 commented Nov 3, 2020

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.

jackpot51 pushed a commit that referenced this pull request Aug 9, 2021
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>
mmstick pushed a commit that referenced this pull request Jan 31, 2023
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)
jackpot51 pushed a commit that referenced this pull request Sep 6, 2023
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants