Desktop briefly becomes unresponsive when receiving a keypress from a different device/mapping than the last keypress (in Xorg)

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1777708/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

> It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it

Sure! But I have no qualified guess.

I did some additional testing today, which may be helpful to others, but confused me a bit more:

I installed Plasma, and here the problem doesn't seem to be there. It feels like there's a slight delay when typing a lot of things at the same time, but it might just be Plasma's way of working. I haven't used it before, so I can't really say whether the slight delay is just how things work or is related to this issue.

But I also found out that I'm able to start a Wayland based Gnome session. Doing that, there's absolutely no problem with they keyboard. All multi-keyboard typing is shown instantly and no UI freeezing.

Based on this, I'm a bit confused about what package to file this bug against, as Plasma (as far as I know) runs on top of X, and Gnome works fine without X.

I'm glad I found this, because it affects me too. I have the Same problem in gnome, but the problem is not present in plasma. I tried gnome with other OS and the bug didn't occur either.

It is very annoying and I could not find a workaround.

Status changed to 'Confirmed' because the bug affects multiple users.

This bug can be easily triggered by typing with two keyboards, Everytime you switch from one keyboard to the other, there is a lag. If you type fast enough you can even freeze the application. Other way to trigger this bug is to use xbindkeys with xautomation, everytime i try to simulate keyboard typing, the lag is there.

It happens with XOrg and Gnome, doesnt happen in wayland. The problem is i cant use wayland with NVidia driver.

Same happens to me.

Now that other have marked themselves as affected, I'm trying to add a package, hoping that it will increase the chance that someone will look into it, although I'm not sure this is a Gnome bug (as mentioned earlier).

After being annoyed by this bug for a long time, i started digging and found a workaround. Today i found that the bug is only present when i'm using certain keyboard layouts ("Portugues (Brasil)") and was not present when i changed the layout to EUA and language to English (need to set them both to English).

After some digging i found out the culprit is the ScrollLock key and that can be fixed by editing the layout file, which in my case is found at /usr/share/X11/xkb/symbols/br. The only modification i did was to remove or comment the line: modifier_map Mod3 { Scroll_Lock };
After that, set the language and layout back to Portugues (Brasil) and the problem was gone!

No more delays between typings.

PS: I tried this on Fedora, i will try this on ubuntu tomorrow.

The only problem is the scroll lock key is no longer useful, but i dont use it, anyway.

PS: The keyboard layout which the bug is not present is US and not EUA like i said.

Interesting findings, Pedro. How did you come up with that? What led you in this direction? Did you have a change to try this in Ubuntu yet?

However, this fix doesn't work for me. Switching from Danish layout to English does not get rid of the lag (I tried both US and UK English layouts; don't know if there's a difference).

Did you set the language to English as well? I've tried in Ubuntu and it worked as well.

BUT I just found out that my solution may not solve your problem. Although it removes the lag between keypresses, if you type two keys at the same type (which happens when you type too fast), there is a small lag. In my case, i don't see any problem, because the secondary keyboard is for a very specific use.

Also, i looked at /usr/share/X11/xkb/symbols/dk file, and looks like the Scroll Lock isn't mapped there.

>Did you set the language to English as well?

Yes, I always use the English interface, if that is what you mean.

> if you type two keys at the same type (which happens when you type too fast) (...)

So, if you're hammering away on the keyboards at the same time, do you still get the freeze, even with your fix? (Please, test it!)

> i looked at /usr/share/X11/xkb/symbols/dk file, and looks like the Scroll Lock isn't mapped there.

Right. It may inherit it from some of the other, more general layout files, though. But still:_ Switching to English layout didn't work for me either.

> So, if you're hammering away on the keyboards at the same time, do you still get the freeze, even with your fix? (Please, test it!)

Yes, the fix i did solved the lag everytime i switched keyboards. The problem is a small lag still happen if i hit the two keyboards at the same time. As i only type on one keyboard at a time, it doesn't bother me, but it will prabably bother you.

I realized if i set the layout "Portugues (Brasil)" without patching the file, the problem is even worse.

I have exactly the same problem with an R-go split keyboard. Makes Ubuntu basically unusable unfortunately. Changing the keyboard layout doesn't help anything.

> I have exactly the same problem with an R-go split keyboard

Great to see some confirmations!

For anyone skimming the comments, I'd like to emphasise that this is _not_ an R-Go specific issue. It can be reproduced by typing on any 2 connected keyboards at the same time. So it's a more general problem, which just happens to manifest itself for users of the R-Go keyboard(s).

I too have issues with keyboard input lag on Ubuntu 18.04. I've made sure I'm current on all updates, I'm using the US layout and my language is set to English.

In my case I am using a KeyMouse Track (which the OS recognizes as two separate keyboards) but I have confirmed that it isn't related to the keyboard devices - two Logitech G810 keyboards plugged in simultaneously exhibit the same behavior.

As others have described, there is significant lag when pressing keys from two keyboards in an alternating fashion, and the faster you press the keys, the longer the delay before anything shows up on-screen once you stop typing. If only keys from one device are pressed, there is no discernible lag even if both keyboards are still plugged in.

Hopefully we can get some traction on this. I don't think Wayland is a viable option for me as I have an nVidia graphics card and I also have to use Skype for work... and I don't really want to switch to Plasma either.

To anyone responding to this issue because it also affects them: Remember to click "This bug affects me" at the top of this page, to increase the likelihood that somebody will dig into the problem some day. Thanks! :)

I don't think that will be addressed soon (or at all). Has anyone found a working workaround yet?

Dominik, unfortunately not something that doesn't involve replacing Xorg or Gnome. Maybe it's been unintentionally fixed in 18.10, but I haven't had the time to try the beta.

I just upgraded from 18.04 to 18.10, and the problem is still there for me.

I bought a Logitech K840 mechanical keyboard couple days back I noticed the lag in 18.04 and 18.10 if I press a lot of keys at the same time. And I've verified that it only happens in GNOME. I haven't tried it in Wayland though. I didn't notice this issue with my previous bluetooth keyboard.

I have the same problem on 18.04. The trick mentioned above with removing scroll lock and changing input language seemed to make the delay smaller but still quite annoying. I am typing this in a Wayland session now and have 0 delay!

Same problem here. When I run htop while reproducing this bug, I can tell that shortly after the freeze, this command is using over 90 % CPU:

/usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3

Maybe this helps to find the cause for this bug:

When I run `xev -event keyboard` and press some keys, I see a KeyPress and a KeyRelease event for every key. When I press a key on another keyboard, I see a MappingNotify event first and then a KeyPress and a KeyRelease event:

KeyPress event, serial 28, synthetic NO, window 0x6800001,
    root 0x1a9, subw 0x0, time 1560057, (183,63), root:(1054,989),
    state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XmbLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x6800001,
    root 0x1a9, subw 0x0, time 1560169, (183,63), root:(1054,989),
    state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

# now typing on another keyboard

MappingNotify event, serial 28, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

KeyPress event, serial 28, synthetic NO, window 0x6800001,
    root 0x1a9, subw 0x0, time 1562201, (183,63), root:(1054,989),
    state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XmbLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x6800001,
    root 0x1a9, subw 0x0, time 1562329, (183,63), root:(1054,989),
    state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

Maybe this MappingNotify event triggers something in Gnome that needs a second of processor time.

I have the same issue, but when using 1 keyboard and the xdotool. I use xdotool to input keypress like XF86AudioPlay, and others multimedia keys. This only happen when using the gnome. In wayland there is no such issue. The real keyboard does not have the multimedia keys. The system became shortly unresponsive everytime I switch from the real keyboard to the xdotool media keys, and vice versa.

This issue looks similar to this issue in Debian:
https://gitlab.gnome.org/GNOME/gnome-shell/issues/856

and I understand is has already been fixed with this patch, although I don't know how to use it :
https://gitlab.gnome.org/GNOME/mutter/merge_requests/579

I've bought a KeyMouse split keyboard and cannot use it because of this delay. Their support is aware of this issue but do not want to help fixing. https://www.keymouse.com/forum/large-lag-between-keystroke-and-response

If it is fixed in Gnome mutter, does it mean it will be available in Ubuntu 19.10?
Or is it possible to update just mutter on Ubuntu 18.04?

Thanks.

This issue is not fixed in Ubuntu 19.10 (at least as of today). To reiterate this issue isn't present in Wayland, only Xorg. Also this issue was present for me in Kubuntu 19.10, but not in Ubuntu Mate or Xubuntu 19.10.

Actually this issue *is* affecting Ubuntu Mate 19.10, it's just not as noticeable but definitely there.

This issue was fixed in Ubuntu 19.10. I switched from 18.04 to Eoan on 2th September and the bug was gone. Unfortunately one month later, somewhere around the beginning of October I upgraded my 19.10 system and the bug was present again. Awesome! :D

Since I am a newboy to Linux I dont know ho to roll back this upgrade and as far as I got it, its not that easy to downgrade gnome while wont touching the other packages. When somebody knows how to do this, pls go ahead.

I know nothing about Linux/Ubuntu and how it works, but I'm also having this issue, with a R-Go split keyboard. I find it very cool that one can use 'xev -event keyboard` to get an idea of what's happening behind the curtain. And it made me research. According to this link: https://tronche.com/gui/x/xlib/events/window-state-change/mapping.html --- the MappingKeyboard appears, when the keyboard mapping was changed.. Which, without knowing anything about how this works, leads me to believe that something, somewhere, either believes the keyboards to be of two different mappings, or something is forcing them to be of two different mappings.

Maybe, if one manually sets the mapping of both keyboards, to be exactly the same? I tried 'xinput -list | grep key' together with 'setxkbmap -device [number] -layout [layout]' to try and force the dansh layout on both keyboarsd, but without avail. Any ideas?

Upstream bug: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1858

One guy (Wiggy boy <Lindholm> Wiggy boy <Lindholm>) found a fix:

from:

https://gitlab.gnome.org/GNOME/gnome-shell/issues/1858

I'm trying out some stuff on Ubuntu 19.10 right now actually.
If you wanna help me or guide me I'd be more than happy to receive your help.
Send me an email REMOVED .
EDIT:
I think I've got this working actually. So I thought it'd be writing down in case someone else comes around wanting to duplicate it (perhaps those over at the Ubuntu Bug Report Forums). Be aware though, I JUST have it working now and have no idea if something will break later down the line. I bricked my Ubuntu installation twice trying to get it to work.
So I'm running Ubuntu 19.10 now, for this to work any older version will not work (at least not with this method).
So currently 19.10 is running gnome-shell 3.34.1 and we'll need to downgrade to 3.34.0 as this includes the fix, before it was reverted. Unfortunately the compiled packages have been removed so we'll have to download and install them manually and figure out the dependencies so things don't break.
Luckily however, Launchpad has some built packages, so we'll need to download for mutter:

gir1.2-mutter-5_3.34.0-3ubuntu1_amd64.deb
libmutter-5-0_3.34.0-3ubuntu1_amd64.deb
mutter-common_3.34.0-3ubuntu1_all.deb
mutter_3.34.0-3ubuntu1_amd64.deb

and for gnome-shell:

gnome-shell-common_3.34.0-1ubuntu1_all.deb
gnome-shell_3.34.0-1ubuntu1_amd64.deb

If the direct links doesn't work, here's where I found all the dpkg files, or if you're not running amd64 architecture, you should also be able to find alternatives:

mutter-3.34.0-3ubuntu1
gnome-shell-3.34.0-1ubuntu1

So, once you've got all the files you need. Open the terminal and the following command to exit the desktop enviroment (I don't know if this is needed but why not?):
sudo init 3
Then install each and everyone of your dpkg files with sudo dpkg -i /path/to/deb/file like so:
sudo dpkg -i gir1.2-mutter-5_3.34.0-3ubuntu1_amd64.deb
sudo dpkg -i libmutter-5-0_3.34.0-3ubuntu1_amd64.deb
sudo dpkg -i mutter-common_3.34.0-3ubuntu1_all.deb
sudo dpkg -i mutter_3.34.0-3ubuntu1_amd64.deb
sudo dpkg -i gnome-shell-common_3.34.0-1ubuntu1_all.deb
sudo dpkg -i gnome-shell_3.34.0-1ubuntu1_amd64.deb
Do not worry if it complains or warns about missing dependencies or breaking dependencies. This is because you have a newer version installed, and we're replacing them one by one.
Once finished, we start the desktop environment again with:
sudo init 5
Finally, we wanna let APT know not to update these packages, because that would undo everything. We do that by running following:
sudo apt-mark hold gir1.2-mutter-5
sudo apt-mark hold libmutter-5-0
sudo apt-mark hold mutter-common
sudo apt-mark hold mutter
sudo apt-mark hold gnome-shell-common
sudo apt-mark hold gnome-shell
Now you're done!
Once everything has been fixed and maybe you do want to upgrade all your versions, just run the previous commands but substitute hold with unhold. That should tell APT that it's okay to upgrade those packages again.

works also without the init command

Please use this Wiki-report at https://askubuntu.com/a/1195394/439867 with more details and evidences abiut this bug. Please more attention here, it affects many testimony and thousands of pageviews in the report's page.

I've the same issue in 19.10. Since I use Portuguese Brazil layout, I was able to circumvent this problem using the Pedro Palhares (Post #8) suggestion.

I'm having the same problem in Ubuntu 20.04 in XPS L502x.
I frequently use my laptop pluged in a external keyboard and mouse (logitech K270)

Thank you.

This problem also affects me. I used the method of downgrading and it really worked. However, I don't know what I'm gonna miss out because of that downgrade.

I also discovered a problem that only exists using a splitted keyboard: For logging in to Ubuntu, the shift keys don't work.

I've created a $50 bounty: https://www.bountysource.com/issues/91397439
Please, support and spread the word for those who can help to fix this issue.

In addition to the two-keyboards thing, I'm also experiencing this problem using the Sidewinder X4 keyboard when holding more than 6 simultaneous keys. According to xev, this keyboard also sends MappingNotify events when it gets to that point.

For anyone looking for some closure, I doubt you'll see a fix for this anytime soon. So the best I can offer to you all is a little hack/fix you can do yourself. You can find it in the upstream bug over at gitlab.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1858#note_818548

Best of luck to you all!

I just bought the R GO Split keyboard and experiencing the same issue on Ubuntu 20.04. Very unfortunate that it hasn't been solved yet.

I have a Drevo BM87, running on Ubuntu 20.04, and the problem prevails.... I hope the issue can be fixed soon, because otherwise it renders the external keyboards pretty much useless.

Is there another way to report this bug since it was opened quite long ago?

The #33 advice works on "19.10" but not on "20.04" bringing the system into "oh, no"-state.

Have the people on 20.04 tried #41 ?

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1858#note_818548
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1858#note_857572

I am using 20.04 & used this Workaround to fix it. Input lag is gone.

Had Found this because [https://github.com/federico-terzi/espanso/] severely froze my desktop when expanding text snippets.
Disabling Scroll lock did solve it.

Using Pop!_OS 20.04 LTS.

I'm using Ubuntu 20.04, and fixed this issue with the workaround by Wiggy boy <Lindholm> (Thanks!):
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1858#note_818548
(and I also had to enable the "Source code" source as explained here: https://askubuntu.com/questions/496549/error-you-must-put-some-source-uris-in-your-sources-list/857433#857433)

This bug was a bummer to find after switching to Gnome/Ubuntu (from Xfce, a bit older version though) mostly because of the feelingly lower input lag in the mouse. So having also gaming in mind, it was a bummer to find out that the keyboard and the extra buttons on the mouse don't work reasonably anymore without freezing with 100 % CPU :/

If the only drawback of this workaround affects keyboards other than qwerty, please at least have a configurable option in settings to disable other than qwerties and have a functional keyboard?

I use Ubuntu 20.04 and I have the same problem.

A similar bug I reported here:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1895486

After some use, I noticed a delay when using keyboard media controls (for example: increase volume audio).

The first time I push these key Gnome hangs for a short time before display the action on the screen.

(This problem is still happening in Ubuntu 18.04 too. Even worse some times, the system crashes when using media keys.)

For some reason, my Gnome freezes when using Fn keys, or when I try to use two keyboards. A friend of mine pointed to me that it occurs when switching to a keyboard layout that has Scroll Lock enabled, so I disabled it in the X11 keyboard layout file for my language, and it solved the problem.

A workaround to solve the problem is:

1) Opened the keyboard layout file for my language, in my case:

sudo nano /usr/share/X11/xkb/symbols/br

2) Commented the line:

modifier_map Mod3 { Scroll_Lock };

3) Logged out and logged in again or run command setxkbmap.

These steps are specific for the Brazilian Portuguese ABNT2 Layout and may not work for other layouts, but it can help you find a similar solution.

Same issue here with R-Go split
Interestingly I found one configuration that works, but horribly breaks other things:

first, have a look with xinput

$ xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
...
⎜ ↳ Hantick USB Keyboard Consumer Control id=20 [slave pointer (2)]
⎜ ↳ HID 0911:2188 Consumer Control id=22 [slave pointer (2)]
⎜ ↳ HID 0911:2188 Mouse id=24 [slave pointer (2)]
⎜ ↳ Hantick USB Keyboard Mouse id=25 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
    ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
...
    ↳ Hantick USB Keyboard id=16 [slave keyboard (3)]
    ↳ HID 0911:2188 System Control id=17 [slave keyboard (3)]
    ↳ HID 0911:2188 id=18 [slave keyboard (3)]
    ↳ Hantick USB Keyboard System Control id=19 [slave keyboard (3)]
    ↳ Hantick USB Keyboard Consumer Control id=21 [slave keyboard (3)]
    ↳ HID 0911:2188 Consumer Control id=23 [slave keyboard (3)]
    ↳ Hantick USB Keyboard Wireless Radio Control id=26 [slave keyboard (3)]

The Hantick devices as well as the 0911:2188 devices are the R-Go Split (why so many?)
interestingly there is a wireless radio control???
Anyway, let's create a new group

$ xinput create-master rgosplit 0
$ xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
...
⎡ rgosplit pointer id=27 [master pointer (28)]
⎜ ↳ rgosplit XTEST pointer id=29 [slave pointer (27)]
⎣ rgosplit keyboard id=28 [master keyboard (27)]
    ↳ rgosplit XTEST keyboard id=30 [slave keyboard (28)]

and now add those 0911:2188 keyboard devices to it (note that you need to replace the numbers in the commands)

$ xinput reattach 17 28
$ xinput reattach 18 28
$ xinput reattach 23 28
$ xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
...
⎜ ↳ Hantick USB Keyboard Consumer Control id=20 [slave pointer (2)]
⎜ ↳ HID 0911:2188 Consumer Control id=22 [slave pointer (2)]
⎜ ↳ HID 0911:2188 Mouse id=24 [slave pointer (2)]
⎜ ↳ Hantick USB Keyboard Mouse id=25 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
    ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
...
    ↳ Hantick USB Keyboard id=16 [slave keyboard (3)]
    ↳ Hantick USB Keyboard System Control id=19 [slave keyboard (3)]
    ↳ Hantick USB Keyboard Consumer Control id=21 [slave keyboard (3)]
    ↳ Hantick USB Keyboard Wireless Radio Control id=26 [slave keyboard (3)]
⎡ rgosplit pointer id=27 [master pointer (28)]
⎜ ↳ rgosplit XTEST pointer id=29 [slave pointer (27)]
⎣ rgosplit keyboard id=28 [master keyboard (27)]
    ↳ HID 0911:...

After updating to Ubuntu 20.10 the problem is back.
Brazilian ABNT2 keyboard layout.

Commenting the modifier line is not a valid workaround anymore.
// modifier_map Mod3 { Scroll_Lock };

In my case the problem was the Discord app. When it's open I get severe input lag (kb/mouse) on Chrome and other apps.

Don't know if it's the same bug as reported here but the symptoms match.

That's concerning. What if you open the Extensions app and disable 'Ubuntu AppIndicators'?

@vanvugt thanks for the tip.
Since disabling Ubuntu AppIndicators I didn't experience the problem.

I have updated to 20.10 and can confirm disabling scroll lock workaround is still working.

Another thing i've just realized is without this hack, there is a huge lag during lock/unlock/login animations. Commenting scroll lock line in /usr/share/X11/xkb/symbols/br made animations a lot better.

Nicolas,

If disabling 'Ubuntu AppIndicators' worked for you then it was probably bug 1849142. Please go to bug 1849142 and help to test the proposed fix for that.

Hey there, thanks for the discussion, it's helped me find a way around this problem.

I also use an R-Go split keyboard. I had the input lag issue OS-wide on Elementary OS and Pop OS. The issue disappears on Wayland.

After switching to Regolith, which uses gnome-flashback, the issue is no longer there. There is one big exception, though: there's still the same problem on Firefox! All other apps are doing just fine.

I wonder whether I can somehow overcome the problem on Firefox as well. I'm no longer sure whether it's a problem in the interaction between Firefox and Xorg or it's a Firefox-specific problem.

On the Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1640535

> There is now quite a lot of input delay. Touch-typists typing with one hand on each keyboard will easily out-pace Firefox's ability to display what they are typing. The problem persists until Firefox is restarted.

That is exactly what's happening to me, and it looks like it's their bug. Sorry about that!

Hi :)

I also have the R-Go Tools Split keyboard and is having the exact same issue no Ubuntu 20.04. I also had the same issue on Ubuntu 18.04.

But I found a way to fix it. If I change the display server from X11/Xorg to Wayland then the problem goes away! :D I just followed this guide:

  https://linuxconfig.org/how-to-enable-disable-wayland-on-ubuntu-20-04-desktop?fbclid=IwAR1yAApu1CItCAnngvHbZgCta1WzY718qk8dqdRXJdVkclm-_xWbOFDGmAw

So my suspection is that this is a problem with the default display server in Ubuntu.

I got this too, comes out of nowhere, typing stalls for a second or two, sometimes the keystrokes are remembered, and typed a bit later, other times they're just dropped and i sit and look at the screen, then try typing and the letter shows up, very annoying for a developer.

Danish keyboard layout (only)
Single keyboard (Logitech K520)
Ubuntu 20.04 (had it on 18.04 too)
MSI GeForce GT 1030
Nvidia 460 (just updated from 450 1½ day ago, haven't seen the bug since this so far)
Display manager gdm3

Xinput shows me a funny thing, a webcam as keyboard. This webcam is quite new, so i'll try and disable it next time i experience the bug.

xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech M310 id=9 [slave pointer (2)]
⎜ ↳ Logitech K520 id=10 [slave pointer (2)]
⎜ ↳ ATEN DVI DL KVMP id=12 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
    ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
    ↳ Power Button id=6 [slave keyboard (3)]
    ↳ Video Bus id=7 [slave keyboard (3)]
    ↳ Power Button id=8 [slave keyboard (3)]
    ↳ ATEN DVI DL KVMP id=11 [slave keyboard (3)]
    ↳ Trust Webcam: Trust Webcam id=13 [slave keyboard (3)]
    ↳ Eee PC WMI hotkeys id=14 [slave keyboard (3)]
    ↳ Logitech K520 id=15 [slave keyboard (3)]

`xev -event keyboard` did not show anything odd.

Feel free to ask for any other info (add commands please)

Kind regards
Kim

This issue still happens on Ubuntu 20.04. I use a laptop with Bluetooth keyboard. I couldn't use media keys like volume up and down due to the large delay. Even if I use the media keys in a single keyboard, the delay happens.

Post #8 solution works for me. Make sure to restart after applying the fix.

If you have any information about this bug then please put it in the upstream issue for the developers to see:

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2872

I recently bought the R-GO Split keyboard too and on Ubuntu 20.04 (Gnome) it was very laggy.
What I did to get rid of the lag was to simply switch from Gnome to KDE Plasma Desktop. Switching to Wayland worked too, but unfortunately, Wayland was causing problems with Skype and Audacity. So that's why I'm using KDE now. It might take some time to get used to KDE Plasma Desktop but it's a great Window Manager and seems to be a lot more stable than Gnome and Wayland.

I also tried to switch to the Brasilien keyboard and commenting out "modifier_map Mod3 { Scroll_Lock };". But it didn't work even after restarting several times and making sure that the Brasilian keyboard was selected. Maybe it worked with an earlier version of Ubuntu but at least for me with Ubuntu 20.04 (Gnome) it didn't have any effect.

Hope this is helpful!

Moving to upstream bug: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1858

I had the same log but the action was different.
Situations where I get the same messages:
- connect/disconnect my secondary keyboard
- when I press a key on the first keyboard and then I press the key on the second keyboard
- on same keyboard: pressing on a letter key and then using an FN key combination

After a while, causing a delay in the response when a key was pressed.

After some testing, I removed the "gnome-shell-extension-ubuntu-dock" package and no longer had this problem.

To have the dock showing again, I installed the "Dash to Dock" extension and had to disable (using Gnome Tweak Tool) the option "Use keyboard shortcuts to activate apps" (in Behavior extension tab). With this option enabled, messages continue to appear as normal.

With Wayland I had no problem because apparently the "Ubuntu Dock" extension is disabled by default. When activated, I get the same problem as the standard version of the Ubuntu installation.

I had the same situation, first on ubuntu 20.04 and now still on ubuntu 20.10.

I have USB keyboard nad usb mouse. I am using mapping for my USB mouse (btnx-config library) so I can map my button as keyboard keys, I was noticing small freezes but I though it was library problem. But later I wanted to create a simple keylogger from python keyboard library and simple script which always when I press d it also press r in system keyboard. When I did it many times, my computer freeze for few seconds, even minute and this warning occurs in syslog.

Is it going to be solve in 21.04?

Anyone affected by this bug should probably discuss it upstream where the developers can see:

  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1858

I'm here to say that I'm having the same issue.

Until this evening, I was using Debian 10 with KDE, but I installed Ubuntu 20.04 a few hours ago.

I use a laptop with a external keyboard connected on it and my laptop have a numeric keyboard and my external keyboard don't, so I always use the laptop keyboard to insert numbers. However, each time I swap the keyboard, my computer frozen.

Also, I have a mouse with several buttons and two of them are configured as "PgUp" and "PgDn" because I find it more practical over there. However, unfortunately, I can't use it properly because the computer crashes every time I press a button. However, I think it's worth mentioning that mouse buttons that belong to the mouse (like click and scroll) don't have this problem.

In short, if I switch keyboards, whether it's laptop, external or mouse buttons, my computer freezes.

I was facing this bug in Pop OS 21.04 when changing keyboard, pressing media keys in laptop (volume, brightness, etc) or using a mouse with configurable hotkeys.

The delay was very long.

After I worked on Pedros' solution written above (scroll lock key), the delay reduced significantly.

But it was still present. If not gaming, barely could notice it.

The solution that worked for me was this workaround from "Wiggy boy"
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1858#note_818548

Now the delay is completely gone

I wrote about this issue in blog post and also provided some downloads to easily just install the bug fixed packages. I'll try to keep this up to date, as updates come out.

https://lindholm.tk/post/1

I have checked that the Osvald Lindholm fix works. Thanks bro!

This problem is a real pain in the ass.

Fedora here, but same keyboard and 100% same issue!
Let's see if Osvald Lindholms fix fixes this too.

I'm facing the same symptoms. First time I realized I have this issue was when playing a game on Stadia through Chrome/Chromium. I am using a special hybrid joystick (movemaster.biz) to replace my keyboard, which consists of two parts. Both devices are connected via usb and are recognized as usb hid keyboards. When steering with the grip of the device and only pressing buttons on the same device everything is okay. But as soon as I press a button on the extension there is a litte lag or stutter/freeze.

I thought it would be an issue with the browser and blamed Chromium, as I haven't had any issues with games played locally. But now I had the same issue with Star Wars Battlefront (from EA) played through Steam + Proton.

The output of journalctl showed the same overwriting existing binding of keysym errors as described here: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1857392

That report leads to this report, and from here I got to https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1858#note_818548 describing a workaround with altering libmutter.

I tried that workaround on Ubuntu 20.04.3 LTS, where I at first wasn't able to successfully biuld mutter/libmutter, but it helped to disable the tests by editing debian/rules and add export DEB_BUILD_OPTIONS=nocheck.

Installing the altered lib and rebooting didn't get rid of the problem though.

Unfortunately the blog post from Osvald doesn't seem to be reachable as the https certificate was revoked.

As the freeze happens despite the workaround, I'm not sure if it's the same issue though. Any help would be appreciated as this behavior totally ruins the experience.

edit: I found a different workaround.

As this affects me only in games, the workaround seems to tell the window and mutter they should bypass compositing, when the window is in full screen. This can be achieved via xprop.
- open a chromium, open a terminal
- in the terminal enter xprop (enter) and with the cross-mouse cursor click into the chromium window. It shows:
_NET_WM_BYPASS_COMPOSITOR(CARDINAL) = 2 (2 means: "hints the compositor to not disabling compositing of this window" according to https://gitlab.gnome.org/GNOME/mutter/-/issues/24#note_924252)
_NET_WM_PID(CARDINAL) = 60247
- search for window id: xdotool search --all --pid 60247 --name Chromium (e.g. 96468995)
- alter bypass value: xprop -id 96468995 -format _NET_WM_BYPASS_COMPOSITOR 32c -set _NET_WM_BYPASS_COMPOSITOR 1
When Stadia now launches a game, the lag is gone when I use the movemaster and the extension. It introduces some minor tearing, but that's way less disturbing than the stutter/freezes.

Are you using Compton? If so, please see https://askubuntu.com/a/1439993/682596 and https://gitlab.xfce.org/xfce/xfwm4/-/issues/676

Basically, Compton could be at fault for creating these key delays. As soon as I start Compton manually in a similar fashion as the OS startup, the problem appears. I am not using double keyboards.