Using xmodmap prevent awesome from receiving (at least) mod4-combinations for about a second per event

[juhanipaasonen]

Output of awesome --version:

awesome v4.0 (Harder, Better, Faster, Stronger)
• Compiled against Lua 5.3.3 (running with Lua 5.3)
• D-Bus support: ✔
• execinfo support: ✔
• RandR 1.5 support: ✔
• LGI version: 0.9.1

How to reproduce the issue:

Run an xmodmap command, e.g.
$ xmodmap -e "keycode 49 = grave asciitilde dead_tilde dead_caron"

Actual result:

xmodmap returns immediately. For a bit less than a second awesome does not receive (at least) commands sent with mod4, such as mod4+number to switch workspace. The delay increases linearly with the number of events run.

There is a backtrace available.

Expected result:

awesome should receive commands all the time.

[psychon]

Just since no one said so yet: I cannot reproduce this.

For the backtrace: Awesome is handling the event telling it that the keymap changed and now seems to be querying the new keymap from the server (xcb_connection_has_error() cannot block).

[Elv13]

I can reproduce. Here's my (messy) Xmodmap file

(setxkbmap us) +

keycode 118 = exclam Insert
keycode 107 = parenleft
keycode 78 = parenright
keycode 127 = quotedbl
!;#keycode 77 = dollar
!;#keycode 82 = ampersand
!;#keycode 109 = braceright
!;#keycode 117 = braceleft
!;#keycode 116 = greater greater
!;#keycode 113 = less less
keycode 61 = slash question slash question eacute Eacute
keycode 48 = apostrophe quotedbl apostrophe quotedbl egrave Egrave
keycode 35 = bracketright braceright bracketright braceright ccedilla Ccedilla
keycode 51 = backslash bar backslash bar agrave Agrave
keycode 136 = F13
keycode 220 = F14
keycode 209 = F15
keycode 210 = F16
keycode 143 = F17
keycode 153 = XF86AudioNext
keycode 176 = XF86AudioPrev
remove Lock = Caps_Lock

! Move caps lock to use shift to prevent accidental trigger
clear Lock
!keycode 66  = Shift_L Caps_Lock
keycode 66  = F22 Caps_Lock

! Remap the modifier to have a third level on the FN key
!clear      mod1
!clear      mod2
!clear      mod3
!clear      mod4
clear      mod5

!mod5        Mode_switch (0x5d),  ISO_Level3_Shift (0x71),  ISO_Level3_Shift (0x7c)

!add     control = Control_L Control_R
!add        mod1 = Alt_L Alt_R Meta_L
!add        mod2 = Num_Lock
!add        mod3 = Hyper_L
!add        mod4 = Super_L Super_R
add mod5 = Mode_switch
!add        mod5 = ISO_Level3_Shift

!add mod3 = Hyper_R

keycode 151 = F23

!keycode 151 = ISO_Level3_Shift Multi_key ISO_Level3_Shift Multi_key

!keycode 113 mod3 = Left Left Left Left Home Home


! Have the Control_R to Super_R for Radical
keycode 105 = Mode_switch

keycode 112 = Page_Up Page_Up Home Home Home Home
keycode 117 = Page_Down Page_Down End End End End
keycode 90 = Escape

setxkbmap doesn't usually cause issues, but the same problem have been reported with both.

[psychon]

Now, that is extremely useful. The following can be used to reproduce this:

xmodmap <(for x in $(seq 1 1000) ; do echo "keycode 107 = parenleft " ; done)

The above results for me in:

2017-03-15 09:10:19 W: awesome: event_handle_mappingnotify:929: Unexpected MappingNotify of type 1  [ I guess this message repeats a thousand times ]
2017-03-15 09:10:19 W: awesome: a_glib_poll:389: Last main loop iteration took 11.647213 seconds! Increasing limit for this warning to that value.

So... would telling people not to use xmodmap be an option? No? But really, thanks to the XKB extension, xmodmap is obsolete since almost forever? What, you insist? Well...

The issue at hand seems to be that awesome gets a "keyboard config changed" event for every ChangeKeyboardMapping request that xmodmap does. So with my above example, awesome re-queries the keyboard state and re-grabs all keybindings a thousand times.

setxkbmap doesn't usually cause issues, but the same problem have been reported with both.

I don't understand. The first part says "setxkbmap does not cause this problem" while the second part says "setxkbmap also causes this problem".
I'd be much interested in a reproducer with setxkbmap, because these are quite different code paths.

[trou]

I'm bitten by the bug, using Xmodmap, anything to workaround it ?

[psychon]

anything to workaround it ?

As far as I know: Do not use obsolete tools like xmodmap. I have yet to see setxkbmap also causing this. (And yes, I know that xmodmap is so much easier to use than setxkbmap).