-
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
Input device settings not applied on hotplug/reconnect/resume in Xorg sessions #14
Comments
We get them when Ubuntu gets them, so shortly after Ubuntu makes a release, there will be a release here too. |
I believe this is the issue that was fixed in #17. |
Yes, this seems like a duplicate of pop-os/gnome-control-center#120 and while Pop 20.04 still has Mutter 3.36.6, the fix for this was backported in the linked PR. Closing for now and we can re-open if this issue is actually something else. |
jackpot51
pushed a commit
that referenced
this issue
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>
jackpot51
pushed a commit
that referenced
this issue
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
I am experiencing the same bug as described here:
https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1899206
where if I unplug and re-plug my external keyboard/mouse the settings don't re-apply.
This seems to have been fixed already in
mutter
's upstream release3.36.8
, so is there any ETA when those changes would be pulled to the Pop!_OS release ofmutter
? Currently runningdpkg -l | grep libmutter-6-0
shows that my up-to-date Pop!_OS 20.10 is running
mutter
version3.36.6
The text was updated successfully, but these errors were encountered: