Help with stuttering UI when typing special characters in 18.10

Budgie Desktop
1

I’m a Linux novice, but I decided to give Ubuntu Budgie a try on my desktop.

I’ve got it working almost perfectly now, including to my surprise, GSync and 144hz (had to upgrade from 18.04 to 18.10 for that), which looks beautiful… but only the most peculiar issue remains.

I notice that typing text looks very stuttery, and the entire UI (except the mouse cursor) will freeze whilst typing. Oddly, it ONLY happens if I type a special character followed by a space.

For example, typing this would result in no stutters: a a a a a a a a a a a a a a a a
However, typing this would hang the UI for a few seconds: / / / / / / / / / / / / / / / / / / / /

Also, it seems to be hardware specific. I am using a Noppoo Choc Mini mechanical keyboard.
If I switch to a crappy old wireless Logitech keyboard, it’s absolutely fine!
Doesn’t seem to matter which USB port. The same keyboard is fine in Windows.

How do I begin debugging this?
Thanks a lot!

2

Weird observation!

Welcome BTW

If you download the latest 19.04 daily image and boot into the live session via a USB stick can you reproduce the issue. Might be buggy xorg and/or kernel stuff

3

I’ve upgraded to 19.04 today, and the exact same issue with my keyboard is still present.

Can it really be that a keyboard is incompatible with an OS? It would be the first time I’ve encountered such a thing in all my days.

I’d appreciate any other debug steps you can think to try.

4

Just out of curiosity, what type of keyboard do you have, and can you just confirm that it is a traditional USB connector? I guess realistically what I’m asking is is there anything special about this keyboard? Additional functionality, a firmware, etc.

5

The offending keyboard is a Noppoo Choc Mini:
http://www.avernus.com/~gadams/hardware/keyboard/
It’s just a normal USB mechanical keyboard as far as I can tell, this is the first time I’ve had any issue with it.

I have this keyboard too which has funky firmware in it, yet it works flawlessly in Ubuntu:
https://ultimatehackingkeyboard.com/

Edit: In fact, the guy on that Noppoo Choc Mini article says something about the USB behaviour of this keyboard here under the heading “USB Behaviour”:
http://www.avernus.com/~gadams/hardware/keyboard/choc-mini-analysis.html
I’m not sure I understand what he’s talking about but it could be a clue?

6

Ah. Excellent last link.

The last bit is important. The keyboard is not following the USB uid spec for certain keys. That is what you are seeing. The linux kernel is expecting stuff from the keyboard that is not properly being sent. Hence why it is struggling.

Nothing really we can do here. Upstream kernel devs will just say that the keyboard is malfunctioning by virtue it is not providing the kernel with info that it requires.

7

Ah, that’s entirely fair enough I guess.

These next questions are just for my own curiosity now I suppose…

  1. I notice the OS X kernel also had issues with the same keyboard, but some folks wrote HID Descriptor overrides to make the keyboard work:
    https://github.com/thefloweringash/iousbhiddriver-descriptor-override
    Is something like this theoretically possible for Ubuntu too? It might take me weeks of study but if it was at least theoretically possible, it could be a project.

  2. I’m still confused as to how a keyboard sending a wrong key can cause the UI thread to completely block momentarily. I mean, it still ends up with the correct input on the screen - it just seems to cause a 500ms UI block in order to achieve it. Makes me wonder what it’s trying to do during this time, as I imagine Windows is also recieving the nonsense input from the keyboard, but it doesn’t cause the whole UI thread to lock up when it gets it. Just curious I guess.

Thanks for the responses though =)