-
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: Enable x11-Add-support-for-fractional-scaling-using-Randr.patch #12
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
leviport
approved these changes
Oct 21, 2020
jackpot51
approved these changes
Oct 21, 2020
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Meant to address #11.