[Xfce-bugs] [Bug 15032] New: Shortcuts stop working for ~15s when connecting a USB keyboard

[bugzilla-daemon at xfce.org]

https://bugzilla.xfce.org/show_bug.cgi?id=15032

            Bug ID: 15032
           Summary: Shortcuts stop working for ~15s when connecting a USB
                    keyboard
    Classification: Xfce Core
           Product: Libxfce4ui
           Version: git
          Hardware: PC (x86_64)
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Medium
         Component: General
          Assignee: nick at xfce.org
          Reporter: igorkuo at meta.ua
                CC: hjudt at xfce.org, xfce-bugs at xfce.org
  Target Milestone: 4.14

Created attachment 8236
  --> https://bugzilla.xfce.org/attachment.cgi?id=8236&action=edit
Simple workaround for repeating xfce_shortcuts_grabber_keys_changed calls

Whenever I connect an external USB keyboard, xfsettingsd's and Xorg's CPU usage
increases. In GNOME System Monitor xfsettingsd's Status changes from Sleeping
to Running and it takes 1-2% CPU; Xorg's CPU usage jumps from 1-2% to 25%, i.e.
the entire CPU core in my 4-core system. During this high CPU usage time (~15s)
keyboard shortcuts - configured in XFCE settings -> Keyboard -> Application
Shortcuts - don't work.

I have this problem for many months (maybe years) now. A similar
shortcuts-not-working-for-a-time issue happens when resuming from hibernation.
Similar issues were reported:
https://forum.manjaro.org/t/keyboard-shortcuts-stop-working-after-reconnecting-the-usb-keyboard-when-xmodmap-is-present/39482,
https://forum.manjaro.org/t/keyboard-shortucts-stop-working-in-xfce-after-user-switch-resume/35849/9
and on other forums/bug trackers as well. I don't use Xmodmap, but I do have 2
keyboard layouts configured. The issue happens on my Manjaro system with the
packaged versions of XFCE packages as well as with the latest git versions of
libxfce4ui, exo, xfconf and xfce4-settings. The issue does not happen on a
Debian stable (stretch) system with its packaged XFCE versions with similar
configuration (2 layouts).

When I attach to the xfsettingsd process in KDevelop and interrupt it right
after plugging in a USB keyboard, I get
xfce_shortcuts_grabber_keys_changed->...->xfce_shortcuts_grabber_grab in the
frame stack. I made the following change in libxfce4ui's
xfce-shortcuts-grabber.c:
-  TRACE ("Keys changed, regrabbing");
+  DBG ("Keys changed, regrabbing");
The line
"DBG[xfce-shortcuts-grabber.c:168] xfce_shortcuts_grabber_keys_changed(): Keys
changed, regrabbing"
is repeated 50 times in xfsettingsd's output when I launch it like this:
(XFSETTINGSD_DEBUG=1 xfsettingsd --no-daemon --replace &>
/home/igor/Documents/tmp/xfsettingsd-git.log &). The same line is repeated 525
times in the output when I connect an external USB keyboard.

Any ideas why the GDK keys-changed signal is emitted so many times? If it is
not possible to stop GDK from emitting the signal repeatedly, perhaps a
workaround should be implemented in libxfce4ui that handles this signal at most
once each 5 seconds.
For example, store the timestamp of the last call to
xfce_shortcuts_grabber_keys_changed. If the next call happens before 5 seconds
elapse, schedule executing xfce_shortcuts_grabber_keys_changed in 5 seconds
time and return from it immediately. Then return immediately from the future
calls to this function until the 5 seconds pass and
xfce_shortcuts_grabber_keys_changed is called by the 5s-timer.

In fact, even a much simpler workaround - simply ignoring
xfce_shortcuts_grabber_keys_changed calls for 5 seconds after its last full
execution - works for me: the high CPU usage practically disappears, shortcuts
work without interruptions. One downside of the simple workaround is that
without knowing what exactly triggers repeated keys-changed signals, there is a
risk of some configuration loss. Also if genuine configuration changes happen
twice in the course of 5 seconds, the second one won't be handled. The simple
workaround patch is attached to this issue for illustration and experimentation
purposes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.