4

I have Ubuntu 14.04 running on a Dell Latitude 13 laptop. When I launch Chromium and open several pages from stackexchange in different tabs. Any text I type in will frequently have characters showing up in a different order from how they were typed. For example, this paragraph actually showed up as:

I have Ubuntu 14.04 runnign on aDell Latitude 1 3laptop. Whne I alucnh Chormium na dopne several pages form tsackexchnag ei ndiffreent tabs. Any text I type in will ferwuqently have cahracters shwoing up in adifferent ofrdre form hwo htye weer ytped. For exmapel, thsi apragraph actually shwoed up as

As you can imagine having to manually fix that every time it happens can be very frustrating. The behavior looks as if some layer in the software stack is inserting key presses into a stack rather than a queue, and if they are not consumed as quickly as they arrive, they show up in the wrong order.

This only happens sporadically, and seems to happen more often when Chromium is swapping a lot. I have not been able to identify which layer of the software stack is causing the problem. Is there any additional debugging/logging I could enable to show me in which order characters show up at different layers in the software stack?

What I have tried so far

By sending alternating STOP and CONT signals to an xterm, I was able to slow down xterm just enough to reproduce the symptom. Since reordering of keyboard input is not supposed to happen even if xterm is frozen for a little bit, I think it is safe to conclude that the flaw is not in Chromium or stackexchange, but rather in some software being involved in both cases.

In order to rule out the possibility that it may be a flaw in the keyboard hardware, I tested with synthetic key presses.

sleep 10 ; for K in {a..z} ; do xdotool type "$K" ; sleep 0.2 ; done

With that command I was able to reproduce the problem. On one occasion the keys showed up in the order abcdefghlmkjpnioqrstuvwxyz. So when it also happens with keypresses generated by xdotool, it cannot be a flaw in the keyboard or keyboard controller.

If I speed up the input produced using xdotool even further, it causes the xterm to lock up.

Seeing an xterm lock up when keyboard input arrives quickly is something I have seen even without artificially slowing it down using STOP signals. When I do see xterm lock up like that, it usually keeps happening after I kill the xterm and start a new one. That problem persists until I run compiz --replace. After running that command everything runs faster and xterm no longer locks up at least for the first few days.

So there is some evidence suggesting that the two problems are related and somehow has something to do with compiz, but I don't have any solid evidence to back up that suspicion.

13
  • 1
    Oh man, this is not going to be simple :( Does it happen only in chromium?
    – terdon
    Jun 13, 2015 at 15:33
  • @terdon By sending alternating STOP and CONT signals to an xterm I managed to slow down an xterm enough to reproduce the symptom.
    – kasperd
    Jun 13, 2015 at 15:34
  • OK but that was asking for it :) Does it happen naturally in anything else but chromium? I'm trying to understand if it's a chromium issue or a more general one.
    – terdon
    Jun 13, 2015 at 15:35
  • 2
    I've been experiencing the same problem with chromium on a first-gen Lenovo X1 Carbon. I'm using the i3 windowmanager. Could it be something to do with Xorg?
    – Logan
    Jun 25, 2015 at 1:50
  • 1
    @Sneetsher The string ppa is not found in any of those files.
    – kasperd
    Jul 20, 2015 at 12:41

0

You must log in to answer this question.

Browse other questions tagged .