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

Input device settings not applied on hotplug/reconnect/resume in Xorg sessions #14

Closed
Jonesus opened this issue Nov 20, 2020 · 3 comments

Comments

@Jonesus
Copy link

Jonesus commented Nov 20, 2020

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 release 3.36.8, so is there any ETA when those changes would be pulled to the Pop!_OS release of mutter? Currently running
dpkg -l | grep libmutter-6-0
shows that my up-to-date Pop!_OS 20.10 is running mutter version 3.36.6

@mmstick
Copy link
Member

mmstick commented Nov 20, 2020

We get them when Ubuntu gets them, so shortly after Ubuntu makes a release, there will be a release here too.

@ids1024
Copy link
Member

ids1024 commented Jan 25, 2021

I believe this is the issue that was fixed in #17.

@jacobgkau
Copy link
Member

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants